Trigger Firing Property

Trigger Firing Property
You can control a DML or DDL trigger's firing property using the SET_TRIGGER_FIRING_PROPERTY procedure in the DBMS_DDL package. This procedure lets you specify whether a trigger's firing property is set to fire once. If a trigger's firing property is set to fire once, then it does not fire in the following cases: When a relevant change is made by an apply process When a relevant change results from the execution of one or more apply errors using the EXECUTE_ERROR or EXECUTE_ALL_ERRORS procedure in the DBMS_APPLY_ADM package If a trigger is not set to fire once, then it fires in both of these cases. By default, DML and DDL triggers are set to fire once. You can check a trigger's firing property by using the IS_TRIGGER_FIRE_ONCE function in the DBMS_DDL package. For example, in the hr schema, the update_job_history trigger adds a row to the job_history table when data is updated in the job_id or department_id column in the employees table. Suppose, in a Streams environment, the following configuration exists: A capture process captures changes to both of these tables at the dbs1.net database. A propagation propagates these changes to the dbs2.net database. An apply process applies these changes at the dbs2.net database. The update_job_history trigger exists in the hr schema in both databases. If the update_job_history trigger is not set to fire once at dbs2.net in this scenario, then these actions result: The job_id column is updated for an employee in the employees table at dbs1.net. The update_job_history trigger fires at dbs1.net and adds a row to the job_history table that records the change. The capture process at dbs1.net captures the changes to both the employees table and the job_history table. A propagation propagates these changes to the dbs2.net database. An apply process at the dbs2.net database applies both changes. The update_job_history trigger fires at dbs2.net when the apply process updates the employees table. In this case, the change to the employees table is recorded twice at the dbs2.net database: when the apply process applies the change to the job_history table and when the update_job_history trigger fires to record the change made to the employees table by the apply process. A database administrator might not want the update_job_history trigger to fire at the dbs2.net database when a change is made by the apply process. Similarly, a database administrator might not want a trigger to fire because of the execution of an apply error transaction. If the update_job_history trigger's firing property is set to fire once, then it does not fire at dbs2.net when the apply process applies a change to the employees table, and it does not fire when an executed error transaction updates the employees table. Also, if you use the ON SCHEMA clause to create a schema trigger, then the schema trigger fires only if the schema performs a relevant change. Therefore, when an apply process is applying changes, a schema trigger that is set to fire always fires only if the apply user is the same as the schema specified in the schema trigger. If the schema trigger is set to fire once, then it never fires when an apply process applies changes, regardless of whether the apply user is the same as the schema specified in the schema trigger. For example, if you specify a schema trigger that always fires on the hr schema at a source database and destination database, but the apply user at a destination database is strmadmin, then the trigger fires when the hr user performs a relevant change on the source database, but the trigger does not fire when this change is applied at the destination database. However, if you specify a schema trigger that always fires on the strmadmin schema at the destination database, then this trigger fires whenever a relevant change is made by the apply process, regardless of any trigger specifications at the source database.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14228/gen_rep.htm#STREP110