在删除时使用外键变换表错误

时间:2011-06-24 13:10:09

标签: oracle plsql triggers foreign-keys

在我们的数据库中,我们有一个表,其中记录由来自大约4个其他表的id引用。这些'子'表具有'master'表的外键,'on delete set null'。所有表都有一个mutating-tables系统(即:包含plsql-table的包,在从after语句触发器调用过程时处理记录)。 但是,在删除master-table中的记录时,子记录会给出'table is mutating'错误。我发现有点奇怪,因为外键似乎触发了一些隐含的update-statement,它位于plsql-table中。

我所追求的只是试图找到原因,我似乎无法挖掘一些相关信息! 当然,我们确实有一个解决方案,只需在关联表中将引用的id字段设置为null,从master的after语句触发器开始,但我仍然想知道为什么会发生这种情况。

重现错误的代码:

CREATE TABLE master_table (ID NUMBER(5) NOT NULL);
CREATE TABLE child_table (ID NUMBER(5) NOT NULL, master_id NUMBER(5));

alter table master_table add constraint master_pk primary key (ID);

alter table child_table add constraint child_pk primary key (ID);

ALTER TABLE child_table
  add constraint on_delete_master foreign key (master_id)
  references master_table (ID) on delete set null;

CREATE OR REPLACE PACKAGE pkg_child
IS
PROCEDURE init_temp;
PROCEDURE add_temp(i_action IN VARCHAR2, 
                   i_master_old IN child_table.master_id%TYPE, 
                   i_master_new IN child_table.master_id%TYPE);
PROCEDURE process_temp;
END;
/
CREATE OR REPLACE PACKAGE BODY pkg_child IS
   TYPE temp_record IS RECORD(
      action        VARCHAR2(1),
      old_master_id child_table.master_id%TYPE,
      new_master_id child_table.master_id%TYPE);

   TYPE type_temp IS TABLE OF temp_record INDEX BY BINARY_INTEGER;

   tab_temp type_temp;

   PROCEDURE init_temp IS
   BEGIN
      tab_temp.delete;
   END;

   PROCEDURE add_temp(i_action     IN VARCHAR2,
                      i_master_old IN child_table.master_id%TYPE,
                      i_master_new IN child_table.master_id%TYPE) IS
      v_id BINARY_INTEGER;
   BEGIN
      v_id := nvl(tab_temp.last, 0) + 1;
      tab_temp(v_id).action := i_action;
      tab_temp(v_id).old_master_id := i_master_old;
      tab_temp(v_id).new_master_id := i_master_new;
   END;

   PROCEDURE process_temp IS
      v_id    BINARY_INTEGER;
      v_total NUMBER;
   BEGIN
      v_id := tab_temp.first;
      WHILE v_id IS NOT NULL LOOP
         IF tab_temp(v_id).action = 'U' THEN
            SELECT COUNT(1)
              INTO v_total
              FROM child_table;
         END IF;
         v_id := tab_temp.next(v_id);
      END LOOP;
   END;
END;
/
CREATE OR REPLACE TRIGGER child_table_bs
 BEFORE 
 INSERT OR UPDATE OR DELETE
 ON child_table
 REFERENCING OLD AS OLD NEW AS NEW
BEGIN
  pkg_child.init_temp;
END;
/
CREATE OR REPLACE TRIGGER child_table_ar
 AFTER 
 INSERT OR DELETE OR UPDATE
 ON child_table
 REFERENCING OLD AS OLD NEW AS NEW
 FOR EACH ROW 
DECLARE
   v_action VARCHAR2(1);
BEGIN
   IF inserting THEN
      v_action := 'I';
   ELSIF updating THEN
      v_action := 'U';
   ELSIF deleting THEN
      v_action := 'D';
   END IF;
   pkg_child.add_temp(v_action, :old.id, :new.id);
END;
/
CREATE OR REPLACE TRIGGER child_table_as
 AFTER 
 INSERT OR UPDATE OR DELETE
 ON child_table
 REFERENCING OLD AS OLD NEW AS NEW
BEGIN
 pkg_child.process_temp;
END;
/

INSERT ALL 
   INTO master_table (id) VALUES (1) 
   INTO master_table (id) VALUES (2) 
   INTO master_table (id) VALUES (3) 
   INTO master_table (id) VALUES (4)
SELECT * FROM dual;

INSERT ALL
   INTO child_table (id, master_id) VALUES (1, NULL) 
   INTO child_table (id, master_id) VALUES (2, 1) 
   INTO child_table (id, master_id) VALUES (3, 2) 
   INTO child_table (id, master_id) VALUES (4, NULL)
SELECT * FROM dual;

-- error on this delete: mutating tables
-- why?
DELETE FROM master_table
 WHERE id = 2;

清理代码:

DROP TRIGGER child_table_bs;
DROP TRIGGER child_table_ar;
DROP TRIGGER child_table_as;
DROP PACKAGE pkg_child;
DROP TABLE child_table;
DROP TABLE master_table;

由于

1 个答案:

答案 0 :(得分:0)

您有一个语句,主表中的DELETE可能会影响多行。 由于CASCADE约束,每个已删除的行将触发CHILD表的隐式/递归UPDATE语句。也就是说,理论上你可以有多个子表的UPDATE。

说你做了DELETE FROM master_table WHERE id in (1, 2)

这将生成两个UPDATE child_table语句。其中每个都会尝试执行AFTER UPDATE触发器,因此您将获得两次

的执行
SELECT COUNT(1)
INTO v_total
FROM child_table

单个DELETE语句下的任何SELECT的结果应该在特定时间点保持一致。但SELECT不会在DELETE结束时发生,而是在删除期间执行多次,每次都可能具有不同的结果。 Oracle可以计算出你想要/期望的结果,因此会抛出变异表错误。

在不了解业务需求的情况下,很难推荐解决方案。像Oracle一样,我们不知道你要做什么。可能通过在事务结束时执行的ON-COMMIT MV或DBMS_JOB来解决这种情况。