Sorry for the late reply.

Thank you for providing the links. I made it through the first half of the first link that your provided – those are long threads! I may be remembering incorrectly, but isn’t a SQL statement that is executed a single time in PL/SQL automatically added to the session’s cached cursors, while the same SQL statement must be executed three times normally, before it is added to the session’s cached cursors. I believe that Tom Kyte called a session cached cursor hit a “soft” soft parse, which is almost as efficient as if the client had left the cursor open and re-executed the SQL statement – so the soft parse count might not be too much of an issue in this case. Such a “soft” soft parse would still be included in the “parse count (total)” statistics, so I am not quite able to explain why that statistic value is roughly the same regardless of whether or not a row level trigger was used.

I think that I need to spend a little more time reading the threads that you linked to above.

Another thing to consider, is soft parsing of querys inside the trigger for multiple calls:
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2588723819082#56351588185822
Unless you are on 11g, where the changed the behavior:
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2588723819082#584022900346046668

Best regards

Joaquin Gonzalez

Thank you for the tip. I wonder if the PL/SQL execution engine handles the two approaches identically behind the scenes?

That is an interesting point that you make about having to repeat the code to retrieve the next value from the sequence – that is something that I had not considered. Having the sequence name located in one place would also make it a little easier to change the sequence name if that is necessary – but that is hopefully something that is very rare. One of the bad points of relying on a triger, however, is that it makes it a little more difficult to understand how the primary key values are populated – something that might be critical when troubleshooting unexpected behavior.

One part of the second script required nearly 4.5 hours to run on Oracle Database 11.1.0.6 on 64 bit Linux – that is much, much longer than the other release versions. Almost all of that time was spent with the session running on the CPU – this appears to be related to context switching considering that the majorty of the other statistics were identical. However, I cannot explain why 11.2.0.1 on 64 bit Linux did not suffer the same severe performance problem for that portion of the test script.

The amount of redo generated is interesting. It appears that 11.1.0.6 and above have an optimization that reduces the amount of redo generated when a trigger is present to populate the primary key value using a trigger and a multi-row insert is performed. On 10.2.0.2 and 10.2.0.5 the multi-row insert is essentially handled the same as many single row inserts when a trigger is present to populate the primary key column (more testing is probably required). It appears that if the trigger is removed, the amount of redo generated drops on 10.2.0.2 and above when a multi-row insert is performed. I believe that I have heard this feature described as batching block changes – notice that there is a sharp decrease in the number of “db block gets” when the redo generation drops significantly.

OLD-WAY:
SELECT S1.NEXTVAL INTO :NEW.C1 FROM DUAL;
NEW-WAY:
:NEW.C1:=S1.NEXTVAL;

But there was not timing difference on my 11.2 db.

I have never thought about the performance gain one can get by using directly the sequence into the insert statement instead of using a row trigger for that. You are giving more strength to Tom Kyte when he says “I hate triggers”.

But I have only few remarks.

(a) Using the sequence directly into the insert statement needs to be done in every insert statement that needs to populate the corresponding primary key while the use of trigger guarantees that every insert will be using the nextval on the trigger

(b) Recently we have backuped data of several parent/child tables from production to test environment. And it was very important to keep the same values of primary key/foreign key. We have disabled the constraints but forget to disable triggers that are responsible of populating PKs.This is why I prefer this:

CREATE OR REPLACE TRIGGER TR1
BEFORE INSERT
ON ST
REFERENCING NEW AS NEW
FOR EACH ROW
BEGIN
If :NEW.C1 IS NULL
THEN
SELECT S1.NEXTVAL INTO :NEW.C1 FROM DUAL;
END IF;
END;
/

Best regards

Mohamed Houri

Nice example of one potential difference… but there is a reason for the difference in redo generation and the number of DB BLOCK GETS. I have a second test case script that demonstrates the reason for the redo difference. It will likely take at least 10 to 12 hours before I update this article with the second test case script with output from Oracle Database 10.2.0.5, 11.1.0.7, and 11.2.0.1 all on 64 bit Windows; and 11.1.0.6 and 11.2.0.1 both on 64 bit Linux using similar hardware to what was used for the Windows test. I do not have all of the results yet, but the results might be interesting.

SQL> spool off


While the trigger approach generated about 49MB redo, the other approach generated just over 8MB of redo. I am not saying this is the main reason for the difference between run-time performance but my intention is to suggest that while the execution time is extremely important criteria, one should not ignore the impact on other factors.