ORA-04091: 表 [blah] 正在变异，触发器/函数可能看不到它

Posted 2023-03-15

【中文标题】ORA-04091: 表 [blah] 正在变异，触发器/函数可能看不到它

【英文标题】：ORA-04091: table [blah] is mutating, trigger/function may not see it

【发布时间】：2010-09-27 10:04:05

【问题描述】：

我最近开始研究一个大型复杂的应用程序，由于这个错误，我刚刚被分配了一个错误：

ORA-04091: table SCMA.TBL1 is mutating, trigger/function may not see it
ORA-06512: at "SCMA.TRG_T1_TBL1_COL1", line 4
ORA-04088: error during execution of trigger 'SCMA.TRG_T1_TBL1_COL1'

有问题的触发器看起来像

    create or replace TRIGGER TRG_T1_TBL1_COL1
   BEFORE  INSERT OR UPDATE OF t1_appnt_evnt_id ON TBL1
   FOR EACH ROW
   WHEN (NEW.t1_prnt_t1_pk is not  null)
   DECLARE
        v_reassign_count number(20);
   BEGIN
       select count(t1_pk) INTO v_reassign_count from TBL1
              where  t1_appnt_evnt_id=:new.t1_appnt_evnt_id and t1_prnt_t1_pk is not null;
       IF (v_reassign_count > 0) THEN
           RAISE_APPLICATION_ERROR(-20013, 'Multiple reassignments not allowed');
       END IF;
   END;

该表有一个主键“t1_pk”，一个“约会事件 id” t1_appnt_evnt_id 和另一列“t1_prnt_t1_pk”可能会或可能会 不包含另一行的t1_pk。

看来触发器正试图确保没有其他人使用 相同的t1_appnt_evnt_id 引用了同一行，引用了另一行，如果这一行引用了另一行。

DBA 对错误报告的评论说“删除触发器，并在代码中执行检查”，但不幸的是，他们在 Hibernate 之上有一个专有的代码生成框架，所以我什至无法弄清楚它实际上被写出来的地方，所以我希望有一种方法可以使这个触发器工作。有吗？

【问题讨论】：

只在代码中强制执行这样的规则是个坏主意——多个同时更新很难处理。如果您在代码中同步，您最终可能会在该代码和数据库锁之间出现肮脏的死锁。

底线 - Oracle 触发器很糟糕。除了像更新序列值或“updated_by”类型字段这样简单的事情外，像瘟疫一样避免它们。他们的触发器在 90 年代很糟糕，现在很糟糕。

【参考方案1】：

我想我不同意你对触发器试图做什么的描述 做。在我看来，它是为了强制执行此业务规则：对于 给定 t1_appnt_event 的值，只有一行可以具有非 NULL 值 t1_prnt_t1_pk 一次。 （它们在第二列中是否具有相同的值并不重要。）

有趣的是，它是为 UPDATE OF t1_appnt_event 定义的，但不是为另一列定义的，所以我认为有人可以通过更新第二列来打破规则，除非该列有单独的触发器。

您可能有一种方法可以创建一个基于函数的索引来强制执行此规则，这样您就可以完全摆脱触发器。我想出了一种方法，但它需要一些假设：

该表有一个数字主键 主键和 t1_prnt_t1_pk 都是正数

如果这些假设成立，您可以创建这样的函数：

dev> create or replace function f( a number, b number ) return number deterministic as
  2  begin
  3    if a is null then return 0-b; else return a; end if;
  4  end;

还有这样的索引：

CREATE UNIQUE INDEX my_index ON my_table
  ( t1_appnt_event, f( t1_prnt_t1_pk, primary_key_column) );

因此，PMNT 列为 NULL 的行将出现在索引中，主键的倒数作为第二个值，因此它们永远不会相互冲突。不为 NULL 的行将使用列的实际（正）值。如果两行在两列中都具有相同的非 NULL 值，那么您可能会违反约束的唯一方法。

这可能过于“聪明”，但它可能会帮助您解决问题。

来自 Paul Tomblin 的更新：我对 igor 放入 cmets 的原始想法进行了更新：

 CREATE UNIQUE INDEX cappec_ccip_uniq_idx 
 ON tbl1 (t1_appnt_event, 
    CASE WHEN t1_prnt_t1_pk IS NOT NULL THEN 1 ELSE t1_pk END);

【讨论】：

哦，好吧。你让我的希望在那里片刻。 :-)

这种方法可行，你只需要让函数接受两个参数。在 F(CAPPEC_APPE_ID, CAPPEC_CAPPEC_ID_PMNT) 上创建一个唯一索引。如果您从函数返回 NULL，则它不会被索引。否则返回 CAPPEC_CAPPEC_ID_PMNT

@WW -- 这不会阻止具有不同 ID 值但相同 PMNT 值的两行吗？

顺便说一句，我重写了我的答案，因为我确实想出了一种可行的方法。

@Dave Costa - 也许我弄错了函数（很快阅读了触发代码），但我认为这个概念是正确的。

【参考方案2】：

我同意 Dave 的观点，即可以而且应该使用内置约束（例如唯一索引（或唯一约束））来实现所需的结果。

如果您确实需要解决 mutating table 错误，通常的方法是创建一个包，其中包含一个包范围的变量，该变量是一个表，可用于识别更改的行（我认为ROWID是可能的，否则你必须使用PK，我目前不使用Oracle所以我无法测试它）。 FOR EACH ROW 触发器然后用语句修改的所有行填充这个变量，然后有一个 AFTER each 语句触发器读取行并验证它们。

类似的东西（语法可能是错误的，我已经几年没有与 Oracle 合作了）

CREATE OR REPLACE PACKAGE trigger_pkg;
   PROCEDURE before_stmt_trigger;
   PROCEDURE for_each_row_trigger(row IN ROWID);
   PROCEDURE after_stmt_trigger;
END trigger_pkg;

CREATE OR REPLACE PACKAGE BODY trigger_pkg AS
   TYPE rowid_tbl IS TABLE OF(ROWID);
   modified_rows rowid_tbl;

   PROCEDURE before_stmt_trigger IS
   BEGIN
      modified_rows := rowid_tbl();
   END before_each_stmt_trigger;

   PROCEDURE for_each_row_trigger(row IN ROWID) IS
   BEGIN
      modified_rows(modified_rows.COUNT) = row;
   END for_each_row_trigger;

   PROCEDURE after_stmt_trigger IS
   BEGIN
      FOR i IN 1 .. modified_rows.COUNT LOOP
         SELECT ... INTO ... FROM the_table WHERE rowid = modified_rows(i);
         -- do whatever you want to
      END LOOP;
   END after_each_stmt_trigger;
END trigger_pkg;

CREATE OR REPLACE TRIGGER before_stmt_trigger BEFORE INSERT OR UPDATE ON mytable AS
BEGIN
   trigger_pkg.before_stmt_trigger;
END;

CREATE OR REPLACE TRIGGER after_stmt_trigger AFTER INSERT OR UPDATE ON mytable AS
BEGIN
   trigger_pkg.after_stmt_trigger;
END;

CREATE OR REPLACE TRIGGER for_each_row_trigger
BEFORE INSERT OR UPDATE ON mytable
WHEN (new.mycolumn IS NOT NULL) AS
BEGIN
   trigger_pkg.for_each_row_trigger(:new.rowid);
END;

【参考方案3】：

对于任何基于触发器（或基于应用程序代码）的解决方案，您需要 在多用户环境中进行锁定以防止数据损坏。 即使您的触发器有效，或者被重写以避免变异表 问题，它不会阻止 2 个用户同时更新 t1_appnt_evnt_id 到 t1_appnt_evnt_id 不是的行上的相同值 null：假设当前没有 t1_appnt_evnt_id=123 和 t1_prnt_t1_pk 不为空：

Session 1> update tbl1 
           set t1_appnt_evnt_id=123 
           where t1_prnt_t1_pk =456;
           /* OK, trigger sees count of 0 */

Session 2> update tbl1
           set t1_appnt_evnt_id=123
           where t1_prnt_t1_pk =789;
           /* OK, trigger sees count of 0 because 
              session 1 hasn't committed yet */

Session 1> commit;

Session 2> commit;

您现在有一个损坏的数据库！

避免这种情况的方法（在触发器或应用程序代码中）是锁定 执行检查前 t1_appnt_evnt_id=123 引用的表中的父行：

select appe_id 
into   v_app_id
from parent_table
where appe_id = :new.t1_appnt_evnt_id
for update;    

现在会话 2 的触发器必须等待会话 1 提交或回滚才能执行检查。

实现 Dave Costa 的索引会更简单、更安全！

最后，我很高兴没有人建议将 PRAGMA AUTONOMOUS_TRANSACTION 添加到您的触发器中：这通常在论坛上被建议并且在变异表问题消失的情况下起作用 - 但它使数据完整性问题更加严重！所以不要...

【讨论】：

实际上，我在任何尝试更新 cappec_appe_id 列时都会收到“表正在变异”错误。

对不起，我不明白你的评论？

【参考方案4】：

我在使用 Hibernate 时遇到了类似的错误。并使用

刷新会话

getHibernateTemplate().saveOrUpdate(o);
getHibernateTemplate().flush();

为我解决了这个问题。 （我没有发布我的代码块，因为我确信所有内容都已正确编写并且应该可以工作 - 但直到我添加了前面的 flush() 语句后才发布）。也许这可以帮助某人。