昨天遇到一個斷電導致oracle異常的案例，記錄一下：

客戶方有同事不懂數據庫，直接將裝有oracle雙機的兩臺服務器直接先后斷電，等待幾分鐘再重新啟動兩臺服務器，結果后來oracle在啟動的時候報如下錯誤：

Mon Oct 17 17:23:08 2011

Errors in file /founder/oracle/admin/bzdb/udump/bzdb_ora_23965.trc:

ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [127404], [127399], [0x000000000], [], [], [], []

ORA-600 signalled during: ALTER DATABASE MOUNT...

查了下資料，原因和解決方法如下：

Cause

[kccpb_sanity_check_2] indicates that the seq# of the last read block is higher than the seq# of the control file header block. This is indication of the lost write of the header block during commit of the previous cf transaction.

Solution

1) restore a backup of a controlfile and recover

OR

2) recreate the controlfile

OR

3) restore the database from last good backup and recover

因為這個災備數據庫不是很關鍵很重要的，客戶要求沒有啟用歸檔，有個4月份的冷備，和客戶方商量后決定先試試重建控制文件；

數據庫沒有控制文件備份，只能nomount，執行alter database mount的時候報錯，所以沒法接著alter database backup controlfile to trace;

于是從alter告警文件里找尋最近成功啟動數據庫的相關記錄信息，摘錄如下，編寫出重建控制文件的腳步create_ctrl.sql，

sqlplus / as sysdba;

直接運行該重建控制文件腳步，數據庫成功open。

create_ctrl.sql

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "bzdb" RESETLOGS

MAXLOGFILES 5

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

GROUP 1 ('/oracle/oradata/db/redo01.log') SIZE 51200K,

GROUP 2 ('/oracle/oradata/db/redo02.log') SIZE 51200K,

GROUP 3 ('/oracle/oradata/db/redo03.log') SIZE 51200K

DATAFILE

'/oracle/oradata/db/system01.dbf',

'/oracle/oradata/db/undotbs01.dbf',

'/oracle/oradata/db/sysaux01.dbf',

'/oracle/oradata/db/users01.dbf',

'/oracle/oradata/db/temp01.dbf',

......

CHARACTER SET AL32UTF8;

ALTER DATABASE MOUNT;

RECOVER DATABASE;

ALTER DATABASE OPEN NORESETLOGS;

總結

以上是生活随笔為你收集整理的oracle 00600 kccpb,ORA-00600: [kccpb_sanity_check_2]报错处理一则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。