Oracle数据恢复: ORA-600 kclchkblk_4 案例一则

原文地址： http://www.itpub.net/thread-1404451-1-1.html

问题描述：

服务器突然故障死机，导致数据库无法驱动，redo的CURRENT组的损坏。oracle 10g rac环境，asm磁盘组，redhat linux系统。每个组一个成员这个是组被破坏无法修复的关键。

没有归档，没有备份。使用ASM无法将数据文件冷备份出来。

ORA-00368: checksum error in redo log block

ORA-00353: log corruption near block 254606 change 12131176305969 time 03/08/2011 01:03:00

ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

查看日志组文件信息，报错的日志组为CURRENT模式。

SQL> select group#,sequence#,archived,status from v$log;


    GROUP#  SEQUENCE# ARC STATUS

---------- ---------- --- ----------------

         1      17495 NO  INACTIVE

         2      17496 NO  CURRENT

         3      17365 NO  INACTIVE

         4      17366 NO  CURRENT

组成员只有一个。

SQL>



     Group   Instance             Member             STATUS             Size(MB)

---------- ---------- ------------------------------ ---------------- ----------

         1          1 +DG1/police/onlinelog/group_1. INACTIVE                500

                      257.657430665


         2          1 +DG1/police/onlinelog/group_2. CURRENT                 500

                      258.657430669


         3          2 +DG1/police/onlinelog/group_3. INACTIVE                500

                      265.657431819


         4          2 +DG1/police/onlinelog/group_4. CURRENT                 500

                      266.657431825

无法使用clear命令清楚redo的信息

SQL> alter database clear unarchived logfile group 2   

  2  ;

alter database clear unarchived logfile group 2

*

ERROR at line 1:

ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)

ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'


SQL> alter database clear logfile group 2;

alter database clear logfile group 2

*

ERROR at line 1:

ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)

ORA-00312: online log 2 thread 1: '+DG1/police/onlinelog/group_2.258.657430669'

处理步骤



把数据库down掉

   SQL>shutdown immediate

5、在init<sid>.ora中加入如下参数

_allow_resetlogs_corruption=TRUE

6、重新启动数据库,利用until cancel恢复

SQL>recover database until cancel;

Cancel

如果出错，不再理会，发出

SQL>alter database open resetlogs;

如果运气好的话可以正常启动数据库，就可以导出数据了。但是这里有点意外不知道是点背还是rac环境的恢复比较特殊。在alert.log中有如下报错：

Errors in file /u01/app/oracle/admin/police/bdump/police2_j003_17720.trc:

ORA-00600: internal error code, arguments: [4194], [9], [8], [], [], [], [], []

Wed Mar  9 18:08:06 2011

Errors in file /u01/app/oracle/admin/police/bdump/police2_j004_17722.trc:

ORA-00600: internal error code, arguments: [4193], [55749], [55753], [], [], [], [], []

Wed Mar  9 18:08:08 2011

Errors in file /u01/app/oracle/admin/police/bdump/police2_mmon_11328.trc:

ORA-00600: internal error code, arguments: [4194], [12], [17], [], [], [], [], []

Wed Mar  9 18:08:08 2011

Errors in file /u01/app/oracle/admin/police/bdump/police2_j002_17718.trc:

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

能后我就重复启动数据库这个错误就过去了，网上有一篇文档是这么说的，真的可以过去，不过我是将两个节点都同时启动的时候过去的，但是在开始出现如下错误：

ORA-600[KCLCHKBLK_4]【2824】，但是没有出现ORA-600[2662]的报错，不知道为什么，有人说是temp文件不一致造成，但是别人都有2662的报错我这里没有，不管了先将temp删了在说。

能后速度将temp删除，能后发现问题依旧。当时我就很失望了，情绪低落。这个报错在网上的解决办法只有这一个。也没有什么人有更好的建议。

ORA-00600: internal error code, arguments: [kclchkblk_4], [2824],
[18446744071603238605], [2824], [18446744071593491338], [], [], []

Wed Mar  9 14:29:55 2011

Errors in file /u01/app/oracle/admin/police/udump/police1_ora_27660.trc:

ORA-00600: internal error code, arguments: [kclchkblk_4], [2824],
[18446744071603238605], [2824], [18446744071593491338], [], [], []

Wed Mar  9 14:29:55 2011

Error 600 happened during db open, shutting down database

USER: terminating instance due to error 600

但是仔细观察后我发现18446744071593491338这个数据有问题，它在我每次重新启动数据库的时候会和前面的数值有所改变18446744071593491338，我的目标就是将

这个数值尽量的缩小和18446744071603238605的值，重复几遍后发现使用srvctl start database -d sid数据库会自动重启多次，我就不停地启动关闭。有希望了两个者还是相差太大，

这一步我们在这里卡了很久。这里有一个scn的问题，我这里碰到的是后面的比前面的低，所以adjust_scn没有效果。

无赖我将_allow_resetlogs_corruption=TRUE增加到spfile中让数据库同时启动。结果发现错误改变了，后来想想估计是要将参数添加到spfile中同时启动数据库才有效果，因为我单独启动数据库的时候效果不大。

Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

Wed Mar  9 18:08:35 2011

ORACLE Instance police2 (pid = 16) - Error 600 encountered while recovering transaction (9, 46).

Wed Mar  9 18:08:35 2011

Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

Wed Mar  9 18:08:35 2011

Trace dumping is performing id=[cdmp_20110309180835]

Wed Mar  9 18:08:37 2011

Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

Errors in file /u01/app/oracle/admin/police/bdump/police2_p007_19333.trc:

ORA-00600: internal error code, arguments: [4198], [9], [], [], [], [], [], []

出现了这些报错，现在好了，4137,4138 ，4139不都是undo的报错吧，

新建立两个undo，修改spfile使用新的undo启动，删除旧的undo。

添加spfile参数

_allow_resetlogs_corruption"=true "

_allow_terminal_recovery_corruption"=true

_corrupted_rollback_segments ='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$'

如果不能确定多少个，但是我在删除UNDO的时候提示_SYSSMU2无法删除，我还是坚持加到了20个，后来我查了一下一共有400多个还好没有每个都坏掉。

修改undo_management 这个参数

把参数文件中的undo_management 改为MANUAL

create undo tablespace undotbs3 datafile '/opt/oracle/oradata/conner/undotbs3.dbf' size 10M;
Tablespace created.

SQL> alter system set undo_tablespace=undotbs1 scope=spfile sid='sid';

System altered.

SQL> drop tablespace undotbs2;
Tablespace dropped.

将两个节点的undo都替换后发现数据库可以起来了，但还是有报错，

Errors in file /u01/app/oracle/admin/police/bdump/police2_j000_7977.trc:

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

Wed Mar  9 23:56:10 2011

但还好可以exp数据了。



导出数据后，删除数据库，删除asm，

关闭第二台的asm实例，

登入第一台asm

SQL> select name from v$asm_diskgroup;

NAME

------------------------------

DG1

SQL> drop diskgroup DG1 including contents;       -->删除磁盘组

SQL>SHUTDOWN IMMEDIATE

能后

crs_unregister ora.node1.ASM1.asm

crs_unregister ora.node1.ASM1.asm(后来极度后悔，应该在unregister前备份一下就好了）

在dbs和admin下删除asm相关文档

修改/etc/oratab文件将asm的注释。

dbca重新建立asm磁盘发现asm实例无法启动晕倒。好像是出现prks-1011，和ora-0210的报错

使用srvctl add asm -n node1 -i +ASM1 -o $ORACLE_HOME -p init+ASM1.ora

提示ora.node1.ASM1.asm服务已经存在了，但是crs_stat -t查看又没有ora.node1.ASM1.asm服务。

于是我使用crs_register ora.node1.ASM1.asm的时候提示找不到 ora.node1.ASM1.asm.cap的文件（这里折腾了一段时间）

没法我从别的rac上使用crs_stat -p ora.node1.ASM1.asm > ora.node1.ASM1.asm.cap导出了一份拷贝到提示的目录下，并且修改了文件中的主机信息等。

在使用crs_register ora.node1.ASM1.asm就注册成功了。其实 ora.node1.ASM1.asm.cap这个文件的东西和 ora.node1.lsnr的文件内容一样。就是有些东西自己动手修改一下就可以替代了。

重新建库导入文件


艰苦的数据恢复终于完成了。