Fire Sequence of Database Triggers [ID 121196.

1]
Modified 16-APR-2009

Type BULLETIN

Status PUBLISHED

"Checked for relevance on 08-Oct-2007"

"Checked for relevance on 07-Apr-2009"
PURPOSE
------This document gives a brief summary of the various database triggers,
when they are executed and which execution model Oracle uses to maintain
the proper firing sequence of multiple triggers and constraint checking.
SCOPE & APPLICATION
------------------This document is intended for database administrators and/or database users
who want to review general information about the execution plan when
multiple triggers are fired. Detailed information can be found in the
manual "Oracle8i Concepts" (see: Related Documents).
FIRE SEQUENCE OF MULTIPLE DATABASE TRIGGERS
------------------------------------------Contents.
--------1. Introduction.
2. Trigger modes.
3. Trigger types.
4. What fires a trigger.
5. Single trigger timing.
6. Multiple trigger timing.
7. Rollback of trigger actions.
8. Data Dictionary trigger information.
9. Related documents.
1. Introduction
--------------Oracle allows you to define procedures called database triggers that execute
implicitly when an INSERT, UPDATE, or DELETE statement is issued against
the associated table or (in some cases) against a view, or when database
system actions occur. These procedures can be written in PL/SQL or Java
and are stored in the database, or they can be written as C callouts.
Similarity between procedure and trigger:
- both can be stored in the database;
- both can include SQL and PL/SQL or Java statements to execute as a unit;
- both can invoke stored procedures.
Difference between procedure and trigger:
- a procedure is explicitly executed by a user, application, or trigger
- a triggers is implicitly fired by Oracle when a triggering event occurs,
no matter which user is connected or which application is being used.

2. Trigger modes
---------------A trigger is in either of two distinct modes:
ENABLED : An enabled trigger executes its trigger action if:
- a triggering statement is issued and
- the trigger restriction (if any) evaluates to TRUE.
DISABLED: A disabled trigger does NOT execute its trigger action, even if:
- a triggering statement is issued and
- the trigger restriction (if any) would evaluate to TRUE.
The mode of a single trigger can be changed by:
ALTER TRIGGER my_trigger ENABLE;
ALTER TRIGGER my_trigger DISABLE;
The mode of all triggers associated with a table can be changed by:
ALTER TABLE my_table ENABLE ALL TRIGGERS;
ALTER TABLE my_table DISABLE ALL TRIGGERS;
A trigger can be explicitly compiled which eliminates the need for implicit
run-time recompilation. The trigger can be recompiled by:
ALTER TRIGGER my_trigger COMPILE;
3. Trigger types
---------------Oracle classifies four trigger types.
a. ROW triggers and STATEMENT triggers;
b. BEFORE and AFTER triggers (can apply to both statement and row triggers);
c. INSTEAD OF triggers;
d. System Events and User Events triggers.
4. What fires a trigger
----------------------A trigger can be fired upon the execution of a SQL statement or by an event:
a. SQL statements:
1) Data Manipulation Language (DML) statements that modify data in a table
(INSERT, UPDATE, or DELETE);
2) Data Definition Language (DDL) statements on any schema object
(CREATE, ALTER, or DROP).
b. Events:
1) database events (such as startup, and shutdown);
2) system events (such as a specific error message or any error message);
3) user events (such as logon, and logoff).
5. Single trigger timing
-----------------------This section describes the trigger timing of single triggers.

a. ROW triggers and STATEMENT triggers.

1) ROW triggers.
Trigger action is executed once for every row affected by the triggering
statement, such as a trigger fired by an UPDATE statement that updates
many rows.
2) STATEMENT triggers.
Trigger action is executed once for the triggering statement,
no matter how many rows it affects.
Note on Oracle8i PL/SQL: Instead of the normal FOR-loop, you have the
possibility to use bulk binding with the FORALL statement. The usage of
bulk-binding prevents the context switches between the PL/SQL and SQL
engines and improves performance. This does not change the execution
sequence of any existing row triggers: the row triggers are still executed
for every row. See Note:74123.1 "Bulk binding - What is it, Advantages,
and how to use it" for more information about bulk-binding.
b. BEFORE and AFTER triggers (can apply to both statement and row triggers)
1) BEFORE triggers.
Trigger action is executed before the triggering statement is executed.
2) AFTER triggers.
Trigger action is executed after the triggering statement is executed.
c. BEFORE/AFTER a ROW/STATEMENT triggers.
1) BEFORE ROW trigger.
Trigger action is executed before modifying each row, and before
checking appropriate integrity constraints (rows are not locked).
2) BEFORE STATEMENT trigger.
Trigger action is executed before executing the triggering statement.
3) AFTER ROW trigger.
Trigger action is executed after modifying each row and possibly
applying appropriate integrity constraints (rows are locked).
4) AFTER STATEMENT trigger.
Trigger action is executed after executing the triggering statement,
and applying any deferred integrity constraints.
d. INSTEAD OF triggers
Trigger action is executed instead of executing the triggering statement.
Can be used to modify views that cannot be modified directly through
DML statements (INSERT, UPDATE, and DELETE).
e. System Events and User Events triggers
1) System STARTUP triggers.
Trigger action is executed when the database is opened by an instance.
2) System SHUTDOWN triggers.
Trigger action is executed just before the server starts shutting down
an instance (trigger is not fired for abnormal instance shutdown).
3) System SERVERERROR triggers.
Trigger action is executed when a specified error occurs, or when any
error occurs if no error number is specified.
4) User LOGON triggers.
Trigger action is executed after a successful logon of a user.
5) User LOGOFF triggers.
Trigger action is executed at the start of a user logoff.
6) User DDL triggers.
Trigger action is executed BEFORE or AFTER the CREATE/ALTER/DROP
statement which effects a schema object.
7) User DML triggers.
Trigger action is executed BEFORE or AFTER the INSERT/UPDATE/DELETE
statement which effects rows in a table.

6. Multiple trigger timing

-------------------------Oracle uses the following execution model to maintain the proper firing
sequence of multiple triggers and constraint checking:
a. Execute all BEFORE statement triggers that apply to the statement.
b. Loop for each row affected by the SQL statement:
1) Execute all BEFORE row triggers that apply to the statement.
2) Lock and change row, and perform integrity constraint checking
(the lock is not released until the transaction is committed).
3) Execute all AFTER row triggers that apply to the statement.
c. Complete deferred integrity constraint checking.
d. Execute all AFTER statement triggers that apply to the statement.
Starting with Oracle8i, when a triggering statement (i.e. the SQL statement
or event that causes a trigger to fire) modifies one table in a referential
constraint (either the primary key or foreign key table), and a triggered
statement modifies the other, only the triggering statement will check the
integrity constraint (i.e. is deferred). This allows row triggers to enhance
referential integrity. In Oracle8, an AFTER ROW INSERT trigger would not be
fired due to ORA-2291 (integrity constraint violated - parent key not found).
Although triggers of different types are fired in a specific order,
triggers of the same type for the same statement are not guaranteed to fire
in any specific order.
For example, all BEFORE row triggers for a single UPDATE statement
may not always fire in the same order. Design your applications so they
do not rely on the firing order of multiple triggers of the same type.
Note: Triggers can also contain statements that cause other triggers
to fire (cascading triggers).
7. Rollback of trigger actions
-----------------------------An important property of the execution model is that all actions and checks
done as a result of a SQL statement must succeed. If an exception is raised
within a trigger, and the exception is not explicitly handled, all actions
performed as a result of the original SQL statement, including the actions
performed by fired triggers, are rolled back.
Thus, integrity constraints cannot be compromised by triggers. The execution
model takes into account integrity constraints and disallows triggers that
violate declarative integrity constraints.
8. Data Dictionary trigger information
-------------------------------------Trigger information such as the status, mode, type, event, etc.
can be retrieved from the following views:
a. user_objects
/ all_objects
/ dba_objects
b. user_triggers / all_triggers / dba_triggers
c. user_trigger_cols / all_trigger_cols / dba_trigger_cols
A combination of these views will result in all essential trigger information:

SELECT t.owner,t.trigger_name,t.status "STATUS(TRIG)",

o.status "STATUS(OBJ)",t.table_owner,t.table_name,tc.column_name,
t.trigger_type,t.triggering_event,t.trigger_body
FROM all_triggers t, all_trigger_cols tc, all_objects o
WHERE t.owner=tc.trigger_owner (+)
AND o.owner=t.owner
AND t.trigger_name=tc.trigger_name (+)
AND t.trigger_name=o.object_name
AND t.trigger_name='MY_TRIGGER'

TRIGGER_OWNER TRIGGER_NAME STATUS (TRIG) STATUS(OBJ)

-------------- ------------- ------------- -----------SYSTEM
MY_TRIGGER ENABLED
VALID
TABLE_OWNER TABLE_NAME COLUMN_NAME TRIGGER_TYPE
TRIGGERING_EVENT
------------ ----------- ------------ ---------------- -----------------SCOTT
EMP
SAL
BEFORE EACH ROW INSERT OR UPDATE
TRIGGER_BODY
------------------------------------------------------------------------BEGIN NULL; END;
9. Related documents
-------------------Part No. A96524-01 "Oracle9i Database Concepts Release 2 (9.2)",
Chapter 17 "Triggers".