周日为了挽救主库USERS表空间不足临时扩了20G表空间，导致DG库的/bak/datafile/目录不足。 日志应用到扩表空间的归档就崩溃，同时更悲剧的是空间不足导致SYSTEM表空间写入也发生了异常。 对于该问题首先想到系统级别扩容，通过系统级别的resize2fs经过确认无法扩容。通过分区合并由于没有相邻的分区也无法进行，只有采用ORACLE层面的方式。我们的DG系统因为空间紧缺数据文件写到了两个不同的文件夹，既然数据可以写到两个目录，肯定可以写到三个目录，会不会是控制文件里有定义，马上创建了PFILE，但从PFILE里面没有发现有用的数据文件重定向信息，又查找资料，发现了救命的RENAME命令，通过RENAME命令解决了数据文件迁移的问题。
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda3 19G 470M 18G 3% /
/dev/sda12 125G 105G 14G 89% /bak
/dev/sda10 9.5G 151M 8.9G 2% /tmp
/dev/sda9 9.5G 318M 8.7G 4% /var
/dev/sda8 19G 173M 18G 1% /opt
/dev/sda7 19G 4.0G 14G 23% /weblogic
/dev/sda2 48G 4.0G 41G 9% /usr
/dev/sda6 48G 28G 18G 61% /home
/dev/sda5 95G 76G 15G 85% /u01
/dev/sda1 1.9G 42M 1.8G 3% /boot
tmpfs 3.9G 0 3.9G 0% /dev/shm
[root@L-DB-163-18 datafile]# umount /weblogic
[root@L-DB-163-18 datafile]# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda3 19G 470M 18G 3% /
/dev/sda12 125G 105G 14G 89% /bak
/dev/sda10 9.5G 151M 8.9G 2% /tmp
/dev/sda9 9.5G 318M 8.7G 4% /var
/dev/sda8 19G 173M 18G 1% /opt
/dev/sda2 48G 4.0G 41G 9% /usr
/dev/sda6 48G 28G 18G 61% /home
/dev/sda5 95G 76G 15G 85% /u01
/dev/sda1 1.9G 42M 1.8G 3% /boot
tmpfs 3.9G 0 3.9G 0% /dev/shm
[root@L-DB-163-18 datafile]# e2fsck -f /dev/sda12
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/bak: 24/33718272 files (12.5% non-contiguous), 28482930/33714402 blocks
[root@L-DB-163-18 datafile]# resize2fs /dev/sda12 128G;
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/sda12 is mounted on /bak; on-line resizing required
Performing an on-line resize of /dev/sda12 to 33554432 (4k) blocks.
The filesystem on /dev/sda12 is now 33554432 blocks long.
空间不够，通过UNMOUNT其他文件系统扩容需要的文件系统后来仔细研究了下确实是不行的。
必须从分区层面进行，尝试fdisk /dev/sda\d\7\w删除了无用的分区，研究分区合并也行不通，
因为sda12相邻的分区没有可用空间，从分区层面扩容无法成行，
在数据库层面原本可以通过OPEN数据库把数据文件重命名的动作由于SYSTEM表空间未完全写完一个事物而无法OPEN，
RENAME操作报错，具体如下。
SQL> alter tablespace TEMP rename datafile '/bak/datafile/temp01.dbf' to '/usr/datafile/temp01.dbf';
alter tablespace TEMP rename datafile '/bak/datafile/temp01.dbf' to '/usr/datafile/temp01.dbf'
*
ERROR at line 1:
ORA-01109: database not open
SQL> alter database open read only;
alter database open read only
*
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/bak/datafile/system01.dbf'
按照常理，DG数据库可以在MOUNT下执行RENAME操作，但试了很多次却不行。
再仔细一看报错信息，居然有如下提示ORA-01275: Operation RENAME is not allowed if standby file management is automatic.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 4596957184 bytes
Fixed Size 2090048 bytes
Variable Size 838863808 bytes
Database Buffers 3741319168 bytes
Redo Buffers 14684160 bytes
SQL> alter database mount standby database;
Database altered.
SQL> alter database rename file '/bak/datafile/namin_data.dbf' to '/usr/datafile/namin_data.dbf';
alter database rename file '/bak/datafile/namin_data.dbf' to '/usr/datafile/namin_data.dbf'
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01275: Operation RENAME is not allowed if standby file management is
automatic.
上ORACLE查了下，在DG模式下文件有两种管理方式（show parameter standby可以查），自动和手动管理，如果是自动管理，是没法重命名的，
马上尝试改成手动模式。
SQL> show parameter standby
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_archive_dest string ?/dbs/arch
standby_file_management string AUTO
SQL> alter system set standby_file_management=MANUAL;
System altered.
SQL> show parameter standby
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_archive_dest string ?/dbs/arch
standby_file_management string MANUAL
SQL> alter database rename file '/bak/datafile/namin_data.dbf' to '/usr/datafile/namin_data.dbf';
Database altered.
SQL> alter database rename file '/bak/datafile/temp01.dbf' to '/usr/datafile/temp01.dbf';
Database altered.
至此更改文件路径成功，数据文件已经定向到了新的路径/usr/datafile/。
再此药注意的是重命名前必须把文件原封不动的拷贝过去，否则会报如下错误。
SQL> alter database rename file '/bak/datafile/sysaux01.dbf' to '/usr/datafile/sysaux01.dbf';
alter database rename file '/bak/datafile/sysaux01.dbf' to '/usr/datafile/sysaux01.dbf'
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01141: error renaming data file 3 - new file '/usr/datafile/sysaux01.dbf'not found
ORA-01110: data file 3: '/bak/datafile/sysaux01.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
这下空间有了，事情就好办了，只要/bak/datafile/下有20G以上的空间，应用了USERS表空间扩容的归档。
其余就是很好操作的事情。归档日志满可以把已经应用的归档给删除掉，如果不小心把未应用的归档删除了怎么办，
也不用慌，如果用了ASM，可以用RMAN从主库提取归档，然后FTP给DG，如果用普通文件系统，那么直接FTP。
EG:
RMAN> copy archivelog '+DATA/log/archivelog/2_5585_697238176.dbf' to '/u01/rman/2_5585_697238176.dbf';
©著作权归作者所有：来自51CTO博客作者zylhsy的原创作品，如需转载，请注明出处，否则将追究法律责任
oracle休闲renameORACLE数据库