十
17
一套运行在Linux下的Oracle 9.2.0.4的库，出现了大量的ORA-600[4042]错误。
ORA-00600: internal error code, arguments: [4042], [31760], [], [], [], [], [], []
关于ORA-600错误，第一个参数，也就是第一个方括号中的标识，通常可以用来定位Oracle错误发生的内部模块。（可以参考Metalink Doc ID 146580.1：What is an ORA-600 Internal Error？）如果是数字，最高位通常是指一个大的模块，而接下来的一位是小的模块。比如这里[4042]，4000，最高位是4，是Transaction Layer（事务层），而次高位是0，Transaction Undo（详见Metalink Doc ID ： 175982.1 ORA-600 Lookup Error Categories）。
针对这个错误，很明显是跟事务有关。在处理的时候，第一反应肯定是检查TRACE文件：
ORA-00600: internal error code, arguments: [4042], [31760], [], [], [], [], [], [] Current SQL statement for this session: INSERT INTO XXX ..... .... ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedmp()+269 call ksedst()+0 0 ? 0 ? 0 ? 0 ? BFFF90A4 ? A16D886 ? ksfdmp()+14 call ksedmp()+0 3 ? BFFF91B0 ? 98585B4 ? AD58FA0 ? 3 ? A4B929C ? kgeriv()+188 call ksfdmp()+0 AD58FA0 ? 3 ? kgeasi()+108 call kgeriv()+0 AD58FA0 ? AD9AFC0 ? FCA ? 1 ? BFFF91EC ? ktugusc()+787 call kgeasi()+0 AD58FA0 ? AD9AFC0 ? FCA ? 2 ? 1 ? 4 ? 7C10 ? ktuswr()+2049 call ktugusc()+0 BFFF9394 ? D ? 1 ? 0 ? 0 ? 0 ? 0 ? 0 ? ktusmous_online_und call ktuswr()+0 D ? 0 ? 0 ? 0 ? 0 ? 1 ? oseg()+898 ktusmaus_add_us()+3 call ktusmous_online_und 1 ? 1 ? BFFF94F8 ? 1 ? 27 oseg()+0 ktubnd()+7646 call ktusmaus_add_us()+0 BFFF9CEC ? 0 ? ktuchg()+581 call ktubnd()+0 BFFF9678 ? 8468F4F0 ? BFFF9CEC ? 0 ? ktbchg2()+318 call ktuchg()+0 2 ? 89E91A08 ? 1 ? B7BC3484 ? B7BC348C ? AD7BECC ? BFFF9CEC ? AD7BE38 ? 0 ? 0 ? kdtchg()+1406 call ktbchg2()+0 0 ? 89E91A08 ? B7BC3484 ? B7BC348C ? AD7BECC ? BFFF9CE4 ? AD7BE38 ? 0 ? 0 ? kdtwrp()+2272 call kdtchg()+0 B7BA8638 ? B7BC3484 ? B7BC348C ? AD7BECC ? AD7BE38 ? 1 ? 1C6 ? kdtInsRow()+1724 call kdtwrp()+0 B7BA8638 ? B7BA0000 ? 60DD40A4 ? B7BC31AC ? C ? 2C88E28 ? insrow()+275 call kdtInsRow()+0 B7BA8638 ? 89E95354 ? 89E950EC ? B7BA8418 ? 9840000 ? AD589E8 ? insdrv()+2566 call insrow()+0 B7BA8638 ? BFFF9FEC ? 0 ? insexe()+1665 call insdrv()+0 B7BA8638 ? 89E950EC ? 0 ? B7BA8418 ? 0 ? 0 ? opiexe()+10831 call insexe()+0 89E95354 ? BFFFA220 ? opipls()+6068 call opiexe()+0 4 ? 3 ? BFFFA98C ? opiodr()+5238 call kjxsupd()+987 66 ? 6 ? BFFFB64C ? rpidrus()+140 call opiodr()+0 66 ? 6 ? BFFFB64C ? 5 ? skgmstack()+211 call rpidrus()+0 BFFFB028 ? 10 ? BFFFB040 ? BFFFB3E4 ? BFFFB028 ? 899782A ? rpidru()+93 call skgmstack()+0 BFFFB040 ? AD5A760 ? F618 ? 899782A ? BFFFB028 ? rpiswu2()+777 call rpidru()+0 BFFFB3E4 ? 40 ? 40 ? 0 ? 40C ? A4B929C ? rpidrv()+1452 call rpiswu2()+0 837327D8 ? 40 ? BFFFB4E8 ? 2 ? BFFFB508 ? 40 ? psddr0()+113 call rpidrv()+0 5 ? 66 ? BFFFB64C ? 3A ? AD5907C ? BFFFB7F8 ? psdnal()+173 call psddr0()+0 5 ? 66 ? BFFFB64C ? 30 ? 20 ? B7BBB6B8 ? pevm_EXECC()+458 call psdnal()+0 BFFFC844 ? BFFFC834 ? AD53500 ? B7BBB6B8 ? 856EA21C ? 856EA21C ? pfrrun()+31877 call pevm_EXECC()+0 B7BBF19C ? AD9E4C0 ? 20 ? peicnt()+291 call pfrrun()+0 B7BBF19C ? 0 ? AD9E31C ? ADA0464 ? AD5907C ? BFFFCC10 ? kkxexe()+451 call peicnt()+0 BFFFC844 ? B7BBF19C ? 2 ? AD9954C ? 5001AA24 ? 0 ? opiexe()+12624 call kkxexe()+0 B7BBD068 ? B7BB022C ? AD53504 ? B7BBD068 ? 0 ? 0 ? opiall0()+4435 call opiexe()+0 4 ? 3 ? BFFFD064 ? opial7()+441 call opiall0()+0 3E ? 22 ? BFFFD164 ? BFFFDC0C ? BFFFD1EC ? 0 ? opiodr()+5238 call kjxsupd()+987 47 ? F ? BFFFDC0C ? ttcpip()+2124 call opiodr()+0 47 ? F ? BFFFDC0C ? 1 ? Cannot find symbol in /lib/tls/libc.so.6. opitsk()+1635 call ttcpip()+0 AD53500 ? 47 ? BFFFDC0C ? 0 ? BFFFE4E4 ? BFFFE4E0 ? opiino()+602 call opitsk()+0 0 ? 0 ? AD53500 ? AD8D7B8 ? 83 ? 0 ? opiodr()+5238 call kjxsupd()+987 3C ? 4 ? BFFFF8B0 ? opidrv()+517 call opiodr()+0 3C ? 4 ? BFFFF8B0 ? 0 ? sou2o()+25 call opidrv()+0 3C ? 4 ? BFFFF8B0 ? main()+182 call sou2o()+0 BFFFF894 ? 3C ? 4 ? BFFFF8B0 ? 1 ? 0 ? 00622DE3 call main()+0 2 ? BFFFF954 ? BFFFF960 ? 5FBC66 ? 734FF4 ? 0 ?
从SQL来看，是个简单的INSERT语句，那么就涉及到事务处理了。
从call stack来看，在stack顶端，下面的几行表明错误应该是跟回滚段有关。
# ktugusc()+787 call kgeasi()+0 AD58FA0 ? AD9AFC0 ? FCA ? 2 ? # 1 ? 4 ? 7C10 ? # ktuswr()+2049 call ktugusc()+0 BFFF9394 ? D ? 1 ? 0 ? 0 ? # 0 ? 0 ? 0 ? # ktusmous_online_und call ktuswr()+0 D ? 0 ? 0 ? 0 ? 0 ? 1 ? # oseg()+898 # ktusmaus_add_us()+3 call ktusmous_online_und 1 ? 1 ? BFFF94F8 ? 1 ? # 27 oseg()+0
这一步的分析其实很快，基本上凭call stack中的函数名字来判断。由于当时有其他的事情在处理，同时也不在这套库的现场，就让DBA重新创建了一个UNDO表空间，并将UNDO_TABLESPACE参数设置为新的UNDO表空间名字，错误就不在出现。
其实这个故障的处理，类似于去年处理的一个案例，详见记一次并行恢复问题导致Oracle数据库Crash故障的处理
一个简单的故障处理过程，记录下来，供朋友们参考。
老熊，有2点不理解
1
从call stack来看，在stack顶端，下面的几行表明错误应该是跟回滚段有关。
不知道这么判断的根据是什么？
2 为何需要从新建立UNDO表空间？而且一般碰到这种错误都是到METALINK中去找，如果找不到的话就要发SR，觉得你直接新建表空间，是不是风险有点大？
[回复]
老熊 回复:
11月 8th, 2009 at 6:05 上午
@zabll,
1. 判断的根据，在文章中已经有说明，并且有相应的Metalink文档号，请参阅。
2. 您也说了，一般情况下是去Metalink中去找，我提到的Metalink文档也算是找了吧？呵呵。当然在处理问题时，遇到不能解决的才会去提交SR, 既然能解决，为啥要提交SR呢？大家都知道，就算是1级SR，也是需要时间的。以我当时的评估，新建个表空间是没有风险的。
[回复]