0

oracle数据库包在调用公共资源包的时候偶尔会出现包失效的情况

问题归档 2019-03-20
106
摘要:oracle数据库包在调用其他的包的时候,会报引用的包失效。具体报错:ORA-04061:existingstateofpackage&q...

问题描述

  1. oracle数据库包在调用其他的包的时候,会报引用的包失效。

    具体报错:

    ORA-04061: existing state of package "PGCX.MES_ZG_GX_COMMON" has been invalidated

    ORA-04065: not executed, altered or dropped package "PGCX.MES_ZG_GX_COMMON"

    ORA-06508: PL/SQL: could not find program unit being called: "PGCX.MES_ZG_GX_COMMON"

  2. 等到检查此包或者引用的包跟存储过程时,发现都是编译通过的。而且此包以及引用的包在多数时间都是正常的,可以正常执行的。

    个人猜测:包应用的全局对象,在某个时刻是处于失效或者找不到的状态。但是报错过于简单,没有办法定位问题

    问题:    

    1. 因为包以及存储过程嵌套过于复杂逐个分析的话非常耗时,且效果不一定很好。能不能做到跟踪数据库中所有的对象,在两个报错时间段内监控着数据库中对象的改动情况?

    2. 具体需要查询数据库中哪些数据库字典,能跟踪到操作数据库对象的sql?

    3. 因为现象是偶然发生,报错时间相隔较大。频率-----一周两次

    是否还有其他的思路能跟踪到故障的原因找到失效的对象?

专家解答

建议试一下 errorstack,让数据库在遇到问题时,抛出详细的信息,以便进一步的诊断分析。

以下是 errorstack 的一个用例,供参考:

Oracle提供接口用于诊断Oracle的错误信息。
诊断事件可以在Session级设置,也可以在系统级设置,通常如果要诊断全局错误,最好在系统级设置,以下是一个测试例子,所选事件只以示范为目的:

SQL> alter system set event='984 trace name ERRORSTACK level  10' scope=spfile;
System altered.
SQL> startup force;
ORACLE instance started.
Total System Global Area  101782828 bytes
Fixed Size                   451884 bytes
Variable Size              37748736 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> create table t (name varchar2(10),id number);
Table created.
SQL> insert into t values(a,1);
insert into t values(a,1)
                     *
ERROR at line 1:
ORA-00984: column not allowed here
SQL> !

此时的984错误将会被跟踪,记录到跟踪文件中。
检查udump目录,找到trace文件:

[oracle@jumper oracle]$ cd $admin
[oracle@jumper udump]$ ls -sort
total 1020
   4 -rw-r--r--    1 oracle        533 Mar  2 16:06 t.sql
   4 -rw-r--r--    1 oracle        522 Mar  3 09:44 d.sql
  20 -rw-r--r--    1 oracle      17445 Mar  8 11:06 a.log
   4 -rw-r-----    1 oracle       3254 Mar 14 23:15 conner_ora_30683.trc
   4 -rw-r-----    1 oracle       1645 Mar 14 23:15 conner_ora_30701.trc
   4 -rw-r-----    1 oracle       1638 Mar 14 23:16 conner_ora_30719.trc
   4 -rw-r-----    1 oracle       1645 Mar 16 09:05 conner_ora_18565.trc
 976 -rw-r-----    1 oracle     993555 Mar 16 09:06 conner_ora_18589.trc
[oracle@jumper udump]$ vi conner_ora_18589.trc
/opt/oracle/admin/conner/udump/conner_ora_18589.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
ORACLE_HOME = /opt/oracle/product/9.2.0
System name:    Linux
Node name:      jumper.hurray.com.cn
Release:        2.4.21-15.EL
Version:        #1 Thu Apr 22 00:27:41 EDT 2004
Machine:        i686
Instance name: conner
Redo thread mounted by this instance: 1
Oracle process number: 10
Unix process pid: 18589, image: oracle@jumper.hurray.com.cn (TNS V1-V3)
*** 2005-03-16 09:06:56.178
ksedmp: internal or fatal error
ORA-00984: column not allowed here
Current SQL statement for this session:
insert into t values(a,1)
----- 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 ? 922C89F ?
                                                   AA642A0 ?
ksddoa()+446         call     ksedmp()+0           A ? AABDCA8 ? B70100B0 ?
                                                   3D8 ? 1 ? B7010114 ?
ksdpcg()+521         call     ksddoa()+0           B70100B0 ? AABDCA8 ?
ksdpec()+220         call     ksdpcg()+0           3D8 ? BFFF3D20 ? 1 ?
ksfpec()+133         call     ksdpec()+0           3D8 ? 3D8 ? AABAE7C ?
                                                   BFFF3D54 ? 9835E89 ?
                                                   AA642A0 ?

有了这个跟踪文件就容易定位和诊断错误了。

参考链接:http://www.eygle.com/archives/2005/03/eoaerrorstackoe.html

「喜欢文章,快来给作者赞赏墨值吧」

评论

1
0
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部
暂无课程,敬请期待...