I’ve faced a lot of issues with using of triggers incorrectly. Actually the problem is not only in integrity constraint but in supporting whole bussiness rules by triggers. It’s quite often when developers use the triggers as a kind of simplest way to organize the rule support as result tables overgrowns with triggers. The core of the problem is that it’s impossible to manage that kind of integrity constraitns and overgrown leads to large number of locks and even deadlocks in highly concurrent systems. I could call it as triggers’ shower. Another way to get poor perfomance with triggers to use large number of operations in the trigger’s body it’s common as well which seems to be almost the same problem.

Kind regards,
Iliya

We should never user triggers to enforce integrity. Because to do so correctly, you
need to lock the table (not at the row level but at the table level).
You know why? because of this fundamental principle of read-consistency : readers do
not block writers and writers do not block readers. In a mutli-user concurency systems
enforcing integrity in triggers is almost wrong.

Instead if you implement an indexed Foreign key (with not null foreign key columns if possible),
then you are 100% sure that your integrity constraint is always validated by Oracle and without any locking

Triggers can also be used to do DML. I have used them very often to log the modifications done on a table.
I have always used insert into values() in this audit triggers.

Regards

Mohamed Houri

Thank you for the information. The description matches what we are experiencing…

Cheers,
Chris

About triggers and constrains… I only agree with you when the constraint cannot be implemented with a simple foreign key. In other words, when a foreign key can be used the solution with a trigger is a no-go for me.
About DML and triggers… It really depends, there are situations where it is “fine” (or, at least, not that bad). In this case, since the tables are loaded by ETL jobs, it is not good at all.

Cheers,
Chris

yes, it’s a bug.

> it (the trigger) exists just because triggers are used to implement integrity constraints (something you should avoid, by the way…)

No, no, no…
What should be avoided is: triggers that perform DML. Because then things automagically start happening.
Triggers that implement integrity constraints on the other hand, only execute queries: *which is fine*!.
What’s wrong is the trigger on T1: it performs DML…
Just my opinion.