我對Oracle RMAN恢復的理解.doc

我對Oracle RMAN恢復的理解零散思路：可能遇到的恢復情況：因為數(shù)據(jù)庫無法啟動或正常使用需要恢復；因為數(shù)據(jù)誤刪除或表空間、表的誤刪除等需要將數(shù)據(jù)庫或其中某表空間、表或表中數(shù)據(jù)恢復到過去某時間點；RMAN恢復原則：恢復不外乎就是恢復如下一些文件：數(shù)據(jù)文件（也有可能是表空間），控制文件，歸檔日志文件（見后面關于歸檔日志恢復部分），在線日志文件，初始化參數(shù)文件，全庫恢復需要在MOUNT狀態(tài)下，表空間或數(shù)據(jù)文件的恢復可以在OPEN狀態(tài)下進行，控制文件歸檔日志文件在線日志文件初始化參數(shù)文件常用的恢復命令：/對數(shù)據(jù)庫進行完全介質(zhì)恢復歸檔模式，控制文件、初始化參數(shù)文件、歸檔日志文件和重做日志文件都完好無損，其余數(shù)據(jù)文件全部丟失，可將數(shù)據(jù)庫恢復到崩潰前那一刻的狀態(tài)：Rmanstartup mount;Rmanrestore database;Rmanrecover database delete archivelog;Rmanalter database open;？那以上情況下，非歸檔模式應如何處理？這種情況下感覺應該有幾種情況：首先非歸檔模式下的備份只可能是一致性備份，而且非歸檔模式下沒有歸檔日志，因此恢復時要考慮最近一次備份和數(shù)據(jù)庫崩潰期間的在線日志文件是否都還在，如果在則直接執(zhí)行restore和recover然后正常打開數(shù)據(jù)庫即可，而如果在線日志文件已經(jīng)部分或全部丟失，則首先restore最近一次備份，然后執(zhí)行recover database until cancel命令，據(jù)說此時該命令并不會執(zhí)行任何恢復操作，只是提示控制文件不再使用原有重做日志，最后以resetlogs方式打開數(shù)據(jù)庫。在三思的書中，文字性提到了一種方法：首先恢復之前備份的控制文件，然后執(zhí)行restore和recover命令，最后以resetlogs方式打開數(shù)據(jù)庫。感覺這種方式很有道理而前一種思路似乎有問題：前一種思路中實際是用當前的控制文件在進行恢復操作，而當前的控制文件很有可能有前次備份中所不具有的新加的數(shù)據(jù)文件，那么這樣在備份的時候是不是會出問題呢？ 以上都需要具體驗證！/恢復表空間和數(shù)據(jù)文件mount或open狀態(tài)都可Tablespace:Rmansql alter tablespace tbs1 offline immediate;Rmanrestore tablespace tbs1;Rmanrecover tablespace tbs1;Rmansql alter tablespace tbs1 online;Datafile:Rmansql alter database datafile 9 offline;Rmanrestore datafile 9;Rmanrecover datafile 9;Rmansql alter datafile 9 online;或Rmanset newname for datafile 3 to f:newlocationsysaux01.dbf;Rmanrestore datafile 3;Rmanswitch datafile 3;Rmanrecover datafile 3;/恢復歸檔日志文件特別：三思告訴我們：“恢復歸檔文件也是使用restore命令，如果只是為了在恢復數(shù)據(jù)文件后應用歸檔文件，那并不需要手動歸檔文件進行恢復，RMAN會在recover的時候自動對適當?shù)臍w檔進行恢復。單獨恢復歸檔文件一般是有特別的需求，如創(chuàng)建了Data Guard環(huán)境，Standy端丟失了部分歸檔文件，必須從Primary端重新獲取等等?！?恢復控制文件這里所說的恢復是指僅恢復控制文件本身，應該還有一種“基于控制文件的不完全恢復”，不知和這種情況是否相同（當所有控制文件全部丟失或者誤刪除了表空間時（閃回數(shù)據(jù)庫能辦到嗎？），需要執(zhí)行控制文件的恢復）。其實本身是一種解決方案下的多種情況： 情景1：歸檔、有恢復目錄、控制文件全部丟失或部分數(shù)據(jù)文件或表空間丟失情景2：歸檔、無恢復目錄、控制文件全部丟失或部分數(shù)據(jù)文件或表空間丟失前景3：非歸檔、有恢復目錄、控制文件全部丟失或部分數(shù)據(jù)文件或表空間丟失情景4：非歸檔、無恢復目錄、控制文件全部丟失或部分數(shù)據(jù)文件或表空間丟失1、 從自動備份中恢復Rmanset DBID=1415261003;Rmanstartup nomount;Rmanrestore controlfile from autobackup;Rmanalter database mount;(Rmanrestore controlfile to d:oraclenewctlfcontrolfile01.ctl from autobackup;恢復到指定位置)Rmanrecover database;Rmanalter database open resetlogs;2、 從備份集中恢復Rmanset DBID=1415261003;Rmanstartup nomount;Rmanrestore controlfile from d:backupc-1415261003-20110522-00;(Rmanrestore controlfile to d:oraclenewctlfcontrolfile01.ctl from autobackup;恢復到指定位置)Rmanalter database mount;Rmanrecover database;Rmanalter database open resetlogs;/恢復初始化參數(shù)文件(方法基本與控制文件的恢復相同)Rman set DBID=1415261003;Rmanstartup nomount;Rmanrestore spfile from autobackup;Rmanalter database mount;Rmanrecover database;/恢復聯(lián)機重做日志文件0、 查詢聯(lián)機日志狀態(tài)情況v$log中記錄聯(lián)機重做日志組的信息；v$logfile中記錄聯(lián)機重做日志組對應的日志文件；SQLselect group#, thread#, sequence#, members, archived, status from v$log;SQLselect group#, member from v$logfile;1、 日志組中的某個日志成員損壞多元化重做日志的目的就是為了防止日志成員的介質(zhì)失敗。如果某個日志組的一個日志成員出現(xiàn)介質(zhì)失敗，那么數(shù)據(jù)庫仍然可以正常工作。首先查詢：SQLselect member from v$logfile where status=INVALID;然后使用alter database drop logfile member命令刪除該日志成員，注意，如果出現(xiàn)損壞的日志成員是當前日志組的日志成員，那么該日志成員將不能被刪除，需要進行手工的切換：SQLalter system switch logfile;SQLalter database drop logfile member c:orclredo01_2.log;在刪除了日志成員之后，需要為該日志組添加新的日志成員，注意新增加的日志成員狀態(tài)也為INVALID：SQLalter database add logfile member c:orclredo01_3.log to group 1;2、 丟失非當前的聯(lián)機重做日志文件先查詢出丟失的聯(lián)機重做日志文件組及其包含的聯(lián)機重做日志文件然后修復：SQLalter database clear logfile group 1;該命令重建該組重做日志文件即可。特別！在精通Oracle 10g備份與恢復一書中關于此部分的介紹分類更細：(1)、在OPEN狀態(tài)下非活動日志組的所有日志成員全部損壞出現(xiàn)此種情況，數(shù)據(jù)庫仍然正常工作，只是當切換到該日志組時，因為其內(nèi)容不能被歸檔，所以后臺進程LGWR會處于等待狀態(tài)。為了使得后臺進程LGWR可以繼續(xù)工作，DBA應該清楚該日志組(我理解此種情景是針對歸檔模式而言的，非歸檔模式?jīng)]得這種問題)：SQLalter database clear unarchived logfile group 1;(2)、在關閉狀態(tài)下非活動日志組的所有日志成員全部損壞新增加新的日志組，刪除原有日志組，然后打開數(shù)據(jù)：SQLalter database add logfile (d:orclredo04_1.log, c:orclredo04_2.log) size 10M;SQLalter database drop logfile group 1;SQLalter database open;3、 丟失當前的聯(lián)機重做日志文件此種情況下不能直接重建，而是應該執(zhí)行不完全恢復需要修改一個隱藏的初始化參數(shù)：SQLalter system set “_ALLOW_RESETLOGS_CORRUPTION”=TRUE SCOPE=SPFILE;該參數(shù)設為TRUE時，Oracle在OPEN時會跳過一些一致性的檢查。特別！在精通Oracle 10g備份與恢復一書中關于此部分的介紹分類更細：(1)、在OPEN狀態(tài)下當前日志組的所有日志成員全部損壞當數(shù)據(jù)庫處于OPEN狀態(tài)時，如果當前日志組的所有日志成員全部損壞，那么當后臺進程LGWR將事物寫入該日志組時，實例會被自動關閉，并報錯。出現(xiàn)這種情況下，需要執(zhí)行不完全恢復：RMANstartup mount;RMANrestore database;RMANrecover database until cancel;RMANalter database open resetlogs;(2)、在關閉狀態(tài)下當前日志組的所有日志成員全部損壞當在關閉狀態(tài)下當前日志組出現(xiàn)損壞時，因為數(shù)據(jù)文件、控制文件都處于完全一致狀態(tài)，所以DBA只需要執(zhí)行基于CANCEL的不完全恢復即可：RMANstartup mount;RMANrecover database until cancel;RMANalter database open resetlogs;/RMAN不完全恢復0、 執(zhí)行不完全恢復后，因為要以resetlogs方式打開數(shù)據(jù)庫，而此時會重新建立重做日志，清空原有重做日志的內(nèi)容（同時歸檔日志也全部刪除了），而且過去的備份也不能直接使用了（但好像聽說從Oracle Database 10g開始，Oracle提供了新的安全機制可以確保歸檔日志不會被覆蓋，從而使得在恢復數(shù)據(jù)庫時可以使用早期數(shù)據(jù)庫副本的備份），因此強烈建議讀者刪除早期所有的備份，并重新備份數(shù)據(jù)庫：RMANrundelete noprompt backup;delete noprompt copy;backup database format=d:backup%d_%s.bak;sql alter system archive log current;1、 基于時間恢復基于時間點恢復是指當出現(xiàn)用戶錯誤（例如誤刪除表、誤截斷表等）時，先使用restore database命令轉(zhuǎn)儲所有數(shù)據(jù)文件備份，再使用recover database命令將數(shù)據(jù)庫恢復到用戶錯誤點的狀態(tài)，從而恢復用戶數(shù)據(jù)。(有時需要結合LogMiner來確定誤操作時間點)RMANrunstartup force mount;set until time=2011-05-22 22:03:00;restore database;recover database;sql alter database open resetlogs;2、 基于SCN恢復RMANrunstartup force mount;set until scn=511927;restore database;recover database;sql alter database open resetlogs;3、 基于日志序列號恢復RMANrunstartup force mount;set until sequence=6;restore database;recover database;sql alter database open resetlogs;4、 基于備份控制文件恢復RMANstartup force nomount;RMANset dbid=123456;RMANrestore controlfile form autobackup;RMANalter database mount;RMANrunset until time=2011-05-22 22:39:00;restore database;recover database;sql alter database open resetlogs;/恢復訛誤的數(shù)據(jù)塊(block media recovery,簡寫為BMR)當我們訪問某個數(shù)據(jù)文件發(fā)現(xiàn)其出現(xiàn)數(shù)據(jù)塊訛誤時，例如如下錯誤消息：ORA-01578：ORACLE data block corrupted (file # 19, block # 44)ORA-01110：data file 19: d:oracleoradatadatamydb_maintbs_01.dbf如果沒有BMR，我們必須從一個備份中恢復這個數(shù)據(jù)文件，關鍵是在恢復過程中用戶不能使用該數(shù)據(jù)文件中的數(shù)據(jù)，相反使用BMR只恢復訛誤的數(shù)據(jù)塊，這時需要使用blockrecover命令：blockrecover datafile 19 block 44;如果有必要，可以同時恢復多個數(shù)據(jù)文件中的多個數(shù)據(jù)塊：blockrecover datafile 19 block 44,66,127blockrecover datafile 19 block 44 datafile 22 block 203;/恢復到以前的Incarnation我們可能面臨到的一種情況是：需要使用上次執(zhí)行resetlogs命令打開數(shù)據(jù)庫前生成的一個備份來還原數(shù)據(jù)庫，或者可能需要還原到執(zhí)行上一個resetlogs命令之前的時間點。這種恢復在是否使用來恢復目錄時存在差別，原因很顯然：恢復目錄能夠永久（至少是長時間）保存控制文件和備份信息，當然也就包括來所記錄的各個版本的Incarnation；而僅使用控制文件時，我們看到的控制文件肯定是當前的版本，有可能稍早的備份或者Incarnation信息已經(jīng)被覆蓋，所以要恢復當前控制文件中已經(jīng)沒有的Incarnation，則首先需要從備份中還原出包含相應Incarnation的控制文件。前提假設：并且最近使用resetlogs命令執(zhí)行過時間點恢復?，F(xiàn)在需要使用執(zhí)行resetlogs命令之前一個備份來恢復數(shù)據(jù)庫。1、 使用恢復目錄恢復前一個IncarnationRMANlist incarnation;List of Database IncarnationsDB Key Inc key DB Name DB ID CUR Reset SCN Reset Time- - - - - - - -1 2 RECOVER 2539725638 NO 763059 08-JUL-021 123 RECOVER 2539725638 YES 764905 09-JUL-02RMANstartup force nomount;RMANreset database to incarnation 2;database reset to incarnation 2 in recovery catalogRMANrestore controlfile;Finished restore at 10-JUL-02RMANalter database mount;database mountedRMANrestore database until scn 764904;Finished restore at 10-JUL-02RMAN recover database until scn 764904;starting media recoveryFinished restore at 10-JUL-02RMANalter database open resetlogs;new incarnation of database registerd in recovery catalogstarting full resync of recovery catalogfull resync completeRMANlist incarnation;List of Database IncarnationsDB Key Inc key DB Name DB ID CUR Reset SCN Reset Time- - - - - - - -1 2 RECOVER 2539725638 NO 763059 08-JUL-021 123 RECOVER 2539725638 NO 764905 09-JUL-021 245 RECOVER 2539725638 YES 764905 10-JUL-022、 不使用恢復目錄恢復前一個IncarnationRMANlist incarnation of database;List of Database IncarnationsDB Key Inc key DB Name DB ID STATUS Reset SCN Reset Time- - - - - - - - -1 1 RECOVER 2539725638 PARENT 1 30-AUG-052 2 RECOVER 2539725638 PARENT 534907 03-OCT-053 3 RECOVER 2539725638 PARENT 3586765 04-FEB-064 4 RECOVER 2539725638 PARENT 3599781 05-FEB-065 5 RECOVER 2539725638 PARENT 3715262 08-FEB-066 6 RECOVER 2539725638 CURRENT 4296046 20-FEB-06RMANshutdown immediate;RMANstartup mount;RMANreset database to incarnation 5;RMANrestore database until scn 4296041;RMANrecover database un