oracle - 触发器在 Oracle 中无效

Question

在对表进行某些更改后，我的数据库中的某些触发器无效。但似乎他们仍在工作。我遇到的唯一问题是，如果我使用 SQL Developer，触发器左侧会出现红色叉号，表明它们是无效的。这是一个大问题吗？

我知道我可以重新编译触发器来解决这个问题，但我不确定这是否真的是一个值得关注的问题。如果是这样，我将需要查看我之前的数百个更改并找出导致问题的原因。谢谢你。

Answer 1

每当我们将更改部署到数据库对象时，任何依赖于它的代码都会失效。这会影响触发器、 View 和存储过程。但是，下次有人调用该代码时，数据库将自动重新编译它。

所以我们不需要担心这个，对吧？嗯，是的，在一定程度上。问题是，触发器(或其他任何东西)的失效对我们来说是一个标志，表明已经进行了可能影响该触发器操作的更改，这可能会产生副作用。最明显的副作用是触发器无法编译。更微妙的是，触发器编译但在操作期间失败。

因此，在开发环境中强制重新编译触发器是一个好主意，以确保我们的更改没有从根本上破坏任何东西。但是当我们在生产中部署我们的更改时，我们可以跳过这一步，因为我们确信一切都会按需重新编译。取决于我们的神经:)

Oracle 提供了自动重新编译模式中所有无效对象的机制。

最直接的就是使用DBMS_UTILITY.COMPILE_SCHEMA() .但这从 8i 开始就很棘手(因为对 Java 存储过程的支持引入了循环依赖的可能性)并且不再保证第一次成功编译所有对象。

在 9i 中 Oracle 给了我们一个脚本 $ORACLE_HOME/rdbms/admin/utlrp.sql其中重新编译的东西。不幸的是，它需要 SYSDBA 访问权限。

在 10g 中，他们添加了 UTL_RECOMP 包，它基本上完成了该脚本所做的一切。这是重新编译大量对象的推荐方法。不幸的是，它还需要 SYSDBA 访问权限。 Find out more .

在 11g 中，Oracle 引入了细粒度的依赖管理。这意味着对表的更改以更精细的粒度(基本上是列级别而不是表级别)进行评估，并且只有直接受更改影响的对象才会受到影响。 Find out more .