Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 9 ■ REDO AND UNDO 297
• Some of the blocks our transaction modified will be visited and “cleaned out” in a
fast mode if they are still in the buffer cache. Block cleanout refers to the lock-related
information we store in the database block header. Basically, we are cleaning out our
transaction information on the block, so the next person who visits the block won’t
have to. We are doing this in a way that need not generate redo log information, saving
considerable work later (this is discussed more fully in the upcoming “Block Cleanout”
section).
As you can see, there is very little to do to process a COMMIT. The lengthiest operation is,
and always will be, the activity performed by LGWR, as this is physical disk I/O. The amount of
time spent by LGWR here will be greatly reduced by the fact that it has already been flushing the
contents of the redo log buffer on a recurring basis. LGWR will not buffer all of the work you do
for as long as you do it; rather, it will incrementally flush the contents of the redo log buffer in
the background as you are going along. This is to avoid having a COMMIT wait for a very long
time in order to flush all of your redo at once.
So, even if we have a long-running transaction, much of the buffered redo log it generates
would have been flushed to disk, prior to committing. On the flip side of this is the fact that
when we COMMIT, we must wait until all buffered redo that has not been written yet is safely on
disk. That is, our call to LGWR is a synchronous one. While LGWR may use asynchronous I/O to
write in parallel to our log files, our transaction will wait for LGWR to complete all writes and
receive confirmation that the data exists on disk before returning.
Now, earlier I mentioned that we were using a Java program and not PL/SQL for a reason—
and that reason is a PL/SQL commit-time optimization. I said that our call to LGWR is a
synchronous one, and that we wait for it to complete its write. That is true in Oracle 10g
Release 1 and before for every programmatic language except PL/SQL. The PL/SQL engine,
realizing that the client does not know whether or not a COMMIT has happened in the PL/SQL
routine until the PL/SQL routine is completed, does an asynchronous commit. It does not
wait for LGWR to complete; rather, it returns from the COMMIT call immediately. However, when
the PL/SQL routine is completed, when we return from the database to the client, the PL/SQL
routine will wait for LGWR to complete any of the outstanding COMMITs. So, if you commit 100
times in PL/SQL and then return to the client, you will likely find you waited for LGWR once—
not 100 times—due to this optimization. Does this imply that committing frequently in
PL/SQL is a good or OK idea? No, not at all—just that it is not as bad an idea as it is in other
languages. The guiding rule is to commit when your logical unit of work is complete—not
before.
■Note This commit-time optimization in PL/SQL may be suspended when you are performing distributed
transactions or Data Guard in maximum availability mode. Since there are two participants, PL/SQL must
wait for the commit to actually be complete before continuing on.
To demonstrate that a COMMIT is a “flat response time” operation, we’ll generate varying
amounts of redo and time the INSERTs and COMMITs. To do this, we’ll again use AUTOTRACE in
SQL*Plus. We’ll start with a big table of test data we’ll insert into another table and an empty
table: