Oracle Buffer Cache Contention Causing Latency Spikes Under Concurrent Requests

Short answer

Latency spikes that appear only under concurrency, with clean single-threaded runs, are the classic signature of hot-block contention in the buffer cache: many sessions probing the same block serialize on cache buffers chains (CBC) latches, surfacing as buffer busy waits, latch: cache buffers chains, or read by other session. One correction up front: SQL_BUFFER_GET is not a standard Oracle wait-event name in 12c or 19c. If that string came from a monitoring tool, map it to the underlying events above before drawing conclusions — the fix depends on which event actually dominates.

Likely explanation vs. confirmed facts

Confirmed mechanism: the buffer cache is partitioned into hash chains protected by CBC latches. When concurrent sessions repeatedly visit the same block — typically a right-hand index leaf fed by a sequence or identity column, a hot table block, or a segment header — they serialize on the latch and the block. This scales poorly with concurrency even when CPU and I/O look healthy, which matches your single-threaded-clean / concurrent-slow pattern.

Likely explanation (needs verification in your environment): the hot object is most often the leading-edge leaf block of an index on a monotonically increasing key. Adaptive cursor sharing and parallel query are less likely primary causes; they more often change which blocks are visited than create block-level serialization. Buffer-pool strategy (KEEP/RECYCLE/DEFAULT) is also a secondary factor — pool placement changes which blocks stay cached, not latch serialization on a hot block.

Diagnostic steps for this case

1. During a spike, capture ASH and group by event and block address:

   SELECT event, p1 file#, p2 block#, COUNT(*) samples
   FROM v$active_session_history
   WHERE sample_time > SYSDATE - 1/24
   GROUP BY event, p1, p2
   ORDER BY samples DESC;

2. Map the hot file/block to an object:

   SELECT owner, segment_name, segment_type
   FROM dba_extents
   WHERE file_id = :file
   AND :block BETWEEN block_id AND block_id + blocks - 1;

3. Confirm with segment statistics:

   SELECT object_name, statistic_name, value
   FROM v$segment_statistics
   WHERE statistic_name IN ('buffer busy waits','row lock waits')
   ORDER BY value DESC;

4. Correlate with an AWR report covering the spike: top waits should be CBC latch / buffer busy events, not db file sequential read or CPU.

Does a dedicated pool help?

Usually no, not for true hot-block contention. Pinning a hot table in a KEEP pool guarantees the block is in memory, but the sessions still serialize on the same latch and block — contention is about concurrency on one block, not cache residency. Pool changes help only if your ASH data shows the waits are actually physical-read amplification (read by other session from an undersized cache). Check V$DB_CACHE_ADVICE before resizing.

Fixes that match the hot object

• Right-hand index leaf (sequence/identity keys): reverse-key index, hash-partitioned global index, or scalable sequences (18c+). Caveat: reverse-key indexes destroy range-scan capability on that index — verify query patterns first.
• Hot table blocks: hash partitioning or hash clustering to spread rows, or application-level batching of the hot row set.
• Excessive logical I/O from a bad plan: tune the SQL first; restructuring segments won't help if a plan change multiplied block visits.

Do not raise _spin_count or other underscore latch parameters without Oracle Support guidance — it masks symptoms and burns CPU.

Version notes

Wait-event names and latch architecture differ between releases; validate event names against your exact 12c/19c version. The diagnostic flow above works on both.

One missing detail

Which event actually tops ASH during a spike — latch: cache buffers chains vs. buffer busy waits vs. read by other session — changes the recommendation, so capture that before changing any pool or index structure.