Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » General »
Latches in Oracle
|
Introduction
The Oracle RDBMS makes use of different types of locking mechanisms. They are mainly latches, enqueues, distributed locks and global locks (used in parallel instance implementations).
This article attempts to give a clear understanding of how latches are implemented in the Oracle RDBMS and what causes latch contention. The information provided can be used in tuning the various kinds of latches discussed.
What is a Latch?
Latches are low level serialization mechanisms used to protect shared data structures in the SGA. The implementation of latches is operating system dependent, particularly in regard to whether a process will wait for a latch and for how long.
A latch is a type of a lock that can be very quickly acquired and freed. Latches are typically used to prevent more than one process from executing the same piece of code at a given time. Associated with each
latch is a cleanup procedure that will be called if a process dies while holding the latch. Latches have an associated level that is used to prevent deadlocks. Once a process acquires a latch at a certain level it
cannot subsequently acquire a latch at a level that is equal to or less than that level (unless it acquires it nowait).
When do we need to obtain a Latch?
A process acquires a latch when working with a structure in the SGA (System Global Area). It continues to hold the latch for the period of time it works with the structure. The latch is dropped when the process is finished with the structure. Each latch protects a different set of data, identified by the name of the latch.
Oracle uses atomic instructions like "test and set" for operating on latches. Processes waiting to execute a part of code for which a latch has already been obtained by some other process will wait until the latch is released. Examples are redo allocation latches, copy latches, archive control latch etc. The basic idea is to block concurrent access to shared data structures. Since the instructions to set and free latches are atomic, the OS guarantees that only one process gets it. Since it is only one instruction, it is quite fast. Latches are held for short periods of time and provide a mechanism for cleanup in case a holder dies abnormally while holding it. This cleaning is done using the services of PMON.
Latches request modes?
Latches request can be made in two modes: "willing-to-wait" or "no wait". Normally, latches will be requested in "willing-to-wait" mode. A request in "willing-to-wait" mode will loop, wait, and request again until the latch is obtained. In "no wait" mode the process requests the latch. If one is not available, instead of waiting, another one is requested. Only when all fail does the server process have to wait.
Examples of "willing-to-wait" latches are: shared pool and library cache latches an example of "no wait" latches is the redo copy latch.
What causes latch contention?
If a required latch is busy, the process requesting it spins, tries again and if still not available, spins again. The loop is repeated up to a maximum number of times determined by the initialization parameter SPIN_COUNT. If after this entire loop, the latch is still not available, the process must yield the CPU and go to sleep. Initially is sleeps for one centisecond. This time is doubled in every subsequent sleep.
This causes a slowdown to occur and results in additional CPU usage, until a latch is available. The CPU usage is a consequence of the "spinning" of the process. "Spinning" means that the process continues to look for the availability of the latch after certain intervals of time, during which it sleeps.
How to identify contention for internal latches?
Relevant data dictionary views are available to fetch the information about latches. Some are given below.
V$LATCH
V$LATCHHOLDER
V$LATCHNAME
Thanks,
Vijay Kumar (Win)
|
Responses
|
No responses found. Be the first to respond and make money from revenue sharing program.
|
|