ora-00600 kccpb_sanity_check_2和kclchkblk_4的恢复case

前几天某客户的数据库出现异常，导致无法正常打开。实际上客户联系我们之前，他们已经联系过其他厂家进程了多次恢复。

从alert log 我们看到了几个常见的错误：

Starting up ORACLE RDBMS Version: 10.2.0.5.0.
System parameters with non-default values:
 processes                = 1000
 __shared_pool_size       = 436207616
 __large_pool_size        = 16777216
 __java_pool_size         = 16777216
 java_pool_size           = 0
 __streams_pool_size      = 0
 sga_target               = 1610612736
 control_files            = +DATA/mycim/controlfile/current.272.830788665
 db_block_size            = 8192
 __db_cache_size          = 1124073472
 compatible               = 10.2.0.5.0
 db_file_multiblock_read_count= 16
 cluster_database         = TRUE
 cluster_database_instances= 2
 db_create_file_dest      = +DATA
..........
Tue Jul 29 22:02:44 CST 2014
SUCCESS: diskgroup DATA was mounted
Tue Jul 29 22:02:48 CST 2014
Errors in file /u01/app/oracle/admin/mycim/udump/mycim1_ora_2047.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [529044], [529037], [0x000000000], [], [], [], []
Tue Jul 29 22:02:49 CST 2014
ORA-600 signalled during: ALTER DATABASE   MOUNT...
Tue Jul 29 22:02:49 CST 2014
Trace dumping is performing id=[cdmp_20140729220249]
Tue Jul 29 22:02:52 CST 2014
..........
Tue Jul 29 23:50:39 CST 2014
Errors in file /u01/app/oracle/admin/mycim/udump/mycim1_ora_13571.trc:
ORA-00600: internal error code, arguments: [kclchkblk_4], [5], [1536014502], [5], [1535605478], [], [], []
Tue Jul 29 23:50:42 CST 2014
Errors in file /u01/app/oracle/admin/mycim/udump/mycim1_ora_13571.trc:
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kclchkblk_4], [5], [1536014502], [5], [1535605478], [], [], []
Tue Jul 29 23:50:42 CST 2014
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 13571

对于第一个ora-00600 [kccpb_sanity_check_2] ，很明显是跟控制文件有关，关于这一点，Oracle mos文档有相关记录，如下：

Ora-00600: [Kccpb_sanity_check_2], [3621501],[3621462] On Startup [ID 435436.1]

该文档提到了该错误的原因如下：

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

针对该错误的解决方案很简单，如下：

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

查看日志我们发现还存在另外一个错误ora-00600 [kclchkblk_4]，很明显这个是跟数据块有关系的。最后我们发现也确实存在坏块。

其中我们通过隐含参数强制把库打开了，还用了event 10015等手段，甚至使用了*._minimum_giga_scn 参数。

当数据库打开之后，虽然还有一系列的报错，但是处理都相对简单了，这里不再累述。
该数据库不到100G，但是客户却没有完整的备份，貌似还是非归档，这确实不应该啊。