Oracle problems

log buffer space: The Log Writer Behind, and the Fix

3 November 2026

log buffer space is a session that has redo to write and no room in the log buffer to put it. Oracle's reference describes the event as "Waiting for space in the log buffer because the session is writing data into the log buffer faster than LGWR can write it out", and gives its advice in the same entry: "Consider making the log buffer bigger if it is small, or moving the log files to faster disks such as striped disks." The wait is "Usually 1 second, but 5 seconds if it is waiting for a Switch Logfile to complete". It appears during the jobs that generate redo in bulk, a load, an index rebuild, a full-table update, and the fix is almost always on the write side rather than in the buffer: redo disks that take milliseconds per write, or redo logs so small that the writer spends its time switching.

What the wait means

The log buffer is a circular area of the SGA that every session copies its redo into and that the log writer empties to the online redo log. Oracle's Concepts guide lists the moments the writer writes everything copied in since its last write: "A user commits a transaction", "An online redo log switch occurs", "Three seconds have passed since LGWR last wrote", "The redo log buffer is one-third full or contains 1 MB of buffered data", and "DBW must write modified buffers to disk", because a dirty block cannot reach the datafile before its redo reaches the log. A session that generates redo faster than those writes drain the buffer finds no space and waits on this event; a commit is not needed, a single large update can do it alone. The buffer's size is LOG_BUFFER, which the reference defaults to "2 MB to 32 MB, depending on the SGA size and CPU count", because "One redo strand is allocated for every 16 CPUs and has a default size of 2 MB. Oracle allocates a minimum of 2 redo strands per instance." It cannot be changed without a restart. The event is not log file sync: that one is a committed session waiting for its redo to reach disk, this one is a session waiting to put redo into the buffer at all.

Who waits, and on which event

SELECT s.event, s.sql_id, COUNT(*) AS sessions,
       SUM(s.seconds_in_wait) AS seconds
FROM   v$session s
WHERE  s.event IN ('log buffer space', 'log file switch completion',
                   'log file switch (checkpoint incomplete)',
                   'log file switch (archiving needed)',
                   'log file sync')
GROUP  BY s.event, s.sql_id
ORDER  BY sessions DESC;

Five events share the log writer and tell different stories. log buffer space alone is the writer behind the redo rate. With the switch events next to it, the logs are too small or the archiver and the database writer are behind the switch, which is the log file switch family. With log file sync next to it, the redo disk is slow and every commit pays too.

The redo statistics, twice

SELECT name, value
FROM   v$sysstat
WHERE  name IN ('redo size', 'redo entries', 'redo writes',
                'redo write time', 'redo buffer allocation retries',
                'redo log space requests', 'redo log space wait time')
ORDER  BY name;

Take the readings a minute apart and work with the difference. redo size over the interval is the redo rate in bytes a second, the number that must fit through the redo disks. redo buffer allocation retries is, in the reference's words, the "Total number of retries necessary to allocate space in the redo buffer. Retries are needed either because the redo writer has fallen behind or because an event such as a log switch is occurring", and retries against redo entries is the share of redo that could not be placed at the first try. redo log space requests is the "Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch": the switch side of the problem. redo write time divided by redo writes is the writer's average write, in the reference's unit of 10s of milliseconds.

The writer's own wait, and the switches

SELECT event, total_waits,
       ROUND(time_waited_micro / 1e6)                 AS seconds,
       ROUND(time_waited_micro/NULLIF(total_waits,0)/1000,1) AS avg_ms
FROM   v$system_event
WHERE  event IN ('log file parallel write', 'log file sync',
                 'log buffer space')
ORDER  BY seconds DESC;

SELECT TO_CHAR(first_time, 'DD HH24') AS hour, COUNT(*) AS switches
FROM   v$log_history
WHERE  first_time > SYSDATE - 1
GROUP  BY TO_CHAR(first_time, 'DD HH24')
ORDER  BY hour;

SELECT group#, thread#, ROUND(bytes / 1048576) AS mb, members, status
FROM   v$log
ORDER  BY thread#, group#;

log file parallel write is the log writer's write to the redo log files. Under a millisecond is a good redo disk; several milliseconds, while sessions wait for buffer space, is the limit of the storage, and no buffer size changes it. Switches at ten or twenty an hour during the batch, on logs of a few hundred megabytes, are the five-second waits: every switch stops allocation until the new log is open.

Who generates the redo

SELECT s.sid, s.username, s.program, s.sql_id,
       ROUND(st.value / 1048576) AS redo_mb
FROM   v$sesstat st
JOIN   v$statname n ON n.statistic# = st.statistic#
JOIN   v$session  s ON s.sid = st.sid
WHERE  n.name = 'redo size'
AND    st.value > 0
ORDER  BY st.value DESC
FETCH FIRST 10 ROWS ONLY;

Redo per session since logon ranks the producers. One session with gigabytes while the others have megabytes is the batch, and its sql_id is the statement to change: a load that could run direct path, an index rebuild that could run after the load instead of during it, an update of every row where a new table would have been cheaper.

The fix, in order

1. Measure the redo disk first. log file parallel write at several milliseconds is the storage: redo logs on the same volume as the datafiles or a backup in progress, a replicated volume, a write cache that is off. Redo wants its own fast path, and on it the event usually disappears without anything else.
2. Generate less redo. A direct-path insert writes its blocks straight to the datafiles, and with NOLOGGING on the segment it generates almost no redo, which is safe only where the standby and the backup plan allow it. Build the indexes after the load instead of maintaining them row by row. Keep intermediate results in global temporary tables, whose rows are not logged. The redo rate falls by a factor, and the writer is no longer behind.
3. Redo logs large enough. Logs that switch every minute under the batch make the writer wait at every switch and the sessions wait five seconds at a time. Size the groups so that switches at the peak are minutes apart, and keep enough groups that the switch never waits for the archiver or the checkpoint.
4. A bigger log buffer, only then. When retries are high and the writer's average write is fast, the buffer absorbs bursts: raise LOG_BUFFER and restart. A bigger buffer does not help a slow disk; it only hides a burst for a moment longer.
5. Move the batch. If the redo rate is a nightly load, run it when the redo disk is not shared with the backup, or split it into chunks so that the writer keeps up between them. The switch count per hour above says when the storage was busy.

See it coming

Radar Engine, the detection layer of Scops, reads the waiting sessions every 5 seconds, watches commit latency as its own signal and keeps a standing watch on the log switch events, so a batch that outruns the log writer is a finding with the session that generates the redo and the writer's latency, within a minute of the first wait:

The finding names the database, the event, the statement behind the waiting sessions and the commit latency of the same minute, so the first question, disk or redo rate, is answered in the mail. The Activity chart draws the Configuration and Commit classes by statement on any edition, without the Diagnostics Pack.

Questions

What does log buffer space mean?
A session has redo to copy into the log buffer and the buffer is full because the log writer has not yet written the earlier entries to the redo log. Oracle's reference says the session is writing data into the log buffer faster than LGWR can write it out. The usual causes are slow redo disks, small redo logs that switch too often, and a batch that generates redo faster than any disk can take it.

Should I increase LOG_BUFFER?
Only after the redo disk and the log size. The default is already 2 MB to 32 MB depending on CPUs and SGA, and a bigger buffer only absorbs a burst; it cannot make the writer faster. Raise it, with a restart, when redo buffer allocation retries are high and log file parallel write is fast.

What is the difference between log buffer space and log file sync?
Log file sync is a session that has committed and waits for its redo to reach disk. Log buffer space is a session that cannot even place its redo in the buffer, commit or not. Both point at the log writer, and a slow redo disk raises both at once.

Why does the wait last 5 seconds sometimes?
Oracle's reference gives the wait time as usually 1 second, but 5 seconds if the session is waiting for a log switch to complete. Many 5-second waits mean the switches are the problem: the redo logs are too small for the redo rate, or the switch itself waits for the archiver or the checkpoint.

How do I find which session generates the redo?
V$SESSTAT with the statistic redo size, joined to V$SESSION, ranks the sessions by redo since logon; the top one in a batch window is the job, and its sql_id is the statement to change. Scops shows the same thing on the Activity chart without any query.

Related problems

• Log file sync waits
• log file switch (checkpoint incomplete)
• Archiver stuck: ORA-16014
• free buffer waits
• NOLOGGING with a standby
• Oracle wait events, by class
• All Oracle problems

Sources

• Oracle: Descriptions of wait events, LOG_BUFFER, Statistics descriptions, Process architecture: log writer process, V$LOG_HISTORY
• Scops docs: Detector reference