斷電與ORA-600錯誤處理

目 錄

斷電與ORA-600錯誤處理集合...................................................................................1
1. 前言.........................................................................................................................3
1.1. 概要說明...................................................................................................3
1.2. 常見步驟--METELINK上查詢...............................................................4
1.3. 控制文件問題...........................................................................................4
1.3.1. 現象ORA-600 [kccpb_sanity_check_2]............................................4
1.4. 數據文件問題...........................................................................................4
1.4.1. 現象ORA-600 [4000]........................................................................4
1.5. REDO文件問題........................................................................................5
1.5.1. 強制啓動報ORA-00600 [2662]........................................................5
1.5.2. 強制啓動報ORA-00600 [kcfnew_2]................................................6
1.5.3. REDO log問題導致ORA-600[kcrfr_update_nab_2]........................6
1.6. UNDO文件問題.......................................................................................6
1.6.1. 現象ORA-600 [4137] 或[4193]或 [4194].......................................6
1.7. 其他問題...................................................................................................7
1.7.1. ORA-00600 [kcratr1_lostwrt]............................................................7
1.7.2. ORA-00600 [19004]..........................................................................8
1.7.3. ORA-00600 [kddummy_blkchk].......................................................8
1.8. 非常規辦法...............................................................................................8 對本文相關問題如有疑問請聯繫

1. 前言

1.1. 概要說明
對於很多的數據庫系統，很多時候，沒有備份，沒有歸檔，這個時候如果斷電的話，而且系統開啓了異步IO的情況下，經常會導致數據庫無法啓動。
本文的目的就是解決斷電導致的無法啓動的問題。數據庫無法啓動到mount狀態，大部分都會出現ORA-600的錯誤，下面說明每一種ORA-600的錯誤，以及對應的解決辦法。
概要說明一下：數據庫有以下部分組成
(1) REDO LOG
(2) UNDO TABLESPACE
(3) TEMP TABLESPACE
(4) SYSTEM TABLESPACE 和 DATA TABLESPACE
(5) CONTROL FILE
如果某一個部分損壞，或者有問題，對應的解決辦法如下：
物理組成
解決辦法
(1) REDO
1. 通過_ALLOW_RESETLOGS_CORRUPTION強制啓動
2. 清空REDO LOG
(2) UNDO
1. 設置_corrupted_rollback_segments
2. 重建UNDO 表空間
(3) TEMP
1. 重建temp 表空間
(4) SYSTEM/DATA
1. _MINIMUM_GIGA_SCN = 2
2. alter session set events '10015 trace name adjust_scn level 1';
(5) CONTROL
1.2. 常見步驟--METELINK上查詢
由於ORA-600屬於內部錯誤，公佈的內容，在metelink上都有記錄辦法。如果有記錄辦法，都可以查詢得到，有時候，沒有可能找不到相關內容。
檢索辦法如下：

1.3. 控制文件問題
1.3.1. 現象ORA-600 [kccpb_sanity_check_2]
本問題是由於斷電導致控制文件的不一致，導致數據庫啓動到mount狀態就會報ORA-600錯誤。
解決辦法:重建控制文件就可以了。
某些特殊情況，會出現ORA-600[4000]的錯誤，這樣按照下面的ORA-600[4000]的處理方法處理就可以了。

1.4. 數據文件問題
1.4.1. 現象ORA-600 [4000]
解決辦法1：
(1) 查看Oracle告警日誌
Sun May 10 14:06:34 2009
SMON: enabling cache recovery
Sun May 10 14:06:34 2009
Errors in file /u01/app/oracle/admin/orcl/udump/orcl2_ora_21637.trc:
ORA-00600: internal error code, arguments: [4000], [6], [], [], [], [], [], []
(2) 按照告警日誌內容，檢索TRC文件，檢索下面類似的內容
Block header dump: 0x0040006e
Object id on Block? Y
seg/obj: 0x24 csc: 0x00.78f0a395 itc: 1 flg: - typ: 2 - INDEX
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.012.00001d26 0x00800cd9.132a.02 C--- 0 scn 0x0000.78f0a395
(3) 將相關紅色的數據轉換成10進制，並且除以1024*1024*1024
0x00.78f0a395 =>0x0078f0a395 => 2029036437 = 2029036437 /1024/1024/1024 = 1.8 =2
(4) 設置隱含參數
1. 修改此參數文件 _MINIMUM_GIGA_SCN = 2
2. startup mount;
3. recover database until cancel;(或者recover database)
4.alter database open resetlogs;
(必要時設置_ALLOW_RESETLOGS_CORRUPTION=TRUE 這個參數)
(5) 轉換成其它的ORA-600錯誤
可能會轉換爲 ORA-600[4137] 或者 ORA-600[4194] 的錯誤。
解決辦法2：
通過多次重啓數據庫，4000的錯誤，又可能轉換成其他的ORA-600的錯誤，然後對應的解決
解決辦法3：
通過BBED來找到數據塊，查找未提交的事務，修改相應的數據塊。

1.5. REDO文件問題
1.5.1. 強制啓動報ORA-00600 [2662]
(1) current日誌文件壞了,通過設置_ALLOW_RESETLOGS_CORRUPTION=true來強制啓動數據庫，這個時候會報ORA-00600 [2662]，這樣雖然數據庫啓動，但是數據庫內部可能有不一致現象，可以通過調整SCN來啓動。
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
或
alter session set events ‘10015 trace name ADJUST_SCN level 1047′;
(2) 如果繼續報2662錯誤，繼續使用下面的辦法
job_queue_processes=0; “_allow_resetlogs_corruption”=true “_allow_read_only_corruption”=true “_allow_terminal_recovery_corruption”=true
(3) 如果還繼續錯誤，那採用_minimum_giga_scn 這個參數
alter session set events ‘10015 trace name adjust_scn level 1
1.5.2. 強制啓動報ORA-00600 [kcfnew_2]
(1) 強制啓動，然後調整SCN
(1)設置_allow_resetlogs_corruption=true
然後數據庫啓動到mount狀態下,執行控制文件的恢復 recover database using backup controlfile until cancel; 提示時輸入cancel 或者recover database
alter database open resetlogs; alter session set events '10015 trace name adjust_scn level 1'; shutdown immediate alter database open
如果報其他ORA-600錯誤，依次處理。
1.5.3. REDO log問題導致ORA-600[kcrfr_update_nab_2]
(1) 通過設置_ALLOW_RESETLOGS_CORRUPTION=true強制啓動
(2) 不能啓動，重建控制文件，再次強制啓動
(3) 再不能啓動，通過alter system clear log group x的辦法，把redo log清空，防止對其他的影響，然後再強制啓動。
(4) 一般能正常啓動了，或者報ORA-600[4000]的錯誤。

1.6. UNDO文件問題
1.6.1. 現象ORA-600 [4137] 或[4193]或 [4194]
(1) 轉一般來說3000到4000之間的錯誤，都是由於undo表空間不一致導致的，解決起來相對簡單一些
(2) 發生了ORA-600錯誤後，檢查alert_orcl.log 一般情況下，有下面的類似的log，就表示有這些回滾段。
Undo Segment 11 Onlined Undo Segment 12 Onlined
Undo Segment 13 Onlined
(3) 或者查視圖得到
select segment_name from dba_rollback_segs
SYSTEM
_SYSSMU1$
_SYSSMU2$
_SYSSMU3$
_SYSSMU4$
_SYSSMU5$
_SYSSMU6$
_SYSSMU7$
_SYSSMU8$
_SYSSMU9$
_SYSSMU10$
(4) 設置隱含參數._corrupted_rollback_segments，比如
_corrupted_rollback_segments ='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$'
如果不能確定多少個，有時候dba_rollback_segs沒有查，可以窮舉的辦法，比如1-60個就足夠了，
(5) 修改undo_management 這個參數
把參數文件中的undo_management 改爲MANUAL
(6) 如果只是回滾段的問題，可以重建undo表空間就可以了。
SQL> create undo tablespace undotbs1 2 datafile '/opt/oracle/oradata/conner/undotbs1.dbf' size 10M; Tablespace created. SQL> alter system set undo_tablespace=undotbs1; System altered. SQL> drop tablespace undotbs2; Tablespace dropped.
(7) 如果是其他的ORA-600錯誤導致的undo問題，可以通過上述設定，啓動數據庫，然後導出數據，再重建數據庫。

1.7. 其他問題
1.7.1. ORA-00600 [kcratr1_lostwrt]
很多時候，由於斷電導致數據的錯誤，如報 ORA-00600 [kcratr1_lostwrt]
這個時候，只要簡單的恢復就可以了，但是爲了安全起見，做完立即備份

1.用sqlplusw /nolog 來以sysdba身份進行登陸
2.startup mount
3.先執行:recover database;
4.再執行:alter database open;
5.然後執行:shutdown immediate;
6.最後啓動數據庫即可:startup;
如果上述辦法能啓動，最好備份，某些情況會繼續出現ORA-00600: [13011]的錯誤這是索引不一致導致
1. 查詢user_index
2. 對所有index ANALYZE INDEX <index_name> VALIDATE STRUCTURE; 然後對有問題的index做drop&重建
1.7.2. ORA-00600 [19004]
本問題是無法入數據導致的內部錯誤，但數據能正常啓動。只要刪除Oracle的過期統計數據，就正常了
1.7.3. ORA-00600 [kddummy_blkchk]
設定alter system set db_block_checksum=off scope=both; 然後可能正常啓動了。

1.8. 非常規辦法
如果上述辦法都不能成功，或沒有任何解決辦法，可以採用ITPUB上提供的GDUL和ADUL,其中GDUL是不收費的，可以上google上檢索。只要有數據文件，系統表空間文件，就可以直接從數據文件中dump出數據。