kccpb_sanity_check2

背景：

一个小系统，9月14号存储控制器和硬盘发生故障，两台AIX主机均丢失了hdisk2 3 4，数据库环境当掉；

21号存储恢复工作结束晚上，AIX主机识别出了三块磁盘；

数据库集群件可以启动，数据库不能启动，报600错；

ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [346397], [346390], [0x000000000], [], [], [], []

kccpb_sanity_check_2的相关资料如下：

MetaLink上Oracle对kccpb_sanity_check_2的解释为:

The ORA-600 [kccpb_sanity_check_2] is reported when the SCN in the controlfile header is lower than the SCN in a controlfile block. 或者

The ORA-600 [kccpb_sanity_check_2] indicates that the seq# of the last read block is higher than the seq# of the control file header block.

可通过下列三种方法解决:

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

可参考MetaLink:435436.1,833115.1

[@more@]

NOTE:

If you do not have any special backup of control file to restore and you are using Multiple Control File copies in your pfile/init.ora/spfile you can attempt to mount the database using each control file one by one. If you are able to mount the database with any of these control file copies you can then issue 'alter database backup controlfile to trace' to recreate controlfile.

过程

首先现场人员，尝试从备份中恢复控制文件，9月10号的全备中包含有控制文件；恢复控制文件成功，open失败，recover失败，using backup controlfile until cancel 失败，数据库不能打开；

22号中午开始接手，在备份了原始环境之后，还原数据库，重新recover using backup controlfile until cancel;在应用了最后一个日志，

ORA-03113: end-of-file on communication channel

ERROR:

ORA-03114: not connected to ORACLE

实例当掉，后台报ora-07445

Thu Sep 22 22:43:33 2011

ALTER DATABASE RECOVER LOGFILE '+DATA1/aysyrk/onlinelog/group_6.264.745102907'

Thu Sep 22 22:43:33 2011

Media Recovery Log +DATA1/aysyrk/onlinelog/group_6.264.745102907

Thu Sep 22 22:44:03 2011

Errors in file /oracle/admin/aysyrk/bdump/aysyrk1_p000_7274518.trc:

ORA-07445: exception encountered: core dump [kcbzfc+00dc] [SIGSEGV] [Address not mapped to object] [0x70000040190] [] []

一些细节：

Restore之前需要去清空datafile，如果不清空，在recover之后，

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '+DATA1/aysyrk/datafile/system.256.745102829';

恢复file1时，又报必须使用using backup controlfile来recover；

Restore到asm中的数据文件会被重命名；

Restore结束之后，把所有的数据文件做一个copy放在2号机的mybak目录下；

第一次恢复时，缺少312# 日志，所以不能恢复，查询备份日志，restore 312# 313# 回asm中，文件夹名称不再是9号而是当天；

重要的是掌握数据文件号、数据文件名称、归档日志文件名、归档日期、seq#、scn

Asmcmd要慎重操作，忽然报错会搞得你一身冷汗；

手工恢复与使用NBU恢复不同；同样的命令，不一样的结果；

Asm磁盘的写速度平均80M 而文件系统能达到100M；

ora-07445怎么办？难道需要logminer一条一条去恢复数据?

只能忽略出问题的日志，提前cancel。

反反复复恢复了多次，凌晨1点的时候，数据库终于打开了。

此外一些细节

1 在线日志文件不是越大越好，在恢复数据时，日志文件越大，意味着可能损失的数据越多；

原来是理论，现在是血淋淋的现实； 一天切换了一次日志，太久了。教科书上的20分钟切换一次对于目前这个系统还是比较适合。

2 即便是放在同一个地方，控制文件还是应该多份；在rman中，设置controlfile autobackup on是有必要的。经常性的手动备份参数文件和控制文件，也是有用的；

3 对于关键的业务数据，除了图片之外，做个DMP，还是有必要的；

4 ASM与文件系统的文件复制，除了rman之外，在数据库不能打开时，还可以通过新建一个实例使用dbms_file_transfer.copy_file复制，也是很容易操作的。

5 备份与数据放在一个阵列上，还没有备份软件备份服务器，有点惊心；

6 v$archived_log v$datafile 和 rman的备份日志 alert日志

后续的一些改善计划

调整在线日志文件的大小；

调整备份策略，包括备份集的存储和保留策略等；

调整控制文件，使有三份；

增加DMP的辅助备份；

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/271063/viewspace-1055283/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/271063/viewspace-1055283/