Linux下Oracle 資料檔案被實體誤删除的恢複

#加深對Linux句柄的了解/緊急情況下Oracle的快速恢複

不同于從Oracle中drop掉資料檔案，在某些情況下，可能會遇到資料庫在運作時資料檔案在作業系統級别被删除，而此時Oracle執行個體并未崩潰，仍然處于open狀态。此時就要求盡量在最小的影響下最高效率地完成恢複。現将恢複過程整理出來，以備不時之需。

<<過程模拟>>

<STEP 1>模拟删除

SYS@icsdb >select name from v$datafile;

NAME

--------------------------------------------------

/ora_data/icsdb/system01.dbf

/ora_data/icsdb/sysaux01.dbf

/ora_data/icsdb/undotbs01.dbf

/ora_data/icsdb/users01.dbf

/ora_data/icsdb/icsdb01.bdf

/ora_data/icsdb/hr01.dbf

已選擇6行。

[root@iccsdb01 icsdb]# ls -ld icsdb01.bdf 

-rw-r-----. 1 oracle oinstall 1073750016 5月  25 16:24 icsdb01.bdf

檢查一下資料看看目前表和資料條數，有3個表

ICS@icsdb >select table_name from user_tables;

TABLE_NAME

------------------------------------------------------------------------------------------

SC

COURSE

STUDENT

已student表為例，說明表中有39條資料

ICS@icsdb >select count(*) from student;

  COUNT(*)

----------

39

insert into student  values(200216303,'王偉','男',33,'IS');

删除測試資料檔案

[root@icsdb02 icsdb]# rm -rf /oracle_data/icsdb/icsdb01.dbf 

SQL> ho rm /oracle_data/icsdb/icsdb01.dbf  --删除使用者資料檔案;

在檢視資料檔案已經不在了

ls: 無法通路icsdb01.bdf: 沒有那個檔案或目錄

這裡千萬不要重新開機資料庫，否則就真丢了

<STEP 2>通過句柄恢複資料檔案--先找出db writer所對應的PID(3742)

[root@iccsdb01 icsdb]# ps -ef|grep dbw0|grep -v grep

oracle    3742     1  0 11:13 ?        00:00:00 ora_dbw0_icsdb

--再找出被程序所删除檔案的句柄(3742)，可能會有多個程序，本處隻有一個

[root@iccsdb01 icsdb]#  ls -l /proc/3742/fd | grep deleted

lrwx------. 1 oracle oinstall 64 5月  25 16:36 263 -> /ora_data/icsdb/icsdb01.bdf (deleted)

--将被删資料檔案的句柄拷貝回資料檔案，先備份到tmp下

[root@iccsdb01 icsdb]# cp /proc/3742/fd/263   /tmp/icsdb01.dbf

重新開機資料庫測試恢複，關閉資料庫關閉不掉會報錯

SYS@icsdb >shutdown immediate;

ORA-01116: 打開資料庫檔案 5 時出錯

ORA-01110: 資料檔案 5: '/ora_data/icsdb/icsdb01.bdf'

ORA-27041: 無法打開檔案

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

強制關閉資料庫

SYS@icsdb >shutdown abort

ORACLE 例程已經關閉。

啟動資料庫測試，啟動隻能啟動到mount狀态，open不了

SYS@icsdb >startup

ORACLE 例程已經啟動。

Total System Global Area  471830528 bytes

Fixed Size     2254344 bytes

Variable Size   360712696 bytes

Database Buffers   104857600 bytes

Redo Buffers     4005888 bytes

資料庫裝載完畢。

ORA-01157: 無法辨別/鎖定資料檔案 5 - 請參閱 DBWR 跟蹤檔案 ORA-01110:

資料檔案 5: '/ora_data/icsdb/icsdb01.bdf'

SYS@icsdb >select instance_name,status from v$instance;

INSTANCE_NAME  STATUS

------------------------------------------------ ------------------------------------

icsdb  MOUNTED

将資料檔案拷貝會原來目錄，并修改屬組為oracle

[root@iccsdb01 tmp]# mv icsdb01.dbf  /ora_data/icsdb/

[root@iccsdb01 icsdb]# chown oracle:oinstall icsdb01.dbf 

alter tablespace ICSDB rename DATAFILE '/ora_data/icsdb/icsdb01.bdf' to  '/ora_data/icsdb/icsdb01.dbf';  

<STEP 3>通過日志恢複事務

接下來便是事務的恢複操作，分為兩種情況：

1)對于歸檔模式，隻需簡單offline掉資料檔案，進行recover最後再将資料檔案online即可，如：

SQL> alter database datafile 4 offline;

Database altered.

SQL> recover datafile 4;

Media recovery complete.

SQL> alter database datafile 4 online;

2)如果是非歸檔，那麼作offline datafile的時候會遇到ORA-01145錯誤，但是可以在copy完檔案句柄之後，

嘗試offline tablespace，然後再online tablespace，這時候會要求恢複之前誤删除的檔案，如果日志組還沒有切換到全部覆寫，那麼recover是可以成功的。

SQL> alter tablespace users offline;

Tablespace altered.

SQL> recover datafile 4 ;          

SQL> alter tablespace users online;

至此恢複完成！

<<恢複原理>>

在Linux作業系統中，如果檔案從作業系統級别被rm掉，之前打開該檔案的程序仍然持有相應的檔案句柄，所指向的檔案仍然可以讀寫，

并且該檔案的檔案描述符可以從/proc目錄中獲得。但是要注意的是，此時如果關閉資料庫，則此句柄會消失，那麼除了掃描磁盤進行檔案恢複之外就沒有 其它方法了，

是以在資料庫出現問題的時候，如果不确認情況的複雜程度，千萬不要随便關閉資料庫。重新開機資料庫往往是沒有意義的，甚至是緻命的。

另：rm操作始終是系統上最危險的區域，需謹慎駕駛！

本文轉自 yuri_cto 51CTO部落格，原文連結：http://blog.51cto.com/laobaiv1/1948152，如需轉載請自行聯系原作者