Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








Oracle Trigger tips

Oracle Consulting Tips by Burleson


What's a trigger?  Well, Trigger was the name of Roy Rogers' horse, but in the Oracle world, a trigger is an important system-level component that allows you to associate a "hunk of code" (usually PL/SQL or Java) with a specific system event, namely DML (SQL insert, update and delete) statements.

See here why triggers are nor the best choice for data validation.

A trigger is like an IDMS user exit, an opening in the code where you can branch out and "do your own thing", prior to performing the insert, update or delete.  The problems with Oracle triggers includes:

  • Trigger Recursion - A DML event may effect thousands of rows at once, which in-turn will have triggered events, triggered by the trigger (see the mutating table problem).
  • Incorrect trigger usage - Triggers are expensive events to Oracle and they should only be used then the design mandates a system-wide events such as auditing or calculating a complex table column values.

Steve Callan has these notes on using Oracle triggers:

Oracle defines triggers as "procedures that are stored in the database and implicitly run, or fired, when something happens." [Page 15-1, Application Developer's Guide] What is the "something" that happens to make a trigger fire? There are 12 "some things" that can cause triggers to fire: Before/After during Insert/Update/Delete on a Row/Table (which leads to the 2x3x2=12 types).

The DML triggers are the best known, but there are more available since Oracle8i was released. The additional triggers, or types of triggers, are instead-of triggers, database event triggers, and DDL triggers. Instead-of triggers are used when views are involved, and are a good way of avoiding the mutating table trigger-related error.

Database event triggers can be divided into two categories: on the database, where triggers occur for all users, and on a schema, where triggers occur for that user. Data definition types of triggers can be used to capture events related to DDL statements such as create, drop, and alter.

Oracle places a size limit of 32KB on a trigger statement. How "big" is 32KB of data? Up to the question mark, this article used about 25KB, using around 870 words and over 4,000 characters, just to give you a rough idea of how much code you can write under 32KB. Is there a way around the 32KB limit? Yes, you can call external procedures.

If you do not use LONG or LONG RAW data types, any restrictions concerning these are transparent to you. Several other restrictions and one interesting restriction has to do with the order in which triggers are fired.

So what are some design issues when considering the use of triggers? When considering which type of trigger to use in a DML operation, you want to avoid having a hair trigger, that is, firing a trigger when it is not the appropriate time to fire it. Conversely, you do not want the correct trigger to fire late.

Suppose you have a banking application with a trigger that checks to see if the DML operation is occurring after business hours (assuming that it should only be performed during business hours). The DML operation involves updating a million records. It does not make sense to let Oracle perform the update, only to have it canceled or rolled back because you used an AFTER trigger instead of a BEFORE trigger to check the time of day. The general rule here would be to check or enforce the business logic BEFORE using database resources. In this example, an AFTER trigger can be used to record what happened.

Oracle fires all triggers of a type, then all triggers of another type, and so on. You have no control over which type is fired first, and whichever type is fired after the first type will see any changes made by the first type, and that cascades down (third type sees changes made by the second type, and so on).

Finally, the mutating table error, ORA-04091 table owner.table_name is mutating, trigger/function may not see it has made DBAs trigger-happy in ways we would rather they not be exposed to.  . .

There are a great many things you can do with triggers, whether they are based on DML statements or system events. As a developer or DBA (or both), there is no such thing as having too many tricks up your sleeve.

In terms of job or role separation, you can think of the DML triggers as being in the purview of the developer, and the system event triggers being in the DBA's, but a good DBA should possess some decent programming skills of his or her own, and that's where knowing how to avoid problems with DML triggers comes into play. Being and staying well-informed on the use (and limitations) of triggers

For my research on Oracle trigger functions, see:

Oracle trigger tips, and many other Oracle performance metrics are discussed in my book "Oracle Tuning" by Rampant TechPress.  You can buy it directly from the publisher and save 30% at this link:



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.