数据恢复:ORA-600 kccpb_sanity_check_2解决

最近在客户的数据库恢复中再次遇到了ORA-00600 kccpb_sanity_check_2错误，这个错误是因为控制文件不一致导致的。

出现这个错误时，数据库将无法Mount挂载，影响数据库服务。
这个错误，多数是因为存储故障，丢失了数据写。

Oracle对此错误的解释是：

[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.

其解释是：kccpb_sanity_check_2 表示最后读取的控制文件块其 seq# 控制序列号大于控制文件头块的 seq# ,这是不应该出现的情况。这说明在最后执行提交的控制文件事务（CF Transaction）中，对于头块的写入丢失了。

这个错误如果只是存在于控制文件上，可以通过重建控制文件来解决，毫无疑问，这是最为简单的处理方式。
如果有备份，也可以从备份中恢复完好的控制文件，但是重建通常是很快捷的方式。

如何重建控制文件，请参考：
http://www.eygle.com/archives/2004/10/backup_and_recreate_controlfile.html

以下是一些错误的记录：

Fri Jan 16 10:47:45 2009
alter database mount
Fri Jan 16 10:47:50 2009
Errors in file /u01/app/oracle/admin/SZFDB/udump/szfdb_ora_7805.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1449], [1448], [0x000000000], [], [], [], []
Fri Jan 16 10:47:51 2009
ORA-600 signalled during: alter database mount...
Fri Jan 16 10:58:50 2009
alter database mount
Fri Jan 16 10:58:54 2009
Errors in file /u01/app/oracle/admin/SZFDB/udump/szfdb_ora_9233.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1449], [1448], [0x000000000], [], [], [], []

案例二：

Mon Aug 27 19:15:26 2007
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows Server 2003 Version V5.2 Service Pack 2
CPU                 : 2 - type 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:2673M/3035M, Ph+PgF:4701M/4926M, VA:1938M/2047M
Mon Aug 27 19:15:26 2007
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Mon Aug 27 19:15:37 2007
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
  processes                = 150
  __shared_pool_size       = 230686720
  __large_pool_size        = 4194304
  __java_pool_size         = 4194304
  __streams_pool_size      = 0
  sga_target               = 612368384
  control_files            = E:\\DB_SERVER_GROUP\\ORACLE\\PRODUCT\\10.2.0\\ORADATA\\ADB\\CONTROLFILE\\O1_MF_3B37YF0H_.CTL, E:\\DB_SERVER_GROUP\\ORACLE\\PRODUCT\\10.2.0\\FLASH_RECOVERY_AREA\\ADB\\CONTROLFILE\\O1_MF_3B37YF8S_.CTL
  db_block_size            = 8192
  __db_cache_size          = 364904448
  compatible               = 10.2.0.1.0
  db_file_multiblock_read_count= 16
  db_create_file_dest      = E:\\DB_Server_Group\\Oracle\\product\\10.2.0\\oradata
  db_recovery_file_dest    = E:\\DB_Server_Group\\Oracle\\product\\10.2.0\\flash_recovery_area
  db_recovery_file_dest_size= 21474836480
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  dispatchers              = (PROTOCOL=TCP) (SERVICE=adbXDB)
  job_queue_processes      = 10
  audit_file_dest          = E:\\DB_SERVER_GROUP\\ORACLE\\PRODUCT\\10.2.0\\ADMIN\\ADB\\ADUMP
  background_dump_dest     = E:\\DB_SERVER_GROUP\\ORACLE\\PRODUCT\\10.2.0\\ADMIN\\ADB\\BDUMP
  user_dump_dest           = E:\\DB_SERVER_GROUP\\ORACLE\\PRODUCT\\10.2.0\\ADMIN\\ADB\\UDUMP
  core_dump_dest           = E:\\DB_SERVER_GROUP\\ORACLE\\PRODUCT\\10.2.0\\ADMIN\\ADB\\CDUMP
  db_name                  = adb
  open_cursors             = 300
  pga_aggregate_target     = 203423744
PSP0 started with pid=3, OS id=2396
PMON started with pid=2, OS id=2392
MMAN started with pid=4, OS id=2400
DBW0 started with pid=5, OS id=2404
LGWR started with pid=6, OS id=2408
CKPT started with pid=7, OS id=2412
SMON started with pid=8, OS id=2416
RECO started with pid=9, OS id=2420
CJQ0 started with pid=10, OS id=2424
MMON started with pid=11, OS id=2432
Mon Aug 27 19:15:54 2007
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=2444
Mon Aug 27 19:15:54 2007
starting up 1 shared server(s) ...
Mon Aug 27 19:16:00 2007
alter database mount exclusive
Mon Aug 27 19:16:07 2007
Errors in file e:\\db_server_group\\oracle\\product\\10.2.0\\admin\\adb\\udump\\adb_ora_2472.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1558], [1423], [0x0], [], [], [], []

Mon Aug 27 19:16:40 2007
ORA-600 signalled during: alter database mount exclusive...

适当的备份控制文件的创建语句，在恢复时可能会起到很大的帮助作用。