Inside Oracle latches
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.
Latches are in-memory locks that ensure one-at-a-time, serial access for when an Oracle process modifies a RAM structure.
For example, the data buffer latches (sometimes called LRU latches) ensure that Oracle processes are “serialized”, such that only one process may alter the data buffer address chain. This twiddling of RAM addresses happens very fast (RAM speed is expressed in nanoseconds), yet busy Oracle databases may experience waits on these events.
Note: Protecting Oracle’s competitive advantage
All database vendors have a vested interest in protecting their competitive advantage, especially within the software kernel, and much of Oracle’s competitive advantage lies in their superb code. Thus, it’s no surprise that Oracle does not publish the internal machinations of their kernel code and it is against the licensing rules to decompile the Oracle code to reveal these mechanisms, so we must speculate as to how Oracle manages his internal locks and latches. Remember, Oracle is not being uncooperative by not releasing these details; it’s done to protect their competitive advantage.
In most databases, an address list is used to sequence the data blocks within the RAM regions (db_cache_size, db_keep_cache_size, db_32k_cache_size, etc.) because it is faster to sequence by address than to shirt the actual data blocks. To prevent corruption within Oracle’s internal the RAM regions, a database must ensure that only one process at a time manipulates the “address list” (a list of pointers to the RAM addresses of the data blocks). In a database like Oracle, we know that the list of data blocks are shifted during many operations, but bat far the most common is the “consistent get”, a logical I/O where Oracle requests a data block and finds it within the buffer.
In order to ensure that frequently-referenced data blocks remain in the buffers, Oracle probably uses this sequence of events for initial reads (physical reads) and logical buffer reads (consistent gets):
When Oracle does a disk read, the database must buffer-up the data block and adjust the RAM pointers:
1 - Oracle marks the LRU address as eligible for over-writing and Oracle perform a disk read and load the data block into this RAM slot, the buffer marked as LRU (least recently used). Note: This causes an “age out”, as Oracle overwrites the contents of the old block.
2 – Once loaded, the DBMS notes the RAM heap address and does a midpoint insertion, shifting the data block address list to place the new block address in the middle of the list. During this operation the database needs to ensure that the process managing the read has exclusive control of the buffer address list:
Logical buffer reads:
When a request is made for a data block that is already in the data buffer, it is “promoted” to the head of the data buffer address list, thereby helping to ensure caching of frequently-referenced blocks:
1 – Oracle issues an “LRU latch” to ensure that the process has exclusive control over the address list.
2 – The managing process then directs the DBMS to shift the requested block address to the MRU (Most Recently Used) end of the list.
3 – The latch is released and the process de-references the pointer (going to that located in the heap) and the row is accessed by the calling program.
Oracle records a “latch miss” when a process must wait for a latch to become available, and we also see “buffer busy waits” when a process must wait for a freelist. You can reduce buffer busy waits by adding additional FREELISTS or FREELIST GROUPS. For low-update databases you can also implement bitmap freelists (ASSM, Automatic Segment Storage Management) with the create tablespace clause “segment space management auto”.
Click below to continue reading about Oracle latch usage within Oracle:
Need a Health Check?
Oracle is the worlds most complex and robust database and there are hundreds of sub-optimal setting that can cripple your database performance.
BC has a great Oracle health check where we identify all database bottlenecks to ensure that your mission-critical system is running at optimal speeds.
Just call 919-783-4133 to schedule your health check.
Need Oracle Training?
The very best Oracle training comes from Burleson Consulting, where you get an on-site visit by an experienced Oracle expert and author. Whether it's one-on-one mentoring or getting a customized on-site Oracle training class, there is no substitute for BC Oracle training. Just call me at 919-783-4133 for details, and check-out our on-site Oracle training catalog: