创建此问题的方案:
我们有一个包是另一个包的依赖项,有时对“父”包进行更改会导致依赖包失效,但有时却不会。
它让我们感到意外。
简单地了解导致失效的原因非常有用,因此我可以预测/计划失效。
答案 0 :(得分:12)
更改程序包所依赖的任何对象(例如表,视图,触发器,其他程序包)将自动将程序包标记为无效。正如上面的tuinstoel所说,Oracle在第一次使用时足够聪明,可以重新编译软件包。
如果您对此感到担心,每次进行架构更改(例如表,视图,触发器,过程)时,请运行DBMS_UTILITY.compile_schema
(或让您的DBA执行此操作)。这将强制编译所有包,并让您知道在找到错误之前,或者是否有错误。
答案 1 :(得分:5)
或者您可以查询下表以查看您拥有的依赖项
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
这将显示所有依赖项。对于您的对象查询user_dependencies。
答案 2 :(得分:3)
顺便说一句,如果我对这种情况完全错了......请提前道歉
感到惊讶?
不确定其含义是什么......
生产中出现了什么问题?
究竟发生了什么?
我问的原因是因为理解每一个可能的变化的后果比处理结果要困难得多。失效为何成为问题?我的猜测是因为您的应用程序中出现“已丢弃包的现有状态”错误。这是 REAL 问题吗?
我再次怀疑它是,如果是这样,我们只是处理它而不是我在评论中添加的更改列表是特定于版本的。 (例如,11g跟踪依赖关系到表格的列而不是整个表格。)
对于您来说,这似乎不是一个重要的错误如果您没有使用包状态。如果你这是一个重要的错误,你不会感到惊讶,所以我猜你不是。
既然你不是这个错误就可以忽略了。由于您可以安全地忽略它,因此您可以编写客户端应用程序代码以忽略此错误并重试您的调用,因为正如其他人指出的那样,Oracle将为您重新编译您的程序包。这是一项值得的练习。因为您不必知道在进行更改时需要担心的所有事情,然后在紧急修复中忘记其中之一,您的应用程序将只处理它并继续前进,而不用担心。
答案 3 :(得分:3)
我同意Thomas Jones-Low,但是有很多问题与长会话和重新编译有关。
如果您在会话中引用了一个包,并且在同一个会话期间重新编译了该包(或依赖包),那么您将得到oracle错误“ORA-06508:PL / SQL:找不到被调用的程序单元”
在会话中引用包后,通常无法更改包而不会使该会话失效。对于软件包频繁更改的开发环境而言,这是一个特殊问题,但对于您希望在不占用整个环境的情况下执行小型修补程序的生产环境也存在问题。请注意,即使更改的包中没有错误,也会发生此错误。
答案 4 :(得分:2)
除了Thomas Jones-Low的回答,如果您只修改包BODY,则可能不会将依赖对象标记为无效。
但是,只要修改软件包规范,就必然会发生这种情况。
答案 5 :(得分:1)
如果尝试执行无效的Oracle包,Oracle将尝试编译它。只有在编译Oracle后它仍然无效时才会抛出异常。