aix环境10g由于控制器异常导致ORA-600 4000故障处理---惜分飞

一台运行在aix环境下面的10.2.0.1的数据库

由于控制器异常导致数据库启动的时候报ORA-600 4000错误

Wed Jan 28 18:17:06 2026 Completed crash recovery at Thread 1: logseq 499321, block 14459, scn 17457591400427 257 data blocksread, 41 data blocks written, 14457 redo blocksread Wed Jan 28 18:17:06 2026 Thread 1 advanced to log sequence 499322 Thread 1 opened at log sequence 499322 Current log# 2 seq# 499322 mem# 0: /dev/rrk_redo2 Successfulopenof redo thread 1 Wed Jan 28 18:17:06 2026 MTTR advisory is disabled because FAST_START_MTTR_TARGET is notset Wed Jan 28 18:17:06 2026 SMON: enabling cache recovery Wed Jan 28 18:17:07 2026 Errorsinfile/u01/app/oracle/admin/orcl1/udump/orcl1_ora_16187632.trc: ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], [] Wed Jan 28 18:17:08 2026 Errorsinfile/u01/app/oracle/admin/orcl1/udump/orcl1_ora_16187632.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], [] Wed Jan 28 18:17:08 2026 Error 704 happened during dbopen, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 16187632 ORA-1092 signalled during: alter databaseopen...

ORA-600 4000这个是在10g版本中非常常见的一个错误,一般是由于对应的block上面有事务没有提交或者scn过大导致,跟踪数据库启动过程发现在以下sql语句报错,而且报错为file 1 block 27527

EXEC#2:c=0,e=62,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=437860213380 WAIT#2: nam='db file sequential read' ela= 139 file#=1 block#=27527 blocks=1 obj#=-1 tim=437860213555 *** 2026-01-31 15:31:40.417 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], [] Current SQL statementforthis session: selectrowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1

这里可以获取到两个有效信息:
1. 报错block为：file 1 block 27227
2. 报错sql为：select rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1

进一步对报错数据块进行分析

Block header dump: 0x00406b87 Objectidon Block? Y seg/obj: 0x2 csc: 0xfe0.a99d3719 itc: 2 flg: - typ: 1 - DATA fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x000b.014.00f1bb09 0x008027a5.eada.0e C--- 0 scn 0x0fda.f353b198 0x02 0x0009.01e.00212e2a 0x01400cdf.113e.01 --U- 1 fsc 0x0000.a99d371b

这里可以确认几个有效信息:
1. 该block的csc scn为:17457592743705
2. 一条已经提交的事务的scn为:17433059635608
3. 还有一条没有提交的事务,使用的回滚段为9,这个和我们报错的ORA-600[4000][9]这个回滚段名称匹配上

基于上述分析,我们需要确认两件事情:
1. 通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本检查结果,确认当前是数据库的文件头scn为:17457591420434小于该block的csc scn

2. itl操上面有一个锁需要提交,通过bbed工具对其进行提交,然后得出dump block信息

Block header dump: 0x00406b87 Objectidon Block? Y seg/obj: 0x2 csc: 0xfe0.a99d3719 itc: 2 flg: - typ: 1 - DATA fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x000b.014.00f1bb09 0x008027a5.eada.0e C--- 0 scn 0x0fda.f353b198 0x02 0x0009.01e.00212e2a 0x01400cdf.113e.01 C--- 0 scn 0x0000.a99d371b

修改好itl之后,先尝试重启库,如果不出意外应该会报ORA-600 2662类似错误（因为前面分析了csc scn大于文件头scn的问题）

这里的ORA-600 2662中的4221831就是报错的rdba地址(10进制),通过dbms_utility.data_block_address_file转换

SQL>selectdbms_utility.data_block_address_file(4221831)"file", 2 dbms_utility.data_block_address_block(4221831)"block" 3fromdual; file block ---------- ---------- 1 27527

得出报错的ORA-600 2662的block就是我们之前分析和修复的itl块,通过修改该块scn或者修改数据库scn,该库均可open,后续就是安排导出数据导入新库的活