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

CHAPTER 6 ■ LOCKING AND LATCHING 221
Latches are locks designed to be held for extremely short periods of time—for example,
the time it takes to modify an in-memory data structure. They are used to protect certain
memory structures, such as the database block buffer cache or the library cache in the Shared
pool. Latches are typically requested internally in a “willing to wait” mode. This means that if
the latch is not available, the requesting session will sleep for a short period of time and retry
the operation later. Other latches may be requested in an “immediate” mode, which is similar
in concept to a SELECT FOR UPDATE NOWAIT, meaning that the process will go do something
else, such as try to grab an equivalent sibling latch that may be free, rather than sit and wait
for this latch to become available. Since many requestors may be waiting for a latch at the
same time, you may see some processes waiting longer than others. Latches are assigned
rather randomly, based on the luck of the draw, if you will. Whichever session asks for a latch
right after it was released will get it. There is no line of latch waiters—just a mob of waiters
constantly retrying.
Oracle uses atomic instructions like “test and set” and “compare and swap” for operating
on latches. Since the instructions to set and free latches are atomic, the operating system itself
guarantees that only one process gets to test and set the latch even though many processes
may be going for it simultaneously. Since the instruction is only one instruction, it can be
quite fast. Latches are held for short periods of time and provide a mechanism for cleanup in
case a latch holder “dies” abnormally while holding it. This cleanup process would be performed
by PMON.
Enqueues, which were discussed earlier, are another, more sophisticated serialization
device used when updating rows in a database table, for example. They differ from latches in
that they allow the requestor to “queue up” and wait for the resource. With a latch request,
the requestor session is told right away whether or not it got the latch. With an enqueue
lock, the requestor session will be blocked until it can actually attain it.
■Note Using SELECT FOR UPDATE NOWAIT or WAIT [n], you can optionally decide not to wait for an
enqueue lock if your session would be blocked, but if you do block and wait, you will wait in a queue.
As such, an enqueue is not as fast as a latch can be, but it does provided functionality over
and above what a latch can offer. Enqueues may be obtained at various levels, so you can have
many shared locks and locks with various degrees of shareability.
Latch “Spinning”
One thing I’d like to drive home with regard to latches is this: latches are a type of lock, locks
are serialization devices, and serialization devices inhibit scalability. If your goal is to construct
an application that scales well in an Oracle environment, you must look for approaches
and solutions that minimize the amount of latching you need to perform.
Even seemingly simple activities, such as parsing a SQL statement, acquire and release
hundreds or thousands of latches on the library cache and related structures in the Shared
pool. If we have a latch, then someone else might be waiting for it. When we go to get a latch,
we may well have to wait for it ourselves.