Sessions waiting on free buffer waits cannot find a clean buffer in the cache to read a new block into. The buffer cache is full of dirty buffers that DBWn has not yet flushed, so foreground processes that need to read a new block have nowhere to put it.

This is a write-path bottleneck, not a read-path problem. The root cause is DBWn falling behind on writes: either the storage cannot absorb the write rate, or DBWn itself is CPU-starved or process-limited. The fix is on the write side. Throwing a bigger buffer cache at the problem does not help and frequently makes it worse.

free buffer waits is never normal in a healthy system. Even a small sustained count is a yellow flag. The underlying condition (DBWn I/O starvation) escalates quickly under load, so treat any non-trivial occurrence as an incident.

What this means

Every server process that needs to read a block into the cache first walks the LRU list looking for a free (clean, reusable) buffer. When it cannot find one because the cache is full of dirty buffers waiting for DBWn, the session posts DBWn to write and waits. If DBWn cannot catch up, foreground work stalls across the instance.

Distinguish this from two adjacent wait events that look similar but are not the same problem:

  • buffer busy waits: contention on a specific in-cache block that another session is reading or modifying. Targeted, not global.
  • read by other session: waiting for another session to finish an in-flight I/O on a block. Also targeted.

free buffer waits is a global resource problem. When it appears, the entire buffer cache write-back path is under pressure.

The single most important diagnostic step is to correlate it with db file parallel write, which is DBWn’s own I/O wait event. That correlation tells you where the bottleneck actually lives.

flowchart TD
    A[Session scans LRU for free buffer] --> B{Clean buffer found?}
    B -- yes --> C[Read block into cache]
    B -- no, dirty buffers dominate --> D[Wait on free buffer waits]
    D --> E[DBWn must write dirty buffers]
    E --> F{db file parallel write high?}
    F -- yes --> G[Storage-bound: slow data file writes]
    F -- no --> H[DBWn-bound: CPU starvation or too few DBWn]

Common causes

CauseWhat it looks likeFirst thing to check
Storage write latency on data filesdb file parallel write average wait elevated, free buffer waits grows in lockstepOS-level I/O latency on data file devices (iostat -x 1 5), AVGIOTIM in V$FILESTAT
DBWn CPU starvationdb file parallel write is low but DBWn processes show high CPU run queue or are starved by other consumersCPU utilization and run queue on the DBWn OS processes
Single DBWn process insufficientMultiple CPUs idle, but one DBWn process saturated; DB_WRITER_PROCESSES too low for write workloadDB_WRITER_PROCESSES parameter value and DBWn process count
Aggressive checkpoint from FAST_START_MTTR_TARGETfree buffer waits correlates with checkpoint bursts, log file switch (checkpoint incomplete) in alert logFAST_START_MTTR_TARGET value, checkpoint messages in alert log
Buffer cache too small for write working setDBWn keeps up with sustained writes, but too few clean buffers exist between write cyclesDirty buffer count vs clean buffer count, write rate relative to cache size

Quick checks

All of these are read-only.

# Confirm the symptom AND the key correlation in one shot.
# Sample twice, 60s apart, to confirm TOTAL_WAITS is still climbing.
sqlplus / as sysdba <<'EOF'
SELECT EVENT, TOTAL_WAITS, TIME_WAITED_MICRO,
       ROUND(TIME_WAITED_MICRO/NULLIF(TOTAL_WAITS,0)/1000, 2) AS avg_ms
FROM V$SYSTEM_EVENT
WHERE EVENT IN ('free buffer waits', 'db file parallel write');
EOF

# Which wait class dominates active sessions right now?
sqlplus / as sysdba <<'EOF'
SELECT NVL(WAIT_CLASS, 'On CPU') AS wait_class, COUNT(*) AS sessions
FROM V$SESSION
WHERE STATUS = 'ACTIVE' AND TYPE = 'USER'
  AND (WAIT_CLASS IS NULL OR WAIT_CLASS != 'Idle')
GROUP BY NVL(WAIT_CLASS, 'On CPU')
ORDER BY COUNT(*) DESC;
EOF

# DBWn and checkpoint configuration
sqlplus / as sysdba <<'EOF'
SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME IN ('db_writer_processes', 'fast_start_mttr_target',
               'db_block_size', 'sga_target', 'db_cache_size',
               'disk_asynch_io', 'filesystemio_options');
EOF

# OS-level: is the data file storage saturated?
iostat -x 1 5

# Per-datafile write latency, worst first
sqlplus / as sysdba <<'EOF'
SELECT f.FILE#, d.NAME, f.PHYWRTS, f.AVGIOTIM
FROM V$FILESTAT f JOIN V$DATAFILE d ON f.FILE# = d.FILE#
ORDER BY f.AVGIOTIM DESC;
EOF

# Checkpoint-related waits in the same window
sqlplus / as sysdba <<'EOF'
SELECT EVENT, TOTAL_WAITS, TIME_WAITED_MICRO
FROM V$SYSTEM_EVENT WHERE EVENT LIKE 'log file switch%';
EOF

# Rule out buffer busy waits (targeted block contention, not global)
sqlplus / as sysdba <<'EOF'
SELECT * FROM V$WAITSTAT ORDER BY COUNT DESC;
EOF

How to diagnose it

  1. Confirm free buffer waits is actually accumulating, not a long-stale counter. Sample V$SYSTEM_EVENT twice, 60 seconds apart, and confirm TOTAL_WAITS is increasing.

  2. Pull db file parallel write in the same window. This is the most important correlative signal:

    • If db file parallel write average wait is elevated, the problem is on the storage side. Move to OS-level I/O latency checks and per-datafile write latency.
    • If db file parallel write is low, the problem is DBWn itself: CPU starvation, too few DBWn processes, or a scheduling issue.

  3. Check the alert log for Checkpoint not complete and log file switch (checkpoint incomplete) entries in the same time window. If they cluster with the free buffer waits increase, the checkpoint path is the trigger.

  4. Verify DB_WRITER_PROCESSES. On a busy write workload with multiple CPUs available, too few DBWn processes can be the bottleneck. The default targets roughly one DBWn per eight CPUs.

  5. Check FAST_START_MTTR_TARGET. A very low target forces DBWn to write aggressively, which can backfire under load by competing with foreground I/O. A high target lets dirty buffers accumulate before checkpointing kicks in.

  6. Confirm you are not confusing this with buffer busy waits or read by other session. Query V$WAITSTAT to see whether contention is on specific block classes, which points to buffer busy waits, not free buffer waits.

  7. Look for correlated workload changes: a new batch job, a bulk DML window, or a stats gather that changed a plan toward more writes. free buffer waits rarely appears in a steady-state system without a workload shift.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
free buffer waits in V$SYSTEM_EVENTThe primary symptom. Never normal in a healthy system.Sustained non-trivial count; above 0.1% of total waits
db file parallel write average waitDBWn’s own I/O wait. Determines whether the bottleneck is storage or DBWn itself.Average wait trending up in lockstep with free buffer waits
log file switch (checkpoint incomplete) waitsCheckpoints are not keeping up, which pressures DBWn.Sustained occurrence alongside free buffer waits
Per-datafile AVGIOTIM from V$FILESTATIdentifies hotspot datafiles with slow write latency.AVGIOTIM above 10ms (SSD) or 20ms (SAN) on write-heavy files
OS write latency on data file devices (iostat await)Independent confirmation of storage-side write latency.await climbing while %util climbs on data file devices
DBWn process CPU utilizationReveals whether DBWn is CPU-starved despite idle I/O.DBWn at 100% on one CPU while other CPUs idle
Redo generation rate and physical write rateTracks the write workload DBWn must keep up with.Sudden increase correlated with free buffer waits onset
Checkpoint not complete in alert logDirect evidence that checkpoint pressure is the trigger.More than a few per hour on a busy system

Fixes

If DBWn is storage-bound (db file parallel write is high)

The data file storage cannot absorb DBWn’s write rate. Increasing the buffer cache will not help and will accumulate more dirty buffers before the same stall recurs.

  • Identify hotspot datafiles. Use V$FILESTAT.AVGIOTIM and OS-level iostat -x to find the worst offenders. Move them to faster or less-contended storage.
  • Separate redo logs from data files. Redo and data file I/O contend badly when sharing physical storage. This is a common hidden cause of write-path stalls.
  • Review filesystem mount options. data=journal on ext4 or improperly tuned ZFS adds write latency. Oracle data files perform best on data=writeback or raw ASM.
  • Verify async I/O is enabled and functional. Check DISK_ASYNCH_IO (should be TRUE) and FILESYSTEMIO_OPTIONS (SETALL or ASYNCH for filesystem-backed files). Without async I/O, DBWn serializes on every write, which shows up directly as elevated db file parallel write time.
  • Short-term pressure relief. Defer non-critical batch loads, or adjust FAST_START_MTTR_TARGET upward to spread checkpoint writes across a longer window.

If DBWn is CPU-bound or process-limited (db file parallel write is low)

DBWn has I/O headroom but cannot schedule or submit writes fast enough. This points to CPU starvation, too few DBWn processes, or a kernel-side scheduling issue.

  • Increase DB_WRITER_PROCESSES. On write-heavy systems with many CPU cores, additional DBWn processes parallelize the write path. The default targets roughly one DBWn per eight CPUs. This parameter requires an instance restart to change.
  • Check for CPU contention from other consumers. Parallel query slaves, RMAN, and stats gathering can starve DBWn of CPU cycles. Moving those workloads off-peak or isolating DBWn’s CPU budget can relieve contention.
  • On VMware, check CPU ready time. vCPU scheduling latency can make DBWn appear CPU-bound when the real constraint is hypervisor scheduling. Check esxtop or vCenter performance stats.

If checkpoint pressure is the trigger

free buffer waits that cluster with Checkpoint not complete or log file switch (checkpoint incomplete) indicate the checkpoint path is forcing DBWn into bursty write storms.

  • Increase online redo log size and add redo log groups. This gives DBWn more time to flush between log switches and reduces checkpoint bursts. It buys time but does not fix a slow storage subsystem.
  • Review FAST_START_MTTR_TARGET. A very low target forces aggressive DBWn writes that compete with foreground I/O. A high target lets dirty buffers accumulate. Tune toward a value consistent with your recovery SLA, not the absolute minimum.
  • Check redo log switch frequency. Switches more than once per minute almost guarantee checkpoint pressure on a busy system. Aim for switches no more than every 10 to 15 minutes at peak redo generation.

What does not help

  • Increasing the buffer cache. If DBWn cannot write fast enough, a larger cache just means more dirty buffers pile up before the same stall recurs. Confirm the write path is healthy first.
  • Forcing a checkpoint. ALTER SYSTEM CHECKPOINT creates exactly the write burst you are trying to avoid. ALTER SYSTEM FLUSH BUFFER_CACHE exists but is undocumented, unsupported for tuning, and forces every buffer dirty or clean through the same path.
  • Adding SGA memory without verifying hugepages. Without hugepages, larger SGAs add page table overhead that can itself pressure CPU and memory.

Prevention

  • Monitor free buffer waits and db file parallel write as a paired signal. Alert on any non-trivial free buffer waits count, and use db file parallel write average wait as the immediate triage input.
  • Track per-datafile write latency over time. Slow drift on a specific datafile often precedes an acute incident.
  • Size redo logs conservatively. Keep switch frequency under one every 10 to 15 minutes at peak redo generation. Frequent switches create checkpoint pressure that propagates to DBWn.
  • Verify DB_WRITER_PROCESSES after hardware changes. Ensure the value is appropriate for the host CPU count and write workload after any migration or resize.
  • Keep redo logs on dedicated storage. The redo and data file I/O paths have different latency profiles and contend badly when shared.
  • Include a write-path health check in your runbook. A small INSERT plus COMMIT into a health check table exercises DBWn and LGWR end to end. A read-only check will not surface write-path stalls.

How Netdata helps

Netdata surfaces the signals that disambiguate a free buffer waits incident at per-second resolution:

  • free buffer waits and db file parallel write collected together, so you can see at a glance whether DBWn is storage-bound or CPU-bound without running two queries and mentally joining them.
  • OS-level disk latency (iostat-equivalent metrics) on the same dashboard as Oracle wait events, so storage-side and database-side signals sit next to each other during triage.
  • Per-process CPU utilization (including the DBWn processes) to make a CPU-starved DBWn visible without manual ps and top cross-referencing.
  • ML anomaly detection that flags the onset of free buffer waits even when the absolute count is still small, because this signal is never normal in a healthy system.

Netdata’s Oracle Database monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.