断电与ORA-600错误处理

目 录

断电与ORA-600错误处理集合...................................................................................1
1. 前言.........................................................................................................................3
1.1. 概要说明...................................................................................................3
1.2. 常见步骤--METELINK上查询...............................................................4
1.3. 控制文件问题...........................................................................................4
1.3.1. 现象ORA-600 [kccpb_sanity_check_2]............................................4
1.4. 数据文件问题...........................................................................................4
1.4.1. 现象ORA-600 [4000]........................................................................4
1.5. REDO文件问题........................................................................................5
1.5.1. 强制启动报ORA-00600 [2662]........................................................5
1.5.2. 强制启动报ORA-00600 [kcfnew_2]................................................6
1.5.3. REDO log问题导致ORA-600[kcrfr_update_nab_2]........................6
1.6. UNDO文件问题.......................................................................................6
1.6.1. 现象ORA-600 [4137] 或[4193]或 [4194].......................................6
1.7. 其他问题...................................................................................................7
1.7.1. ORA-00600 [kcratr1_lostwrt]............................................................7
1.7.2. ORA-00600 [19004]..........................................................................8
1.7.3. ORA-00600 [kddummy_blkchk].......................................................8
1.8. 非常规办法...............................................................................................8 对本文相关问题如有疑问请联系

1. 前言

1.1. 概要说明
对于很多的数据库系统，很多时候，没有备份，没有归档，这个时候如果断电的话，而且系统开启了异步IO的情况下，经常会导致数据库无法启动。
本文的目的就是解决断电导致的无法启动的问题。数据库无法启动到mount状态，大部分都会出现ORA-600的错误，下面说明每一种ORA-600的错误，以及对应的解决办法。
概要说明一下：数据库有以下部分组成
(1) REDO LOG
(2) UNDO TABLESPACE
(3) TEMP TABLESPACE
(4) SYSTEM TABLESPACE 和 DATA TABLESPACE
(5) CONTROL FILE
如果某一个部分损坏，或者有问题，对应的解决办法如下：
物理组成
解决办法
(1) REDO
1. 通过_ALLOW_RESETLOGS_CORRUPTION强制启动
2. 清空REDO LOG
(2) UNDO
1. 设置_corrupted_rollback_segments
2. 重建UNDO 表空间
(3) TEMP
1. 重建temp 表空间
(4) SYSTEM/DATA
1. _MINIMUM_GIGA_SCN = 2
2. alter session set events '10015 trace name adjust_scn level 1';
(5) CONTROL
1.2. 常见步骤--METELINK上查询
由于ORA-600属于内部错误，公布的内容，在metelink上都有记录办法。如果有记录办法，都可以查询得到，有时候，没有可能找不到相关内容。
检索办法如下：

1.3. 控制文件问题
1.3.1. 现象ORA-600 [kccpb_sanity_check_2]
本问题是由于断电导致控制文件的不一致，导致数据库启动到mount状态就会报ORA-600错误。
解决办法:重建控制文件就可以了。
某些特殊情况，会出现ORA-600[4000]的错误，这样按照下面的ORA-600[4000]的处理方法处理就可以了。

1.4. 数据文件问题
1.4.1. 现象ORA-600 [4000]
解决办法1：
(1) 查看Oracle告警日志
Sun May 10 14:06:34 2009
SMON: enabling cache recovery
Sun May 10 14:06:34 2009
Errors in file /u01/app/oracle/admin/orcl/udump/orcl2_ora_21637.trc:
ORA-00600: internal error code, arguments: [4000], [6], [], [], [], [], [], []
(2) 按照告警日志内容，检索TRC文件，检索下面类似的内容
Block header dump: 0x0040006e
Object id on Block? Y
seg/obj: 0x24 csc: 0x00.78f0a395 itc: 1 flg: - typ: 2 - INDEX
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.012.00001d26 0x00800cd9.132a.02 C--- 0 scn 0x0000.78f0a395
(3) 将相关红色的数据转换成10进制，并且除以1024*1024*1024
0x00.78f0a395 =>0x0078f0a395 => 2029036437 = 2029036437 /1024/1024/1024 = 1.8 =2
(4) 设置隐含参数
1. 修改此参数文件 _MINIMUM_GIGA_SCN = 2
2. startup mount;
3. recover database until cancel;(或者recover database)
4.alter database open resetlogs;
(必要时设置_ALLOW_RESETLOGS_CORRUPTION=TRUE 这个参数)
(5) 转换成其它的ORA-600错误
可能会转换为 ORA-600[4137] 或者 ORA-600[4194] 的错误。
解决办法2：
通过多次重启数据库，4000的错误，又可能转换成其他的ORA-600的错误，然后对应的解决
解决办法3：
通过BBED来找到数据块，查找未提交的事务，修改相应的数据块。

1.5. REDO文件问题
1.5.1. 强制启动报ORA-00600 [2662]
(1) current日志文件坏了,通过设置_ALLOW_RESETLOGS_CORRUPTION=true来强制启动数据库，这个时候会报ORA-00600 [2662]，这样虽然数据库启动，但是数据库内部可能有不一致现象，可以通过调整SCN来启动。
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
或
alter session set events ‘10015 trace name ADJUST_SCN level 1047′;
(2) 如果继续报2662错误，继续使用下面的办法
job_queue_processes=0; “_allow_resetlogs_corruption”=true “_allow_read_only_corruption”=true “_allow_terminal_recovery_corruption”=true
(3) 如果还继续错误，那采用_minimum_giga_scn 这个参数
alter session set events ‘10015 trace name adjust_scn level 1
1.5.2. 强制启动报ORA-00600 [kcfnew_2]
(1) 强制启动，然后调整SCN
(1)设置_allow_resetlogs_corruption=true
然后数据库启动到mount状态下,执行控制文件的恢复 recover database using backup controlfile until cancel; 提示时输入cancel 或者recover database
alter database open resetlogs; alter session set events '10015 trace name adjust_scn level 1'; shutdown immediate alter database open
如果报其他ORA-600错误，依次处理。
1.5.3. REDO log问题导致ORA-600[kcrfr_update_nab_2]
(1) 通过设置_ALLOW_RESETLOGS_CORRUPTION=true强制启动
(2) 不能启动，重建控制文件，再次强制启动
(3) 再不能启动，通过alter system clear log group x的办法，把redo log清空，防止对其他的影响，然后再强制启动。
(4) 一般能正常启动了，或者报ORA-600[4000]的错误。

1.6. UNDO文件问题
1.6.1. 现象ORA-600 [4137] 或[4193]或 [4194]
(1) 转一般来说3000到4000之间的错误，都是由于undo表空间不一致导致的，解决起来相对简单一些
(2) 发生了ORA-600错误后，检查alert_orcl.log 一般情况下，有下面的类似的log，就表示有这些回滚段。
Undo Segment 11 Onlined Undo Segment 12 Onlined
Undo Segment 13 Onlined
(3) 或者查视图得到
select segment_name from dba_rollback_segs
SYSTEM
_SYSSMU1$
_SYSSMU2$
_SYSSMU3$
_SYSSMU4$
_SYSSMU5$
_SYSSMU6$
_SYSSMU7$
_SYSSMU8$
_SYSSMU9$
_SYSSMU10$
(4) 设置隐含参数._corrupted_rollback_segments，比如
_corrupted_rollback_segments ='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$'
如果不能确定多少个，有时候dba_rollback_segs没有查，可以穷举的办法，比如1-60个就足够了，
(5) 修改undo_management 这个参数
把参数文件中的undo_management 改为MANUAL
(6) 如果只是回滚段的问题，可以重建undo表空间就可以了。
SQL> create undo tablespace undotbs1 2 datafile '/opt/oracle/oradata/conner/undotbs1.dbf' size 10M; Tablespace created. SQL> alter system set undo_tablespace=undotbs1; System altered. SQL> drop tablespace undotbs2; Tablespace dropped.
(7) 如果是其他的ORA-600错误导致的undo问题，可以通过上述设定，启动数据库，然后导出数据，再重建数据库。

1.7. 其他问题
1.7.1. ORA-00600 [kcratr1_lostwrt]
很多时候，由于断电导致数据的错误，如报 ORA-00600 [kcratr1_lostwrt]
这个时候，只要简单的恢复就可以了，但是为了安全起见，做完立即备份

1.用sqlplusw /nolog 来以sysdba身份进行登陆
2.startup mount
3.先执行:recover database;
4.再执行:alter database open;
5.然后执行:shutdown immediate;
6.最后启动数据库即可:startup;
如果上述办法能启动，最好备份，某些情况会继续出现ORA-00600: [13011]的错误这是索引不一致导致
1. 查询user_index
2. 对所有index ANALYZE INDEX <index_name> VALIDATE STRUCTURE; 然后对有问题的index做drop&重建
1.7.2. ORA-00600 [19004]
本问题是无法入数据导致的内部错误，但数据能正常启动。只要删除Oracle的过期统计数据，就正常了
1.7.3. ORA-00600 [kddummy_blkchk]
设定alter system set db_block_checksum=off scope=both; 然后可能正常启动了。

1.8. 非常规办法
如果上述办法都不能成功，或没有任何解决办法，可以采用ITPUB上提供的GDUL和ADUL,其中GDUL是不收费的，可以上google上检索。只要有数据文件，系统表空间文件，就可以直接从数据文件中dump出数据。