哪些情况会导致 Oracle 软件包无效？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/626267/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What Situations Cause Oracle Packages to Become Invalid?
提问by Jeff
The scenario that created this question:
创建此问题的场景：
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
我们有一个包是另一个包的依赖项，有时对“父”包进行更改会导致依赖包无效，但有时不会。
It has caught us by surprise before.
它以前让我们感到惊讶。
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
简单地了解导致失效的原因非常有用，这样我就可以预测/计划它。
回答by Thomas Jones-Low
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
更改包所依赖的任何对象（例如表、视图、触发器、其他包）将自动将包标记为无效。正如上面的 tuinstoel 所指出的，Oracle 足够聪明，可以在第一次使用包时重新编译它。
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema(or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
如果您对此感到担心，则每次进行架构更改（例如表、视图、触发器、过程）时，请运行DBMS_UTILITY.compile_schema（或让您的 DBA 进行更改）。这将强制编译所有包，并让您知道哪里或是否有错误，然后才能找到它们。
回答by Guru
Or you can query the following table to see what dependencies you have
或者你可以查询下表，看看你有哪些依赖
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
This will show all dependencies. For your objects query user_dependencies.
这将显示所有依赖项。对于您的对象，请查询 user_dependencies。
回答by Guru
BTW, If I'm completely wrong about the situation... apologies in advance
顺便说一句，如果我完全错误的情况......提前道歉
Caught by surprise?
出乎意料？
Not sure what the implications of that are...
不知道这有什么影响......
Did something break in production?
生产中有什么问题吗？
What EXACTLY happened?
究竟发生了什么？
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REALissue?
我问的原因是因为了解每一个可能的变化的后果比处理结果要困难得多。为什么失效会成为一个问题？我的猜测是因为您的应用程序中出现“包的现有状态已被丢弃”错误。这是真正的问题吗？
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
我再次怀疑它是，如果是这样，让我们处理它而不是我在评论中放入的更改列表是特定于版本的。（例如，11g 将依赖性跟踪到表的列而不是整个表）。
This may not seem like an important error to you ifyou're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
如果您没有使用包状态，这对您来说可能不是一个重要的错误。如果你是，这将是一个重要的错误，你不会感到惊讶，所以我猜你不会。
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
因为你不是这个错误可以忽略。由于您可以安全地忽略它，您可以编写客户端应用程序以忽略此错误并重试您的调用，因为正如其他人指出的那样，Oracle 会为您重新编译您的包。这是一个值得的练习。因为当您进行更改时，您无需了解您需要担心的所有可能的事情，然后在紧急修复中忘记其中之一，您的应用程序只会处理它并继续前进，而无需担心。
回答by darreljnz
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
我同意 Thomas Jones-Low 的观点，但是还有一些与长时间会话和重新编译有关的问题。
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
如果您在会话中引用一个包并且该包（或依赖包）在同一个会话中被重新编译，那么您将收到 oracle 错误“ORA-06508：PL/SQL：找不到正在调用的程序单元”
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
一旦您在会话中引用了包，您通常无法在不使该会话无效的情况下更改包。这对于软件包频繁更改的开发环境来说是一个特殊问题，但对于您希望在不关闭整个环境的情况下进行小补丁的生产环境也是一个问题。请注意，即使更改的包中没有错误，也会发生此错误。
回答by Brummo
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
除了 Thomas Jones-Low 的回答，如果您只修改包 BODY，依赖对象可能不会被标记为无效。
However, as soon as you modify the package specification, that is bound to happen.
但是，一旦您修改了包规范，这必然会发生。
回答by tuinstoel
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.
如果尝试执行无效的 Oracle 包，Oracle 将尝试编译它。只有在编译 Oracle 后仍然无效时才会抛出异常。
