不使用rman工具就能恢復被rm刪除的數據文件案例

當我們在Linux系統中不小心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刪除的數據文件，并最終順利打開數據庫的實驗！我是一個比較嚴謹的人，所以一上來我先做個了“壓縮全庫備份”做到有備無患

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com