断电与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 对本文相关问题如有疑问请联系 cys830301@sina.com.cn 第 2 页 共 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. 1.重建控制文件 对本文相关问题如有疑问请联系 cys830301@sina.com.cn 第 3 页 共 8 页
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], [], [], [], [], [], [] 对本文相关问题如有疑问请联系 cys830301@sina.com.cn 第 4 页 共 8 页 (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′; 对本文相关问题如有疑问请联系 cys830301@sina.com.cn 第 5 页 共 8 页 (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 对本文相关问题如有疑问请联系 cys830301@sina.com.cn 第 6 页 共 8 页 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] 这个时候,只要简单的恢复就可以了,但是为了安全起见,做完立即备份 对本文相关问题如有疑问请联系 cys830301@sina.com.cn 第 7 页 共 8 页 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出数据。
|