通過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/sdad7w刪除了無用的分割槽，研究分割槽合併也行不通， 
因為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`;