Example 1 - Before insert trigger which modifies the values being inserted
create or replace trigger konverto
before insert on employees
for each row
begin
dbms_output.put_line('inside trigger');
:new.salary :=100;
end;
Try to remove the for each row clause.
Discuss the result.
Try to change the timing when the trigger fires from before to after .
Discuss the result.
Example 2 - Before update trigger which modifies the values being modified
create or replace trigger konverto2
before update on employees
for each row
begin
dbms_output.put_line('inside trigger');
:new.salary :=300;
end;
Exercice - Before triggers - try it your self
Example table
CREATE TABLE orders
( order_id number(5),
quantity number(4),
cost_per_item number(6,2),
total_cost number(8,2),
updated_date date,
updated_by varchar2(10)
);
Write a trigger which modifies the update_date column to by sysdate whenever the orders table is updated.
Solution
CREATE OR REPLACE TRIGGER orders_before_update
BEFORE UPDATE
ON orders
FOR EACH ROW
DECLARE
v_username varchar2(10);
BEGIN
-- Find username of person performing UPDATE on the table
SELECT user INTO v_username
FROM dual;
-- Update updated_date field to current system date
:new.updated_date := sysdate;
-- Update updated_by field to the username of the person performing the UPDATE
:new.updated_by := v_username;
END;
Compound DML Triggers
In Oracle 11g, the concept of compound trigger was introduced. A compound trigger is a single trigger on a table that enables you to specify actions for each of four timing points:
Before the firing statement
Before each row that the firing statement affects
After each row that the firing statement affects
After the firing statement
With the compound trigger, both the statement-level and row-level action can be put up in a single trigger. Plus there is an added advantage: it allows sharing of common state between all the trigger-points using variable. This is because compound trigger in oracle 11g has a declarative section where one can declare variable to be used within trigger. This common state is established at the start of triggering statement and is destroyed after completion of trigger
When to use Compound Triggers
The compound trigger is useful when you want to accumulate facts that characterize the “for each row” changes and then act on them as a body at “after statement” time. Two popular reasons to use compound trigger are:
To accumulate rows for bulk-insertion. We will later see an example for this.
To avoid the infamous ORA-04091: mutating-table error.
Syntax
CREATEORREPLACETRIGGERcompound_trigger_name
FOR[INSERT|DELETE]UPDATE[OFcolumn] ONtable
COMPOUND TRIGGER
-- Declarative Section (optional)
-- Variables declared here have firing-statement duration.
--Executed before DML statement
BEFORE STATEMENT IS
BEGIN
NULL;
ENDBEFORE STATEMENT;
--Executed before each row change- :NEW, :OLD are available
BEFORE EACH ROW IS
BEGIN
NULL;
ENDBEFORE EACH ROW;
--Executed aftereach row change- :NEW, :OLD are available
AFTEREACH ROW IS
BEGIN
NULL;
ENDAFTEREACH ROW;
--Executed after DML statement
AFTERSTATEMENT IS
BEGIN
NULL;
ENDAFTERSTATEMENT;
ENDcompound_trigger_name;
Compound Triggers Rules
A compound trigger must be a DML trigger.
A compound trigger must be defined on either a table or a view.
OLD, :NEW, and :PARENT cannot appear in the declarative part, the BEFORE STATEMENT section, or the AFTER STATEMENT section.
Only the BEFORE EACH ROW section can change the value of :NEW
Example: Using Compound Triggers in Table Auditing
Lets create a compound trigger for auditing a large table called ‘employees’. Any changes made in any field of ‘employees’ table needs to be logged in as a separate row in audit table ‘aud_empl’. Since each row update in employees table needs to make multiple inserts in the audit table, we should consider using a compound trigger so that batching of inserts can be performed.
But before that we need to create our Tables:
--Target Table
CREATETABLEemployees(
emp_id varchar2(50) NOTNULLPRIMARYKEY,
namevarchar2(50) NOTNULL,
salary number NOTNULL
);
Audit table
CREATE TABLE "AUD_EMP"
( "UPD_BY" VARCHAR2(50 BYTE) NOT NULL ENABLE,
"UPD_DT" DATE NOT NULL ENABLE,
"FIELD" VARCHAR2(50 BYTE) NOT NULL ENABLE,
"FROM_VALUE" VARCHAR2(50 BYTE) NOT NULL ENABLE,
"TO_VALUE" VARCHAR2(50 BYTE) NOT NULL ENABLE,
"EMP_ID" NUMBER,
"ACTION" VARCHAR2(20 BYTE)
) ;
Now the trigger… On update of each row instead of performing an insert operation for each field, we store (buffer) the required attributes in a Arrays of type aud_emp. Once a threshold is reached (say 1000 records), we flush the buffered data into audit table and reset the counter for further buffering. And at last, as part of AFTER STATEMENT we flush any remaining data left in buffer.
--Trigger
CREATEORREPLACETRIGGERaud_emp
FORINSERTORUPDATE
ONemployees
COMPOUND TRIGGER
TYPE t_emp_changes ISTABLEOFaud_emp%ROWTYPE INDEXBYSIMPLE_INTEGER;
v_emp_changes t_emp_changes;
v_index SIMPLE_INTEGER := 0;
v_threshhold CONSTANT SIMPLE_INTEGER := 1000; --maximum number of rows to write in one go.
Now any changes in any field of employees will to be written in aud_emp table. A beauty of this approach is we were able to access same data ‘v_emp_changes’ between statement and row triggering events.
With this in mind, one can see that it make sense to move v_emp_changes(v_index).upd_by := SYS_CONTEXT ('USERENV', 'SESSION_USER'); inside declarative(or BEFORE STATEMENT if complex computation) section as a pre-processing step. To do so, v_user variable declared in trigger body can be used and assigned value of logged in user in the declarative section itself. So that same computation is not made during after-each-row section, and is computed and stored in a variable just once before row-level execution begins.
Using the Data Definition Language (DDL) triggers, the Oracle DBA can automatically track all changes to the database, including changes to tables, indexes, and constraints. The data from this trigger is especially useful for change control for the Oracle DBA.
DDL triggers execute every time a DDL statement is executed, and adds new entries to your new table, as shown below:
connect sys/manager
create or replace trigger DDLTrigger AFTER DDL ON DATABASE BEGIN insert into perfstat.stats$ddl_log ( user_name, ddl_date, ddl_type, object_type, owner, object_name ) VALUES ( ora_login_user, sysdate, ora_sysevent, ora_dict_obj_type, ora_dict_obj_owner, ora_dict_obj_name );
