环境：
OS: AIX 4.3.3
ORACLE: 8.1.7.4 OPS,非归档模式
没有任何物理备份，只有一个月前的逻辑备份
客户一个重要的系统因ora-600 [ktbair1]错误而异常宕机，dba偿试去启动时，还是报这个600号错误。
在告警日志文件中我们发现以下错误：
Errors in file /oracle/app/oracle/admin/ora73/bdump/smon_41086_ora73.trc:
ORA-00600: internal error code, arguments: [ktbair1], [1], [7], [], [], [], []
Errors in file /oracle/app/oracle/admin/ora73/bdump/smon_41086_ora73.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
ORA-00600: internal error code, arguments: [ktbair1], [1], [7], [], [], [], []
Errors in file /oracle/app/oracle/admin/ora73/bdump/pmon_31066_ora73.trc:
ORA-00474: SMON process terminated with error
该600号错误的错误堆栈如下：
----- Call Stack Trace -----
calling
call entry
location
type point
-------------------- -------- -----------
ksedmp+00fc
bl ksedst
ksfdmp+0018
bl ksedmp
kgerinv+00e8 bl _ptrgl
kgeasnmierr+004c bl kgerinv
ktbair+00d4
bl kgeasnmierr
kdourp+09a0
bl ktbair
kcoapl+0650
bl _ptrgl
kcbapl+0080
bl kcoapl
kcrfwr+0db4
bl kcbapl
kcbchg1+14fc bl kcrfwr
kcbchg+00a0
bl kcbchg1
ktuapundo+01dc bl kcbchg
从中我们可以知道，该600号错误是发生在事务回滚的阶段，在oracle回滚事务时发现块信息与redo信息不一致导致的。
于是开始我们相信增加10513事件以禁止smon进程回滚事务可以正常启动数据库。
但是增加10513事件后，启动数据库，却报出了一个ora-7445[ksmudr]错误。错误堆栈如下：
----- Call Stack Trace -----
calling
call entry
location
type point
-------------------- -------- ------------------
ksmudr+004c
?00000000
ksmfrs+001c
bclksdxexeotherwa+012
kcbema+08a0
bl ksmfrs
kcrpap+011c
bl kcbema
kcratr+0498
bl kcrpap
kctrec+0588
bl kcratr
kcvcrv+1530
bl kctrec
kcfopd+02e4
bl kcvcrv
adbdrv+0640
bl kcfopd
opiexe+2380
bl adbdrv
opiosq0+0c80 bl opiexe
kpoal8+06f8
bl opiall0
opiodr+06bc
bl _ptrgl
ttcpip+0a74
bl _ptrgl
opitsk+06d8
bl ttcpip
opiino+0670
bl opitsk
opiodr+06bc
bl _ptrgl
opidrv+056c
bl opiodr
sou2o+0028 bl opidrv
main+0128
bl sou2o
__start+0090 bl main
从metalink上搜索该7445错误，基本上都是讲内存corruption方面的问题，未有任何有用的线索。
增加10231事件，错误依旧。
于是我们打算跟踪oracle启动过程，增加10046事件，启动数据库，通过产生的trace文件发现此时oracle启动在刚开始就报错了，
也就是没还有到查询数据字典和创建bootstrap$基表的过程，
而前面的600号错误是在回滚的阶段的报错。于是怀疑oracle在读取数据文件的checkpoint时就报错了。
于是偿试将其中一个数据文件offline drop(因为是非归档模式)掉后，再做recover datafile,然后将数据文件online起来，操作成功。
偿试recover database，又报出前面的ora-7445错误。至此基本上可以肯定是某个数据文件有问题导致了ora-7445错误。
于是先将数据库暂时改成归档模式将所有的文件都offline drop，再一个一个做recover datafile，然后online启来。
在这个过程中有两个文件出错，其中一个是6号文件，其是indx表空间，这个祼设备在物理上是不存在的，并且这个表空间里面没有任何数据，
直接将该文件offline即可，不用理会。另外一个是38号文件，它是属于data表空间的(最重要的表空间)，将其offline drop掉后，
将所有的事件去掉，偿试将数据库open，open成功！ 但是过了几分钟后数据库又宕下来了，报出前面的600号错误，
从告警日志里面可以看出是smon进程在做事务回滚导致的。于是此时再增加10513事件后，可以正常启动数据库，并不会自动宕机下来。
至此，数据库可以正常打开，但是38号文件无法online起来，所有的业务还是无法继续。我们采用dbv检测38号文件，未有坏块。
我们偿试查看38号文件上面有多少的表格和索引，但是dba_extents视图无法查看，报出ora-8103的错误。
同时我们发现查看dba_free_space和dba_data_files几张视图时，都会报出ora-8103错误。这表明oracle的基表上面数据有问题！
偿试做recover datafile 38也是报出ora-7445错误。与此同时在alert日志里面不断地报出下面的错误：
Errors in file /oracle/app/oracle/admin/ora73/bdump/smon_41412_ora73.trc:
ORA-00376: file 38 cannot be read at this time
ORA-01110: data file 38: '/dev/rlvdata54'
ORACLE Instance ora73 (pid = 8) - Error 376 encountered while recovering transaction (43, 70) on object 34060.
通过dba_objects视图我们发现34060对象是so表(非常重要的表格).
问题处理到这里，当时觉的几乎没什么希望了，数据字典有问题，38号文件也有问题，并且是处于recover状态。除了重建数据库，
将一个月前的数据导入外好像没有什么好的办法了。
此时想起以前我用bbed修改数据文件头的scn号，以将表空间online起来的那次事件，为了使38号文件打开，我们决定再次采用
bbed修改38号文件的scn号，看看能不能将38号文件online启来。
修改成功后，直接online数据文件不行，还是要做recover，recover datafile 38很快做完，然后顺利将38号文件online启来。
此时查看38号文件上面的表格和索引，发现几乎所有的表格和索上都有一部分数据存在38号文件上面。
至此还是怀疑38号文件上面的错误信息引起了这一切，我们认为38号文件上面的数据块肯定有问题，但是采用dbv又查不到错误。
此时想起前面用bbed修改scn，校验数据文件时，它将587219块标志为failing状态(这个状态不知道是什么意思)
通过Dba_extents视图，找出该块对应的segment就是so表。
我们偿试analyze table so validzte structure;执行正常，未报出任何错误。同时我们偿试select count(*) from so;返回结果也正常。
再偿试create table bak_so as select * from so;报出前面一样的ora-7445错误。
采用10231事件，想跳过坏块，取出正常的数据，但是依然报同样的ora-7445错误。然后我们采用rowid方法跳过该块，
取出so表中其他正常的数据(丢失了64条记录)。将so表删掉重建，将索引建立回去，重新对so表做analyze分析。同时将外键增加回去。
至此一切正常，测试业务，正常！
后语：
真是没想到了一个普通表格上面的数据块有问题导致了这么大的问题，这个块oracle未将它标志为坏块，而是failing状态，
不知道是什么意思，如果标志为坏块，那事情就不会这样了。
|
