Explain redo log buffer architecture.
In the high-stakes world of database transactions, the Redo Log Buffer is the "fast-acting memory" that ensures your data is never lost, even if the power cuts out a split second after you hit save.
If the Data Files are the final permanent records, the Redo Log Buffer is the high-speed stenographer taking notes on every change as it happens.
The Redo Log Buffer is a circular memory structure located within the SGA (System Global Area). Its sole purpose is to hold Redo Entries—small, compressed records of every change made to the database (INSERTs, UPDATEs, DELETEs, etc.).
Writing directly to the physical Redo Log Files on disk for every tiny change would be incredibly slow. The buffer acts as a "waiting room," gathering changes in memory and then flushing them to disk in efficient batches.
The Redo Log Buffer operates on a simple but strict set of rules to ensure maximum performance and zero data loss.
Think of the buffer as a wedding ring. Oracle starts writing at the beginning and continues around the circle. Once it reaches the end, it wraps back around to the start (provided that the earlier data has already been safely written to the disk by the Log Writer).
Oracle follows a Write-Ahead Logging (WAL) protocol. This means:
The record of the change (the Redo) must be written to the disk before the actual data block is updated in the data file.
This ensures that if the system crashes, Oracle has a "recipe" to recreate the change during recovery.
The LGWR (Log Writer) process is the "bouncer" that moves data from this buffer to the physical disk. It is triggered by four specific events:
At Commit: The moment a user types COMMIT, LGWR flushes the buffer to ensure the transaction is permanent.
Every 3 Seconds: Even if no one is committing, LGWR clears the buffer to keep the "lag" to a minimum.
One-Third Full: When the buffer reaches $1/3$ capacity, it triggers a flush to make room for new entries.
Before DBWn Writes: If the Database Writer (DBWn) needs to write a changed data block to disk, it first tells LGWR to flush the corresponding redo record.
Each entry in the buffer contains:
The Change: What was modified? (e.g., "Change Salary from 5000 to 6000").
The Location: Which Data Block and Row was affected?
The SCN: The System Change Number (the precise "timestamp" of the change).
If your Redo Log Buffer is too small, or your disks are too slow, you might see the wait event: log buffer space.
This happens when your server processes are generating changes so fast that the buffer fills up before LGWR can flush it to disk. When this happens, the entire database pauses until space is cleared.
| Feature | Redo Log Buffer (Memory) | Redo Log Files (Disk) |
| Location | SGA (RAM) | Physical Storage (SSD/HDD) |
| Volatile? | Yes (Lost on power fail) | No (Persistent) |
| Access Speed | Nanoseconds | Milliseconds |
| Managed By | Server Processes | LGWR |
In modern Oracle versions (12c, 19c, 21c), the parameter LOG_BUFFER is usually automatically sized. However, if you have a "Write-Heavy" application (like a massive batch load), monitoring the V$SESSION_WAIT view for log file sync or log buffer space is crucial for tuning.