ORA-600 [17182],ORA-07445 [kghrst()+1567]

今天，一个11.2.0.2 on CentOS5.8 x86-64 的单点库，出现了问题。

具体现象就是，每次alter database open时，会在10几秒内 自动crash（崩溃）掉

alert 日志如下

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

 SMON: slave died unexpectedly, downgrading to serial recovery
Errors in file /cvms/app/oracle/diag/rdbms/hncvms/HNCVMS/trace/HNCVMS_smon_11203.trc  (incident=187832):
ORA-00600: internal error code, arguments: [17182], [0x2B7C8E7CD7A0], [], [], [], [], [], [], [], [], [], []
Incident details in: /cvms/app/oracle/diag/rdbms/hncvms/HNCVMS/incident/incdir_187832/HNCVMS_smon_11203_i187832.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Doing block recovery for file 12 block 470173
Resuming block recovery (PMON) for file 12 block 470173
Block recovery from logseq 31163, block 68 to scn 70921364289
Recovery of Online Redo Log: Thread 1 Group 1 Seq 31163 Reading mem 0
  Mem# 0: /cvms/app/oracle/oradata/HNCVMS/redo01.log
Block recovery completed at rba 31163.135.16, scn 16.2201887554
ORACLE Instance HNCVMS (pid = 14) - Error 600 encountered while recovering transaction (11, 3) on object 75050.
Errors in file /cvms/app/oracle/diag/rdbms/hncvms/HNCVMS/trace/HNCVMS_smon_11203.trc:
ORA-00600: internal error code, arguments: [17182], [0x2B7C8E7CD7A0], [], [], [], [], [], [], [], [], [], []
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x90890C3, kghrst()+1567] [flags: 0x0, count: 1]
Errors in file /cvms/app/oracle/diag/rdbms/hncvms/HNCVMS/trace/HNCVMS_smon_11203.trc  (incident=187833):
ORA-07445: exception encountered: core dump [kghrst()+1567] [SIGSEGV] [ADDR:0x0] [PC:0x90890C3] [SI_KERNEL(general_protection)] []
ORA-00600: internal error code, arguments: [17182], [0x2B7C8E7CD7A0], [], [], [], [], [], [], [], [], [], []
Incident details in: /cvms/app/oracle/diag/rdbms/hncvms/HNCVMS/incident/incdir_187833/HNCVMS_smon_11203_i187833.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Feb 17 10:44:11 2014
PMON (ospid: 11177): terminating the instance due to error 474

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

通过观察日志，看部分

Doing block recovery for file 12 block 470173
Resuming block recovery (PMON) for  file 12 block 470173
Block recovery from logseq 31163, block 68 to scn 70921364289
Recovery of Online Redo Log: Thread 1 Group 1 Seq 31163 Reading mem 0
  Mem# 0: /cvms/app/oracle/oradata/HNCVMS/redo01.log
Block recovery completed at rba 31163.135.16, scn 16.2201887554
ORACLE Instance HNCVMS (pid = 14) - Error 600 encountered while recovering transaction (11, 3) on object  75050.

再根据原理分析，则可以定位到问题是出现在Instance recovery时出现的。通过报错可以判断，是对 file12 block 470173  也就是 object id为 75050 中的一个块，出现了问题（坏块）

导致instance recover时遭遇到了600错误，Pmon 终止，Pmon的终止又导致 整个实例的down掉

遇到这个情况，我们分两步处理：

第一步：启动实例，查询file 12 block 470173 以及object 75050 是属于哪个类型的对象

1、启动实例

      启动实例时，会执行Instance recovery，而recovery又会crash库，那么我们需要将 instance recovery的动作暂时先停掉

      根据现在的spfile 创建一个pfile，然后在pfile后面跟一条：

      event="10513 trace name context forever, level 2"
2、查询对象（现在系统是不会崩溃了，但是数据库状态是非正常的，因为没有instance recovery）

      1）SQL> SELECT owner, object_name, object_type FROM dba_objects WHERE object_id = 75050;
      2） SQL> select segment_type,owner,segment_name from dba_extents where file_id = &file_id and &block between block_id and block_id+blocks -1;
      根据上面反馈的信息，把对象类型查出来

第二步、恢复数据库

这个错误是坏块错误，如果我们要恢复数据库，将坏块解决即可

我们根据所查对象类型的不同，对应有不同的解决方案

1、索引（index）类型的对象

      如果是索引（index）类型的对象，问题就好办了：

     1） 查询定义 SQL>select index_owner,index_name,table_name,column_name,column_position from dba_ind_columns where index_name='XXX'  ; 

            或者将创建语句直接查出

                             SQL>set long 50000

                             SQL>select dbms_metadata.get_ddl('INDEX','索引名字','所属用户') from dual;

     2） 删除索引 SQL>drop  index xxx  

     3） 重新创建 SQL>create index xxx on   xxx(xxx);

     4） 关闭数据库，使用之前的spfile进行启动

2、表（table）类型的对象

      表，有很多种情况去恢复

有备份的情况：

    1）、通过 rman的blockrecover 进行恢复

           SQL>startup mount; 

           RMAN > Blockrecover datafile 12 block 470173;

           如恢复成功

           SQL>Alter database open

   2）、通过RMAN的block recover 没有成功（这种情况可以判断是磁盘物理出现了坏块）

           操作步骤如下：

           SQL> Drop table xxx（删除掉坏块对象以后，其实已经可正常open库了）

           使用已有备份，到其他机器上  异机恢复（我会在之后写一篇关于异机恢复的博客)

            从异机恢复好的数据库，将XXX表 导出，

            然后导入到 当前生产库 （导出导入的手段随便，我之后也会总结一篇文档[可能跟在异机恢复文档里]）

           使用之前的SPFILE启动库！

     to   be  continue--