Oracle DBA · Lesson 9
Why Redo Must Reach Disk First
Lesson 8B drew the line: dirty buffers are not the commit record. This lesson follows the durability path — why redo must reach the online redo log on disk before commit can return, and why write-ahead logging protects crash recovery.
Watch on YouTube
Oracle DBA Lesson 9 — Why Redo Must Reach Disk First
AI Ops Pro
From Lesson 8B: dirty ≠ durable
A dirty buffer means the cache image changed and DBWR has not yet written the datafile. COMMIT does not wait for that write. Durability rides on redo: LGWR must write the transaction’s redo — including the commit record — to the online redo log on disk before commit returns.
What redo is
Redo is a description of how to replay a change. It is not the old row image — that belongs to undo. Server processes copy redo records into the redo log buffer in the SGA (a small circular buffer). LGWR writes that buffer to the online redo log files on disk.
- Redo = replay instructions for recovery.
- Log buffer = short-lived waiting room in the SGA.
- Online redo log = durable sequential files LGWR fills.
Commit waits on LGWR
When you issue COMMIT, the session waits until LGWR has flushed that transaction’s redo (and anything still ahead of it in the log buffer) to the online redo log. Only then does commit return success.
Mental model: change → redo log buffer → LGWR → online redo log on disk → commit returns. Datafile writes remain DBWR’s job on a different schedule.
Write-ahead logging
Oracle’s write-ahead rule: never write a changed data block to a datafile until the redo for that change is already on disk. Crash recovery depends on this. If the instance fails after commit returned, recovery finds the commit in redo and can re-apply the work — even if dirty buffers never reached the datafiles.
That is why redo must reach disk first: the online redo log is the durability path for commit, and write-ahead keeps the recovery story consistent.
Inspect online redo groups
Start with the online redo groups themselves — size, member count, and status (CURRENT, ACTIVE, INACTIVE).
SELECT group#, members, bytes/1024/1024 AS mb, status
FROM v$log
ORDER BY group#;Teaching peek — read what your lab returns. Status and sizes vary by configuration.
When commit feels stuck, redo I/O waits are often the first place to look — not buffer-cache hit ratio.
SELECT event, total_waits, time_waited
FROM v$system_event
WHERE event LIKE 'log file%'
ORDER BY time_waited DESC;Counts accumulate since startup. Use them as a concept check for log-file wait classes, not as a fixed “healthy” chart.
Gotchas
- Commit durability is redo on disk (LGWR), not a dirty-buffer datafile flush (DBWR).
- Write-ahead: redo for a change must be on disk before that changed block may hit the datafile.
- A slow or full online redo path shows up as commit waits — even when the buffer cache looks fine.
- Do not “tune” by making the log buffer huge; fix online log I/O and log sizing first.
Quick quiz
Choose one answer, then submit. You’ll see the correct answer and a short why.
No comments:
Post a Comment