ora-00600 kccpb_sanity_check_2和kclchkblk_4的恢复case
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
前几天某客户的数据库出现异常，导致无法正常打开。实际上客户联系我们之前，他们已经联系过其他厂家进程了多次恢复。
从alert log 我们看到了几个常见的错误：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
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 2 3 4 5 6 7 8 9 |
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，但是客户却没有完整的备份，貌似还是非归档，这确实不应该啊。
Leave a Reply
You must be logged in to post a comment.