通过RENAME解救空间紧缺的DG系统

 周日为了挽救主库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数据库