rman恢復:資料檔案丟失,控制檔案丟失,聯機日誌檔案丟失(非當前使用與當前使用)

與刃爭鋒發表於2013-12-30
原文網址 : http://blog.itpub.net/25025926/viewspace-1065705/
rman恢復示例                                                            以下操作均參考了君三思大仙的書——塗抹oracle

歸檔模式有備份,丟失資料檔案的恢復
1.建立全庫備份
rman>backup database;
2.構造資料

3.模擬檔案丟失
關閉資料庫shutdown immediate後(不關閉無法刪除資料檔案,因為被db鎖定),殘忍的刪除user01.dbf資料檔案. 

4.嘗試開啟資料庫,未遂

5.執行恢復
另開視窗登入,輸入restore datafile 4;

繼續整

查詢一下剛才建立的測試資料:一切都恢復正常了,你微微一笑(因為是測試,你不緊張,換生產資料庫基本就嚇尿了)


附送一個SQL來查詢表空間及其關聯的資料檔案:(來自君三思大仙兒,以上很多的資料和例子都來自君三思大仙兒的說)

select ts.tablespace_name,df.file_name,df.file_id,df.status from dba_tablespaces ts,
    (select tablespace_name,file_id,file_name,status from dba_data_files
        union all
     select tablespace_name,file_id,file_name,status rom dba_temp_files) df
where ts.tablespace_name = df.tablespace_name


其中file_id為1的有倆,有點意思,暫不知道為啥




歸檔模式無備份,丟失資料檔案的恢復(歸檔不備份,作死的節奏)
並不是所有資料檔案丟失都能夠被恢復,同樣也不是所有資料檔案丟失都需要恢復,比如system表空間資料檔案丟失或損壞,除非藉助備份,否則無法直接恢復.如果是臨時表空間的資料檔案丟了,就沒啥大事——重建一個即可,因為它是臨時的.

1.建立演示環境


sql>create user weiye identified by weiye default tablespace bobtest quota unlimited on bobtest;
sql>grant connect,resource to weiye;
sql>grant create session to weiye
sql>grant create table to weiye
sql>conn weiye/weiye
新建個表並insert幾條資料


2.模擬檔案丟失
關閉資料庫手動刪除資料檔案bobtest,重啟資料庫,如下報錯

3.執行修復
首先要通過alter database create datafile命令重建一個該檔案,可指定新路徑.
sql>alter database create datafile 'D:\oracle\product\10.2.0\oradata\bob\bobtest01.dbf' as 'D:\oracle\product\10.2.0\oradata\bob\bobtest01.dbf';
然後再
sql>recover datafile 8;
sql>alter database open;





期間我演示失敗,因為我用現有的老早建立的表空間bobtest來做演示,隨後在恢復的過程中,建立同名資料檔案時報錯

如上的演示成功的關鍵是:從建立時間起所有的重做日誌都在!老早前的bobtest建立的歸檔早就沒了,導致初次演示不成功.

最後重新建立新的表空間,建立新使用者,建立新表,由這些新生成的資訊來驗證上面的演示.

如上的演示成功的關鍵是:從建立時間起所有的重做日誌都在!
重建資料檔案後,通過recover命令應用所有的重做日誌檔案的方式,重建該資料檔案中的內容.

這次修復並沒用rman,屬於"使用者管理的備份和恢復",某些特殊情況下,使用者管理的備份和恢復還是有點優勢的.
如果想用rman處理如上問題:
rman>restore datafile 8;
預設情況下restore會將資料檔案修復到原來位置,如想恢復到其他位置,用set
rman>recover datafile 8;
rman>alter database open;



丟失控制檔案的恢復
nocatalog模式下,rman建立的備份都在目標資料庫的控制檔案中,一旦控制檔案丟失,不僅目標資料庫崩潰,rman的備份資訊也丟失,這種情況下,有控制檔案備份,還有救(沒有也有點希望:寫指令碼建立控制檔案)

恢復控制檔案之前,必須知道目標資料庫的DBID(本人的是13834161)

關閉資料庫,然後刪除控制檔案(作死,facebook),控制檔案丟了,也就能nomount了
sql>startup nomount
另開視窗連到rman並指定dbid
>rman target /
rman>set dbid=13834161
之前建立的備份都是nocatalog模式進行的,控制檔案丟失,一切配置都沒了,show all一下:都恢復成了預設值

顯式指定控制檔案備份集的方式恢復控制檔案:
rman>restore controlfile from 'D:\oracle\bobbackup\BOB_30_%P_C-13834161-20131230-14';
--指定控制檔案,要找個新一點的控制檔案,如果沒指定to字句,控制檔案會被恢復到初始化引數control_files指定的路徑下

rman>alter database mount;
rman>recover database;
rman>alter database open resetlogs;--由於是通過備份的控制檔案恢復,必須指定resetlogs


丟失聯機重做日誌檔案的恢復
聯機日誌正常情況下都有冗餘,丟了一個問題不大.

丟失非當前的聯機重做日誌檔案
sql>shutdown immediate
刪除online redo日誌組2——REDO02.LOG,REDO02A.LOG
sql>startup

sql>alter database clear logfile group 2;
sql>alter database open;
非當前聯機日誌損壞不一定導致資料庫崩潰,因為非當前日誌暫未用到,資料庫還能正常執行,但早晚會切到損壞日誌組,此時檔案無法訪問而導致報錯.


丟失當前的聯機重做日誌檔案(測試時我心裡都有些突突)
當前聯機重做日誌丟失,有備份也會丟失資料.

模擬檔案丟失
sql>shutdown abort
sql>startup mount;--同時刪除日誌組4的檔案
sql>alter database open;

嘗試直接修復聯機重做日誌檔案
sql>alter database clear logfile group 4;

根據錯誤可知,丟失的重做日誌檔案中包含必備的重做資訊,無法被clear

執行不完全恢復
歸檔模式而且有備份,正常情況下只丟失當前聯機重做日誌檔案中的資料,如果沒有備份,就只能強制恢復了,介紹一個
隱藏的初始化引數:
sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
_allow_resetlogs_corruption是一個隱藏引數,設定該引數為true後,oracle在open時會跳過一些一致性的檢查.

關閉並重啟到mount狀態:
sql>shutdown immediate
sql>startup mount
對資料庫進行不完全恢復:
sql>recover database until cancel;
輸入cancel
然後通過open resetlogs方式開啟資料庫:
sql>alter database open resetlogs;

善後處理:這種恢復方式比較極端,很有可能導致資料庫中資料不一致.alter日誌估計報很多錯誤,因此,一旦開啟了建議馬上通過export邏輯
匯出的方式執行一次full export,然後新建資料庫,再通過import匯入之前匯出的二進位制檔案.






































 


 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25025926/viewspace-1065705/，如需轉載，請註明出處，否則將追究法律責任。

相關文章