What is latch contention?
In the Oracle Database, if a Lock is like a reserved parking spot for a car (transactional data), a Latch is like the turnstile at a stadium gate. It’s a low-level, internal mechanism designed to coordinate access to shared memory structures in the System Global Area (SGA).
Latch Contention occurs when too many processes try to squeeze through that "turnstile" at the exact same time. It’s the digital equivalent of a traffic jam inside the database’s brain.
It’s common to confuse the two, but they serve very different purposes:
Locks: Protect data (rows/tables). They ensure that if you are updating a bank balance, no one else can change it until you’re done. They are held for the duration of a transaction.
Latches: Protect memory structures (linked lists/buffers). They ensure that while the database is searching for that bank balance in RAM, the map it’s using doesn't change mid-search. They are held for microseconds.
When a process needs a latch that is currently held by someone else, it doesn't just wait patiently in a queue. It uses a "willing-to-wait" strategy:
The Spin: The process "spins" on the CPU, checking the latch over and over (thousands of times) to see if it has been released. This consumes CPU but is faster than going to sleep if the latch is about to be freed.
The Sleep: If it still hasn't grabbed the latch after spinning, it finally goes to sleep. This is recorded as a latch free wait event.
High Latch Contention = High CPU Usage + High Wait Times.
This is the most famous latch. It protects the linked lists used to find data blocks in the buffer cache.
Cause: Many sessions are trying to access the exact same data block (a "hot block"), like the root of a busy index.
Symptom: High latch: cache buffers chains waits.
This latch protects the area where SQL statements are stored.
Cause: Your application is not using Bind Variables. Every time a user runs SELECT * FROM users WHERE id = 123 and another runs ...id = 456, Oracle treats them as new queries and has to lock the Library Cache to "parse" them.
Symptom: High latch: library cache waits.
This protects the buffer where transaction logs are written before they hit the disk.
Cause: A very high volume of small, frequent commits or a massive amount of DML.
Symptom: High latch: redo allocation waits.
You can spot contention by looking at the "Top Wait Events" in an AWR or ASH report. You can also query the database directly:
SELECT name, gets, misses, sleeps
FROM v$latch
WHERE misses > 0
ORDER BY sleeps DESC;
Gets: Total requests.
Misses: How many times the process had to "spin."
Sleeps: How many times the process actually had to go to sleep.
Fixing contention usually requires changing how the application talks to the database, rather than just "adding more hardware."
Use Bind Variables: This is the #1 fix for Library Cache contention.
Optimize SQL: Reduce the number of "Logical Reads" (memory hits). If you touch fewer blocks, you need fewer latches.
Increase Latch Count: For some latches, like the Redo Allocation latch, you can increase the number of "child latches" via initialization parameters (though this is less common in modern Oracle versions like 19c/23c).
Spreading Data: If a single index block is "hot," consider using a Hash Partitioned Index to spread the load across multiple blocks.
Latch contention is a signal that your database is working too hard on "housekeeping" rather than actually processing data. It’s the ultimate scalability killer. In 2026, with high-core-count CPUs, latch contention can often mask itself as high CPU usage, making it even more critical to monitor your wait events closely.