Oracle触发器报错table xxxx is mutating,trigger/function may not see it

写了一个数据更新的触发器 , 但是写完编译没问题 , 一使用就报错. 然后在PLsql中调试了一下,报了table xxxx is mutating,trigger/function may not see it这个错, 上网查了原来是这样.

1.

对于after 类型的 for each row 级别的triggers，不论哪种insert语句触发了trigger，

都不允许在 trigger 中访问本trigger所依赖的table

2.
对于before 类型的 for each row 级别的triggers，如果使用 insert into ... values 语句触发此trigger ，
则在trigger 中访问本table没有问题；但如果使用 insert into select .. from 语句触发此trigger ，
则在trigger 中访问本table就报ora-04091错误；


明明逻辑都正确,其中的sql语句单独拿出来也能用,调试的时候就是卡在那个地方.无语,真浪费时间啊...


只要按上面这两个规则,就会正常。

2017.3.24修改：
今天又写了一个触发器，如果update A表的某个字段触发这个触发器，里面的逻辑还是要查询所依赖的A表，又导致table xxxx is mutating,trigger/function may not see it这个错误。
就算按照上面的两个规则也不行，在网上查到可以用PRAGMA AUTONOMOUS_TRANSACTION; 
就可以执行成功，格式如下：
（以下转自http://blog.csdn.net/tw7752/article/details/44624437）
create or replace trigger tr_test  
after insert   
on test  
for each row  
declare  
PRAGMA AUTONOMOUS_TRANSACTION;  
begin  
   update test set column2=123 where column1=:new.column1  
end tr_test;  
AUTONOMOUS_TRANSACTION是指在function,procedure,trigger等subprograms中对事务进行自治管理,当在别的pl/sql block里取调用这些subprograms的时候这些subprograms并不随着父pl/sql block的失败而回滚,而是自己管自己commit;
注意慎用AUTONOMOUS_TRANSACTION。一个DML可能触发很多次触发器，因此产生了大量独立的事务，很容易产生死锁。
ASKTOM上对AUTONOMOUS_TRANSACTION的看法是：唯一的用途就是作审计日志，其他一概不该使用。
有人建议是取消使用触发器，把你的业务逻辑写到存储过程去。

PS：虽然这样执行成功，但不知后续会产生什么后果，是不是很容产生死锁等，以后会持续更新。如果好长时间不更就说明是问题不大的。
3月28日：因为业务上的原因没有采用PRAGMA AUTONOMOUS_TRANSACTION这个方式，也不用触发器了，代码都写到项目里。但是感觉用起来还是没问题的。