Oracle中的触发器无效

new*_*guy 13 oracle triggers recompile

在对表进行某些更改后,我的数据库中的某些触发器将变为无效.但似乎他们仍然在工作.我唯一的问题是如果我使用SQL Developer,触发器左侧有红色十字表示它们无效.这是一个大问题吗?

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

APC*_*APC 17

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

所以我们不需要担心这个,对吧?好吧,是的,一点.问题是,触发器(或其他)的失效是我们的一个标志,表明已经进行了一些改变,这可能会影响该触发器的操作,这可能会产生副作用.最明显的副作用是触发器无法编译.更巧妙的是,触发器在操作期间编译但失败.

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

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

  • 最直接的是使用DBMS_UTILITY.COMPILE_SCHEMA().但是自8i以来这一点很狡猾(因为对Java存储过程的支持引入了循环依赖的可能性)并且不再保证第一次成功编译所有对象.

  • 在9i中,Oracle为我们提供了一个$ORACLE_HOME/rdbms/admin/utlrp.sql重新编译的脚本 .不幸的是,它需要SYSDBA访问权限.

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

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