在对表进行某些更改后，我的数据库中的某些触发器变得无效。但他们似乎仍在工作。我遇到的唯一问题是，如果我使用 SQL Developer，触发器的左侧会出现红叉，表明它们无效。这是一个大问题吗？
我知道我可以重新编译触发器来解决这个问题，但我不确定这是否真的是一个值得关注的问题。如果是这样，我将需要检查之前的数百个更改并找出导致问题的原因。谢谢。
每当我们将更改部署到数据库对象时，依赖于它的任何代码都会失效。这会影响触发器、视图和存储过程。但是，下次调用该代码时，数据库将自动重新编译它。
所以我们不需要担心这个，对吧？嗯，是的，在某种程度上。问题是，触发器（或其他）的失效对我们来说是一个标志，表明已经进行了更改，这可能会影响该触发器的操作，这可能会产生副作用。最明显的副作用是触发器无法编译。更巧妙的是，触发器可以编译，但在操作期间会失败。
因此，在开发环境中强制重新编译触发器是一个好主意，以确保我们的更改不会从根本上破坏任何内容。但是，当我们在生产中部署更改时，我们可以跳过这一步，因为我们确信所有内容都会根据需要重新编译。取决于我们的神经:)
Oracle 提供了自动重新编译模式中所有无效对象的机制。
最直接的就是使用DBMS_UTILITY.COMPILE_SCHEMA()。但自 8i 以来，这一直很危险（因为对 Java 存储过程的支持引入了循环依赖的可能性），并且不再保证一次性成功编译所有对象。
在9i中Oracle给了我们一个脚本$ORACLE_HOME/rdbms/admin/utlrp.sql它重新编译了东西。不幸的是它需要 SYSDBA 访问权限。
在 10g 中，他们添加了 UTL_RECOMP 包，它基本上完成了该脚本所做的所有事情。这是重新编译大量对象的推荐方法。不幸的是，它还需要 SYSDBA 访问权限。了解更多 http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10802/u_recomp.htm#1000010.
在 11g 中，Oracle 引入了细粒度的依赖管理。这意味着对表的更改会以更细的粒度（基本上是列级别而不是表级别）进行评估，并且只有直接受更改影响的对象才会受到影响。了解更多 http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/dependencies.htm#CHDJIIFC.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
