不使用rman工具就能恢複被rm刪除的資料檔案案例

引題：朋友一時興起使用了rm**，刪除了Oracle資料檔案後找我幫忙，我在幫朋友恢複資料庫時，遇到了當recover時，報錯不能找到28739號歸檔日誌，這樣我就不能同步scn，更不能開啟資料庫了。這是歸檔日誌不連續的典型案例，我最後告訴他要做好心理準備。事情還沒有完，這個真實案例引發了我的思考，如果當時在朋友沒有做rman拯救措施的情況下，可不可能不使用rman即可恢複資料檔案呢！最後我找到了答案：）

案例
1.系統solaris SunOS TJLT-YDWG6 5.9 Generic_122300-25 sun4u sparc SUNW,Sun-Fire-V890
DB  OracleDatabase 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
2.案情描述
現場工程師使用了rm -rf *.dbf命令把所有的資料檔案全部刪除了
現在有5月4日的備份
restore database until time "to_date('2012-05-04 12:00:00','yyyy-mm-dd hh24:mi:ss')";  進行恢複顯示finish restore complete沒有問題已經把檔案 複製回來了
進行同步
RMAN> recover database until time "to_date('2012-05-04 11:00:00','yyyy-mm-dd hh24:mi:ss')";                 
Starting recover at 2012-07-26 14:02:42
using channel ORA_DISK_1
starting media recovery
unable to find archive log
archive log thread=1 sequence=28739  缺少28739號的歸檔日誌，導致undotbs01.dbf檔案不一致
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/opt/oradata/kpidb/undotbs01.dbf'
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/26/2012 14:02:51
RMAN-06054: media recovery requesting unknown log: thread 1 seq 28739 lowscn 1513525474
Leonarding
2012.7.26

在我們工作中可能會經常發生這樣類似的突髮狀況，在遇到此情況下首先要做的就是冷靜，上面發生的問題到了我這裡之後，我就探索資料庫已經變成了mount狀態，在使用檔案控制代碼方式恢複資料檔案已經為時已晚，所以我採用了常規的恢複方式，沒想到啊沒想到，歸檔日誌還不全，立馬我整個人都“斯巴達”了，最後告訴朋友做DBA是需要勇氣的。

下面我用自己的測試庫示範一下作業系統rm層級的刪除資料檔案後，資料庫仍然處於open狀態的時候使用檔案控制代碼來恢複被rm刪除的資料檔案，並最終順利開啟資料庫的實驗！我是一個比較嚴謹的人，所以一上來我先做個了“壓縮全庫備份”做到有備無患

1 2 3 4 下一頁