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

296
CHAPTER 9 ■ REDO AND UNDO
If we insert 10,000 rows and only commit when all 10,000 are inserted, we get results
similar to the following:
begin /* commit size = 10000 */ commit; end;
....
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
log file sync 1 0.00 0.00
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
When we committed after every INSERT, we waited almost every time—and if you wait a
little bit of time but you wait often, then it all adds up. Fully two seconds of our runtime was
spent waiting for a COMMIT to complete—in other words, waiting for LGWR to write the redo to
disk. In stark contrast, when we committed once, we didn’t wait very long (not a measurable
amount of time actually). This proves that a COMMIT is a fast operation; we expect the response
time to be more or less flat, not a function of the amount of work we’ve done.
So, why is a COMMIT’s response time fairly flat, regardless of the transaction size? Before we
even go to COMMIT in the database, we’ve already done the really hard work. We’ve already modified
the data in the database, so we’ve already done 99.9 percent of the work. For example,
operations such as the following have already taken place:
• Undo blocks have been generated in the SGA.
• Modified data blocks have been generated in the SGA.
• Buffered redo for the preceding two items has been generated in the SGA.
• Depending on the size of the preceding three items, and the amount of time spent,
some combination of the previous data may be flushed onto disk already.
• All locks have been acquired.
When we COMMIT, all that is left to happen is the following:
• An SCN is generated for our transaction. In case you are not familiar with it, the SCN is
a simple timing mechanism Oracle uses to guarantee the ordering of transactions and
to enable recovery from failure. It is also used to guarantee read-consistency and checkpointing
in the database. Think of the SCN as a ticker; every time someone COMMITs, the
SCN is incremented by one.
• LGWR writes all of our remaining buffered redo log entries to disk and records the SCN in
the online redo log files as well. This step is actually the COMMIT. If this step occurs, we
have committed. Our transaction entry is “removed” from V$TRANSACTION—this shows
that we have committed.
• All locks recorded in V$LOCK held by our session are released, and everyone who was
enqueued waiting on locks we held will be woken up and allowed to proceed with their
work.