Latches are similar to locks but they operate on memory to protect code and internal data structures by preventing concurrent access["Latches are serialization mechanisms that protect areas of Oracle’s shared memory (the SGA)"]. For example, the LRU latches are used when managing the buffer cache, an operation that is restricted to being run by a single process; other processes must wait for the current process to complete its actions on the buffer cache before the next one in line can proceed. The latch holds this structure for the current process to access; when the current process is done the latch is released and the next process in the queue can acquire it.
In simple terms latches prevent two processes from simultaneously updating - and possibly corrupting - the same area of the SGA.. It is low-level serialization mechanism.
In-other way we can say, Latches are like locks for RAM memory structures to prevent concurrent access and ensure serial execution of kernel code. The LRU (least recently used) latches are used when seeking, adding, or removing a buffer from the buffer cache, an action that can only be done by one process at a time.Contention on an LRU latch usually means that there is a RAM data block that is in high demand. If a latch is not available a 'latch free miss' statistics is recorded.
If the latch is already in use, Oracle can assume that it will not be in use for long, so rather than go into a passive wait (e.g., relinquish the CPU and go to sleep) Oracle will retry the operation a number of times before giving up. This algorithm is called acquiring a spin lock and the number of “spins” before sleeping is controlled by the Oracle initialization parameter “_spin_count”.
Locks
Protect the logical contents of the database object (table, index) from other transactions.
Are held for the transaction duration.
Provide rollback capability for the associated transaction.
Latch
Protect the critical sections of the associated internal data structures from other threads.
Are held only until the operation completes and then are released.
Prevent concurrent access to a memory structure.
Latch occurrence:
Oracle sessions need to update or read from the SGA for almost all database operations. For instance:
When a session reads a block from disk, it must modify a free block in the buffer cache and adjust the buffer cache LRU (Least Recently Used) chain.
When a session reads a block from the SGA, it will modify the LRU chain.
When a new SQL statement is parsed, it will be added to the library cache within the SGA.
As modifications are made to blocks, entries are placed in the redo buffer.
The database writer periodically writes buffers from the cache to disk (and must update their status from “dirty” to “clean”).
The redo log writer writes entries from the redo buffer to the redo logs.
Latches prevent any of these operations from colliding and possibly corrupting the SGA.
Root causes of Latch contention:
The latches that most frequently affect performance are those protecting the buffer cache, areas of the shared pool and the redo buffer.
Library cache and shared pool latches: These latches protect the library cache in which shareable SQL is stored. In a well defined application there should be little or no contention for these latches, but in an application that uses literals instead of bind variables library cache contention is common, it will be good to use soft parsing over hard to avoid library cache contention.
Cache buffers chain latches: These latches are held when sessions read or write to buffers in the buffer cache. There are typically a very large number of these latches each of which protects only a handful of blocks. Contention on these latches is typically caused by concurrent access to a very “hot” block and the most common type of such a hot block is an index root or branch block (since any index based query must access the root block).
Redo copy/redo allocation latches: These latches protect the redo log buffer, which buffers entries made to the redo log. These latches were a significant problem in earlier versions of Oracle, but are rarely encountered today.
Run the following queries for Latch:
SELECT n.name, l.sleeps
FROM v$latch l, v$latchname n
WHERE n.latch#=l.latch# and l.sleeps > 0 order by l.sleeps;
SELECT n.name, SUM(w.p3) Sleeps
FROM V$SESSION_WAIT w, V$LATCHNAME n
WHERE w.event = `latch free'
AND w.p2 = n.latch#
GROUP BY n.name;
In simple terms latches prevent two processes from simultaneously updating - and possibly corrupting - the same area of the SGA.. It is low-level serialization mechanism.
In-other way we can say, Latches are like locks for RAM memory structures to prevent concurrent access and ensure serial execution of kernel code. The LRU (least recently used) latches are used when seeking, adding, or removing a buffer from the buffer cache, an action that can only be done by one process at a time.Contention on an LRU latch usually means that there is a RAM data block that is in high demand. If a latch is not available a 'latch free miss' statistics is recorded.
If the latch is already in use, Oracle can assume that it will not be in use for long, so rather than go into a passive wait (e.g., relinquish the CPU and go to sleep) Oracle will retry the operation a number of times before giving up. This algorithm is called acquiring a spin lock and the number of “spins” before sleeping is controlled by the Oracle initialization parameter “_spin_count”.
Locks
Protect the logical contents of the database object (table, index) from other transactions.
Are held for the transaction duration.
Provide rollback capability for the associated transaction.
Latch
Protect the critical sections of the associated internal data structures from other threads.
Are held only until the operation completes and then are released.
Prevent concurrent access to a memory structure.
Latch occurrence:
Oracle sessions need to update or read from the SGA for almost all database operations. For instance:
When a session reads a block from disk, it must modify a free block in the buffer cache and adjust the buffer cache LRU (Least Recently Used) chain.
When a session reads a block from the SGA, it will modify the LRU chain.
When a new SQL statement is parsed, it will be added to the library cache within the SGA.
As modifications are made to blocks, entries are placed in the redo buffer.
The database writer periodically writes buffers from the cache to disk (and must update their status from “dirty” to “clean”).
The redo log writer writes entries from the redo buffer to the redo logs.
Latches prevent any of these operations from colliding and possibly corrupting the SGA.
Root causes of Latch contention:
The latches that most frequently affect performance are those protecting the buffer cache, areas of the shared pool and the redo buffer.
Library cache and shared pool latches: These latches protect the library cache in which shareable SQL is stored. In a well defined application there should be little or no contention for these latches, but in an application that uses literals instead of bind variables library cache contention is common, it will be good to use soft parsing over hard to avoid library cache contention.
Cache buffers chain latches: These latches are held when sessions read or write to buffers in the buffer cache. There are typically a very large number of these latches each of which protects only a handful of blocks. Contention on these latches is typically caused by concurrent access to a very “hot” block and the most common type of such a hot block is an index root or branch block (since any index based query must access the root block).
Redo copy/redo allocation latches: These latches protect the redo log buffer, which buffers entries made to the redo log. These latches were a significant problem in earlier versions of Oracle, but are rarely encountered today.
Run the following queries for Latch:
SELECT n.name, l.sleeps
FROM v$latch l, v$latchname n
WHERE n.latch#=l.latch# and l.sleeps > 0 order by l.sleeps;
SELECT n.name, SUM(w.p3) Sleeps
FROM V$SESSION_WAIT w, V$LATCHNAME n
WHERE w.event = `latch free'
AND w.p2 = n.latch#
GROUP BY n.name;
No comments:
Post a Comment