详解ORA-600(17069)错误（二）

日期： 2009-02-25 作者：杨廷琨 来源：TechTarget中国 英文

　　查看文档的描述，发现ORA-600错误的第二个参数，这里是0x6A5DEE1E0，代表Library Cache Object Handle.看来问题可能和LATCH有关。

    但是根据信息在V$LATCH和V$LATCH_CHILDREN视图中，没有找到有价值的信息。

    这个JOB由于失败会自动再次执行，检查JOB运行时的V$LOCK信息：


SQL> SELECT ADDR， TYPE， ID1， ID2， LMODE， REQUEST， BLOCK
2 FROM V$LOCK
3 WHERE SID = 75;
ADDR TY ID1 ID2 LMODE REQUEST BLOCK
—————- — ———- ———- ———- ———- ———-
0000000690342780 CU -1.703E+09 6 6 0 0
00000006903426F8 JQ 0 63 6 0 0

　　从V$LOCK中看不到什么特别有价值的信息，接着检查V$SESSION_WAIT，看看这个JOB在等待什么：


SQL> SELECT EVENT， P1TEXT， P1RAW， P2TEXT， P2RAW， STATE
2 FROM V$SESSION_WAIT 
3 WHERE SID = 75;
EVENT P1TEXT P1RAW P2TEXT P2RAW STATE
—————– ————— —————- ———— —————- ——-
library cache pin handle address 00000006A5DEE1E0 pin address 00000006B1A971A8 WAITING
 

    这次的信息就明显了，ORA-600错误的第二个参数就是V$SESSION_WAIT视图的P1RAW的值，而且从等待事件上也可以看到，问题就是出现在LIBRARY CACHE PIN的过程中。

    重新查看METALINK的信息，这个错误可能发生在一个长时间运行的进程，在其运行过程中，所依赖的对象被编译或者删除了。

    检查JOB调用的过程的状态：

SQL> SELECT OWNER， OBJECT_NAME， OBJECT_TYPE， STATUS
2 FROM DBA_OBJECTS
3 WHERE OWNER = ‘FUJIANREP’
4 AND OBJECT_NAME = ‘P_GENERATE_REPDATA’;
OWNER OBJECT_NAME OBJECT_TYPE STATUS
—————————— —————————— —————— ——-
FUJIANREP 
 

    果然问题过程处于不正常的状态。

    将JOB至于BROKEN状态，避免JOB再次运行：


SQL> EXEC DBMS_JOB.BROKEN(63， TRUE)
PL/SQL procedure successfully completed.
SQL> COMMIT;
Commit complete.

　　杀掉JOB对应的PROCESS：


SQL> SELECT SPID FROM V$PROCESS WHERE ADDR IN (SELECT PADDR FROM V$SESSION WHERE SID = 75);
SPID
————
14927
SQL> HOST kill -9 14927

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。

作者

杨廷琨
杨廷琨

相关推荐