損壞后恢復數據庫

1、Current Redo log損壞后恢復數據庫禤梓橋 00109548關鍵字： 10513事件，_allow_resetlogs_corruption，_corrupted_rollback_segments，dba_rollback_segs，ORA-6002662，ORA-6002663，ORA-6004136。適用場景： 1. 當前redo log文件發(fā)生物理或邏輯損壞；且沒有可用的redo log備份； 2. 沒有可用于恢復的備份； 3. rman恢復時間過長或備份太舊，不滿足業(yè)務快速恢復的要求。如何判定損壞日志狀態(tài)為CURRENT： 1. 以startup啟動后，檢查alert日志

2、，從”Started redo scan”日志信息開始如下類似的錯誤信息：Started redo scanORA-00313: 無法打開日志組 3 (用于線程 1) 的成員ORA-00312: 聯機日志 3 線程 1: 'F:APPX00109548ORADATAORCLREDO03.LOG'ORA-27041: 無法打開文件OSD-04002: 無法打開文件O/S-Error: (OS 2) 系統(tǒng)找不到指定的文件。Aborting crash recovery due to error 313或者Started redo scanORA-368 signalled duri

3、ng: ALTER DATABASE OPEN.注意：如果alert只有ORA-368錯誤，沒有報告具體的redo log文件時，需要先按照損壞redo log文件狀態(tài)為非current的辦法處理，當無法恢復數據庫時，才按以下恢復步驟嘗試恢復。 2. 在startup啟動報錯后，此時數據庫處于MOUNT狀態(tài)，查看損壞的文件狀態(tài)是否為CURRENT：SQL>select member, l.status, l.group# from v$log l, v$logfile f where l.group#=f.group#;MEMBER STATUS GROUP#- - -F:APPX001

4、09548ORADATAORCLREDO01.LOG INACTIVE 1F:APPX00109548ORADATAORCLREDO02.LOG INACTIVE 2F:APPX00109548ORADATAORCLREDO03.LOG CURRENT 3恢復步驟： 確認損壞redo log文件為current時，執(zhí)行以下操作：步驟1：將spfile轉存為pfile.ora，并在pfile.ora文件中添加_allow_resetlogs_corruption=true。1.1轉存spfileSQL>create pfile='d:pfile.ora' from spfi

5、le;編輯d:pfile.ora文件，添加如下參數：*._allow_resetlogs_corruption=true1.2正常關閉數據庫SQL>shutdown immediate;步驟2：以pfile文件啟動實例并將數據庫掛載SQL>startup pfile='d:pfile.ora' mount;步驟3：執(zhí)行recover database until cancel，并輸入cancelSQL>recover database until cancel;ORA-00279: 更改 1546960 (在 10/17/2012 09:26:37 生成) 對

6、于線程 1 是必需的ORA-00289: 建議:F:APPX00109548PRODUCT11.1.0DB_1RDBMSARC00048_0796850999.001ORA-00280: 更改 1546960 (用于線程 1) 在序列 #48 中指定日志: <RET>=suggested | filename | AUTO | CANCELcancel <-手工輸入cancelORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 將出現如下錯誤ORA-01194: 文件 1 需要更多的恢復來保持一致性ORA-01110: 數據文件 1: '

7、;F:APPX00109548ORADATAORCLSYSTEM01.DBF'注意：此時可能會報告SYSTEM系統(tǒng)表空間數據文件需要恢復，可以忽略此錯誤。步驟4：以open resetlogs打開數據庫SQL>alter database open resetlogs; 注意：1.此時可能打不開數據庫，或者打開數據庫后alert日志有ORA-6002662、ORA-6002663、ORA-6004136、ORA-6004194、ORA-6004197等錯誤。ORA-6002662、ORA-6002663等錯誤通常是因為在實例崩潰時事務已經將數據塊寫入到數據文件中。ORA-6002

8、023、ORA-6004136、ORA-6004194、ORA-6004197等錯誤是因為undo表空間中的數據需要恢復。 2. 如果SYSTEM表空間的數據損壞，將無法恢復數據庫， 如果是業(yè)務用的數據文件， 考慮刪除這些損壞的文件后，接著按以下操作執(zhí)行。 步驟5：在pfile.ora文件中增加如下參數并MOUNT數據庫編輯d:pfile.ora文件，添加和修改如下參數：*.event='10513 trace name context forever,level 2'undo_management=manual <-此處將auto修改為manualSQL>star

9、tup pfile='d:pfile.ora' mount注意：startup restrict模式無法打開數據庫。步驟6：執(zhí)行recover database操作，并打開數據庫(recover database驗證數據庫文件是否有問題，可不做)SQL>recover database;完成介質恢復。SQL>alter database open; <-此時要以正常方式打開此時alert日志應該沒有報錯的情況步驟7：需要用exp命令備份業(yè)務數據(命令步驟不詳細列出)，同時檢查dba_rollback_segs表中的回滾段狀態(tài)SQL> select seg

10、ment_name, tablespace_name, status from dba_rollback_segs;SEGMENT_NAME TABLESPACE_NAME STATUS - - - SYSTEM SYSTEM ONLINE _SYSSMU22_1350439519$ UNDOTBS1 OFFLINE _SYSSMU21_1350439519$ UNDOTBS1 OFFLINE _SYSSMU20_1350439519$ UNDOTBS1 NEEDS RECOVERY _SYSSMU19_1350439519$ UNDOTBS1 OFFLINE _SYSSMU18_135043

11、9519$ UNDOTBS1 OFFLINE _SYSSMU17_1350439519$ UNDOTBS1 OFFLINE _SYSSMU16_1350439519$ UNDOTBS1 OFFLINE _SYSSMU15_1350439519$ UNDOTBS1 OFFLINE _SYSSMU14_1350439519$ UNDOTBS1 OFFLINE _SYSSMU13_1350439519$ UNDOTBS1 OFFLINE _SYSSMU12_1350439519$ UNDOTBS1 OFFLINE 注意：1. 當exp命令在執(zhí)行過程中報ORA-01555錯誤時，此時不要試著將UNDO

12、TBS1空間擴大，這是因為實例崩潰時數據庫中未提交事務占用了大量的回滾段，在打開數據庫后undo表空間仍然有數據需要恢復，即使UNDOTBS1表空間增大，這些可用空間依然不能使用。2.UNDOTBS1表空間中存在NEEDS RECOVERY的回滾段需要記錄到pfile中，并要重建該undo表空間。步驟8：設置參數記錄損壞的回滾段，重啟后刪除并重建UNDOTBS1表空間8.1 編輯d:pfile.ora文件，添加如下參數：*._corrupted_rollback_segments='_SYSSMU20_1350439519$' #上述查詢中NEEDS RECOVERY狀態(tài)的回滾

13、段，如果有多個需要記錄的回滾端，設置形式為：*._corrupted_rollback_segments='SEGMENT_NAME1', 'SEGMENT_NAME2',8.2 正常關閉數據庫SQL>shutdown immediate;8.3 重啟數據庫SQL>startup pfile='d:pfile.ora'8.4 刪除UNDOTBS1表空間SQL>drop tablespace undotbs1 including contents and datafiles;8.5 重建UNDOTBS1表空間(以下僅是樣例)SQL

14、>create undo tablespace undotbs1 datafile 'F:appx00109548oradataorclundotbs1.dbf' size 8192m;步驟9：關閉數據庫，以原來的spfile參數文件正常啟動數據庫SQL>shutdown immediate;SQL>startup;小結： 1. 在步驟4打開數據庫時，如果沒有ORA-6002662，ORA-6002663，ORA-6004136等錯誤，那么不需要執(zhí)行步驟56的操作。這通常是事務中DML操作的數據塊沒有寫到數據文件，而是在buffer cache中，因此不需要設

15、置10513事件和_corrupted_rollback_segments，這時按照步驟9操作，觀察是否能正常打開、是否有相應的ORA-600錯誤，如果沒有即可正常使用。 2. 在步驟5必須將undo_management修改為manual，否則在dba_rollback_segs表中可能無法展現有問題的回滾段，從而在數據庫正常運行中報ORA-6002023和ORA-6004136錯誤。3. 當在恢復過程中發(fā)生ORA-6002662、ORA-6002663錯誤，不論回滾段是否有損壞的情況，建議都重建undo表空間，避免在業(yè)務正常運行時發(fā)生ORA-01555錯誤。 Redo log損壞驗證： 1

16、. 在正常的數據庫中創(chuàng)建一張小數據表t_smalltable，模擬DML操作時，數據塊完全在buffer cache的情況 1.1建立t_smalltable表和索引SQL>create table t_smalltable as select * from all_objects; SQL>create index ix_smalltable_objectid on t_smalltable(object_id); 1.2 模擬未提交事務SQL>update t_smalltable set owner=lower(owner);1.3 在另一個窗口,以sys用戶登錄將數據庫強行關閉SQL>conn / as sysdbaSQL>shutdown abort;1.4將操作系統(tǒng)上的所有重做日志刪除2. 在正常的數據庫中創(chuàng)建一張大數據表t_bigtable，模擬DML操作時，有部分數據塊寫到磁盤的情況 2.1建立t_bigtable表SQL>create table t_bigtable as select * from all_objects; SQL>begin for i in 1.10 loop insert into t