ORA-00600: internal error code, arguments: [15709], [29], [1]-故障處理

tangyunoracle發表於2014-01-10
檢查日誌,發現兩次次當機前均出現ORACLE內部600錯誤 (ORA-00600 [15709] , [29], [1]),該錯誤是由於資料庫發生並行回滾觸發了Oracle Bug 6954722。檢查alert日誌及資料庫回滾資訊,發現確實有大量的資料回滾。

日誌分析:
--First Crash
Wed Jan  8 12:08:51 2014
Errors in file /oracle/products/admin/szdm/bdump/szdm_smon_762530.trc:
ORA-00600: internal error code, arguments: [15709], [29], [1], [], [], [], [], []
ORA-30319: Message 30319 not found;  product=RDBMS; facility=ORA
Wed Jan  8 12:08:58 2014
Fatal internal error happened while SMON was doing active transaction recovery.
Wed Jan  8 12:08:58 2014
Errors in file /oracle/products/admin/szdm/bdump/szdm_smon_762530.trc:
ORA-00600: internal error code, arguments: [15709], [29], [1], [], [], [], [], []
ORA-30319: Message 30319 not found;  product=RDBMS; facility=ORA
SMON: terminating instance due to error 474
Termination issued to instance processes. Waiting for the processes to exit

--Second Crash
Wed Jan  8 16:11:13 2014
Completed checkpoint up to RBA [0xc7b41.2.10], SCN: 319187804449
Wed Jan  8 16:11:24 2014
Errors in file /oracle/products/admin/szdm/bdump/szdm_smon_816146.trc:
ORA-00600: internal error code, arguments: [15709], [29], [1], [], [], [], [], []
ORA-30319: Message 30319 not found;  product=RDBMS; facility=ORA
Wed Jan  8 16:11:30 2014
Fatal internal error happened while SMON was doing active transaction recovery.
Wed Jan  8 16:11:30 2014
Errors in file /oracle/products/admin/szdm/bdump/szdm_smon_816146.trc:
ORA-00600: internal error code, arguments: [15709], [29], [1], [], [], [], [], []
ORA-30319: Message 30319 not found;  product=RDBMS; facility=ORA
SMON: terminating instance due to error 474
Termination issued to instance processes. Waiting for the processes to exit
Wed Jan  8 16:11:40 2014

metalink:
Solution :
To implement solution for unpublished Bug: 6954722, please execute one of the following steps:
1. Use the following workaround
Set fast_start_parallel_rollback=false and recovery_parallelism=0
Setting fast_start_parallel_rollback=false and recovery_parallelism=0 simply tells Oracle to recover failed/aborted transaction in serial mode. THere is not harm in setting these as that should not be a common operation。

透過查詢確認發現大量的事務在回滾:
select * from V$FAST_START_TRANSACTIONS;
根據以上分析結果可以確認異常當機的原因是由於使用者大量資料並行回滾導致觸發Oracle Bug 6954722導致。

透過檢視當前資料庫的引數設定為:
recovery_parallelism=20
fast_start_parallel_rollback=LOW

根據metalink的建議將資料庫引數修改,規避該Bug的問題出現。
recovery_parallelism=0
fast_start_parallel_rollback=false

=============End==============================

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

相關文章