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

周日为了挽救主库USERS表空间不足临时扩了20G表空间，导致DG库的/bak/datafile/目录不足。 日志应用到扩表空间的归档就崩溃，同时更悲剧的是空间不足导致SYSTEM表空间写入也发生了异常。 对于该问题首先想到系统级别扩容，通过系统级别的resize2fs经过确认无法扩容。通过分区合并由于没有相邻的分区也无法进行，只有采用ORACLE层面的方式。我们的DG系统因为空间紧缺数据文件写到了两个不同的文件夹，既然数据可以写到两个目录，肯定可以写到三个目录，会不会是控制文件里有定义，马上创建了PFILE，但从PFILE里面没有发现有用的数据文件重定向信息，又查找资料，发现了救命的RENAME命令，通过RENAME命令解决了数据文件迁移的问题。

1. 
   
2.      
3. 文件系统              容量  已用 可用 已用% 挂载点 
4. /dev/sda3              19G  470M   18G   3% / 
5. /dev/sda12            125G  105G   14G  89% /bak 
6. /dev/sda10            9.5G  151M  8.9G   2% /tmp 
7. /dev/sda9             9.5G  318M  8.7G   4% /var 
8. /dev/sda8              19G  173M   18G   1% /opt 
9. /dev/sda7              19G  4.0G   14G  23% /weblogic 
10. /dev/sda2              48G  4.0G   41G   9% /usr 
11. /dev/sda6              48G   28G   18G  61% /home 
12. /dev/sda5              95G   76G   15G  85% /u01 
13. /dev/sda1             1.9G   42M  1.8G   3% /boot 
14. tmpfs                 3.9G     0  3.9G   0% /dev/shm 
15. [root@L-DB-163-18 datafile]# umount /weblogic 
16. [root@L-DB-163-18 datafile]# df -h 
17. 文件系统              容量  已用 可用 已用% 挂载点 
18. /dev/sda3              19G  470M   18G   3% / 
19. /dev/sda12            125G  105G   14G  89% /bak 
20. /dev/sda10            9.5G  151M  8.9G   2% /tmp 
21. /dev/sda9             9.5G  318M  8.7G   4% /var 
22. /dev/sda8              19G  173M   18G   1% /opt 
23. /dev/sda2              48G  4.0G   41G   9% /usr 
24. /dev/sda6              48G   28G   18G  61% /home 
25. /dev/sda5              95G   76G   15G  85% /u01 
26. /dev/sda1             1.9G   42M  1.8G   3% /boot 
27. tmpfs                 3.9G     0  3.9G   0% /dev/shm 
28.  
29. [root@L-DB-163-18 datafile]# e2fsck -f /dev/sda12 
30. e2fsck 1.39 (29-May-2006) 
31. Pass 1: Checking inodes, blocks, and sizes 
32. Pass 2: Checking directory structure 
33. Pass 3: Checking directory connectivity 
34. Pass 4: Checking reference counts 
35. Pass 5: Checking group summary information 
36. /bak: 24/33718272 files (12.5% non-contiguous), 28482930/33714402 blocks 
37. [root@L-DB-163-18 datafile]# resize2fs /dev/sda12 128G; 
38. resize2fs 1.39 (29-May-2006) 
39. Filesystem at /dev/sda12 is mounted on /bak; on-line resizing required 
40. Performing an on-line resize of /dev/sda12 to 33554432 (4k) blocks. 
41. The filesystem on /dev/sda12 is now 33554432 blocks long. 
42. 空间不够，通过UNMOUNT其他文件系统扩容需要的文件系统后来仔细研究了下确实是不行的。 
43. 必须从分区层面进行，尝试fdisk /dev/sda\d\7\w删除了无用的分区，研究分区合并也行不通， 
44. 因为sda12相邻的分区没有可用空间，从分区层面扩容无法成行， 
45.  
46. 在数据库层面原本可以通过OPEN数据库把数据文件重命名的动作由于SYSTEM表空间未完全写完一个事物而无法OPEN， 
47. RENAME操作报错，具体如下。 
48. SQL> alter tablespace TEMP rename datafile '/bak/datafile/temp01.dbf' to '/usr/datafile/temp01.dbf'; 
49. alter tablespace TEMP rename datafile '/bak/datafile/temp01.dbf' to '/usr/datafile/temp01.dbf' 
50. * 
51. ERROR at line 1: 
52. ORA-01109: database not open 
53.   
54. SQL> alter database open read only; 
55. alter database open read only 
56. * 
57. ERROR at line 1: 
58. ORA-16004: backup database requires recovery 
59. ORA-01196: file 1 is inconsistent due to a failed media recovery session 
60. ORA-01110: data file 1: '/bak/datafile/system01.dbf' 
61.  
62.     按照常理，DG数据库可以在MOUNT下执行RENAME操作，但试了很多次却不行。 
63. 再仔细一看报错信息，居然有如下提示ORA-01275: Operation RENAME is not allowed if standby file management is automatic. 
64. SQL> startup nomount; 
65. ORACLE instance started. 
66.   
67. Total System Global Area 4596957184 bytes 
68. Fixed Size                  2090048 bytes 
69. Variable Size             838863808 bytes 
70. Database Buffers         3741319168 bytes 
71. Redo Buffers               14684160 bytes 
72. SQL> alter database mount standby database; 
73.   
74. Database altered. 
75.   
76. SQL> alter database rename file '/bak/datafile/namin_data.dbf' to '/usr/datafile/namin_data.dbf'; 
77. alter database rename file '/bak/datafile/namin_data.dbf' to '/usr/datafile/namin_data.dbf' 
78. * 
79. ERROR at line 1: 
80. ORA-01511: error in renaming log/data files 
81. ORA-01275: Operation RENAME is not allowed if standby file management is 
82. automatic. 
83. 上ORACLE查了下，在DG模式下文件有两种管理方式（show parameter standby可以查），自动和手动管理，如果是自动管理，是没法重命名的， 
84. 马上尝试改成手动模式。 
85.  
86. SQL>  show parameter standby 
87.   
88. NAME                                 TYPE        VALUE 
89. ------------------------------------ ----------- ------------------------------ 
90. standby_archive_dest                 string      ?/dbs/arch 
91. standby_file_management              string      AUTO 
92. SQL> alter system set standby_file_management=MANUAL; 
93.   
94. System altered. 
95.   
96. SQL> show parameter standby 
97.   
98. NAME                                 TYPE        VALUE 
99. ------------------------------------ ----------- ------------------------------ 
100. standby_archive_dest                 string      ?/dbs/arch 
101. standby_file_management              string      MANUAL 
102. SQL> alter database rename file '/bak/datafile/namin_data.dbf' to '/usr/datafile/namin_data.dbf'; 
103.   
104. Database altered. 
105.   
106. SQL> alter database rename file '/bak/datafile/temp01.dbf' to '/usr/datafile/temp01.dbf'; 
107.   
108. Database altered. 
109. 至此更改文件路径成功，数据文件已经定向到了新的路径/usr/datafile/。 
110. 再此药注意的是重命名前必须把文件原封不动的拷贝过去，否则会报如下错误。 
111. SQL> alter database rename file '/bak/datafile/sysaux01.dbf' to '/usr/datafile/sysaux01.dbf'; 
112. alter database rename file '/bak/datafile/sysaux01.dbf' to '/usr/datafile/sysaux01.dbf' 
113. * 
114. ERROR at line 1: 
115. ORA-01511: error in renaming log/data files 
116. ORA-01141: error renaming data file 3 - new file '/usr/datafile/sysaux01.dbf'not found 
117. ORA-01110: data file 3: '/bak/datafile/sysaux01.dbf' 
118. ORA-27037: unable to obtain file status 
119. Linux-x86_64 Error: 2: No such file or directory 
120. Additional information: 3 
121.  
122. 这下空间有了，事情就好办了，只要/bak/datafile/下有20G以上的空间，应用了USERS表空间扩容的归档。 
123. 其余就是很好操作的事情。归档日志满可以把已经应用的归档给删除掉，如果不小心把未应用的归档删除了怎么办， 
124. 也不用慌，如果用了ASM，可以用RMAN从主库提取归档，然后FTP给DG，如果用普通文件系统，那么直接FTP。 
125. EG: 
126. RMAN> copy archivelog '+DATA/log/archivelog/2_5585_697238176.dbf' to '/u01/rman/2_5585_697238176.dbf'; 

 本文转自zylhsy 51CTO博客，原文链接：http://blog.51cto.com/yunlongzheng/578456，如需转载请自行联系原作者