Log Writer Functions (LGWR)

The log writer process, LGWR, writes redo log buffer entries to the online redo log files on disk. It starts automatically the moment the instance starts, and an Oracle instance requires at least two online redo log groups to operate at all; each group can contain one or more member files, which is the mechanism behind multiplexed redo, but the minimum requirement is expressed in groups, not individual files.
At any given moment, one redo log group is the current, or active, group, and LGWR writes to it exclusively. When that group fills up, LGWR performs a log switch and begins writing to the next group in sequence. If that next group hasn't been archived yet and the database is running in ARCHIVELOG mode, LGWR has to wait until archiving catches up before it can safely reuse that group, exactly the "archiver stuck" scenario covered in the previous lesson.
A log switch itself breaks down into a few distinct steps, and it's worth being precise about which process does what. First, Oracle locates the next available log group to switch into. Second, LGWR finishes writing any remaining redo log buffer entries to the group it's currently on. Third, the actual switch happens: the current group is closed, and Oracle records the transition. This step triggers a checkpoint, and it's CKPT, not LGWR, that updates the control file and data file headers with the checkpoint information marking that transition, a division of labor worth keeping straight since it's easy to lump "the log switch" together as one undifferentiated event when it's really two processes cooperating. Fourth, LGWR opens the new current group and begins writing to it.
One sizing detail is worth flagging here specifically because it cuts against intuition: the size of your redo log files does not affect LGWR's own write performance. LGWR writes sequentially regardless of how big any individual log file is. What redo log size does affect is checkpoint frequency and DBW's workload, since undersized logs force more frequent checkpoints and more frequent log switches. If you're ever tempted to resize redo logs specifically to make LGWR faster, that's the wrong lever; LGWR's performance bottlenecks are almost always about disk I/O speed and contention, covered below, not log file size.
The LGWR process is diagrammed in the image below.

LGWR flushes everything copied into the redo log buffer since its last write whenever any of the following occurs:

1. A transaction commits
2. An online redo log switch occurs
3. The redo log buffer becomes one-third full, or accumulates 1 MB of buffered data, whichever happens first
4. A timeout occurs, roughly every three seconds since LGWR's last write
5. DBW needs to write a modified data block to disk, and the redo protecting that change hasn't been written yet

That last trigger is the write-ahead logging rule: Oracle will never let a changed data block reach disk before the redo describing that change does, which is exactly what makes crash recovery possible in the first place. It's worth noting explicitly that this list replaces "at every checkpoint" as a trigger, since a checkpoint by itself doesn't force LGWR to write; the log switch and DBW write-ahead triggers above cover the situations that actually matter.
LGWR writes to the redo log groups in a circular fashion. It writes to the current group until that group fills, at which point a log switch occurs and LGWR moves on to the next group. This continues around all the configured groups until the last one fills, at which point LGWR wraps back around and starts writing to the first group again, overwriting its previous contents, but only once that group has actually been archived, if ARCHIVELOG mode is enabled. In NOARCHIVELOG mode there's no such wait, which is exactly why NOARCHIVELOG mode can't support point-in-time recovery beyond what's still sitting in the current online logs.

Because every commit in your database waits on LGWR, even small amounts of LGWR latency get felt directly by users, which makes LGWR one of the more consequential processes to understand when diagnosing response time problems. Two wait events cover most of what actually goes wrong.
Log file sync is the wait a session experiences on COMMIT or ROLLBACK, from the moment it asks LGWR to flush the relevant redo to disk until that write actually completes. If you see a lot of these waits but each individual wait is short, the likely culprit is an application committing after every single row instead of batching its work, committing every 50 rows instead of every row, for instance, can meaningfully cut down how often sessions have to wait on LGWR at all. If the average wait time itself is high rather than just the count, the problem is usually on the I/O side: contention on the disks holding the redo logs, or an archiver competing with LGWR for the same disk. The practical remedies are straightforward: give the redo logs dedicated disks rather than sharing them with other database files, alternate redo log members across separate disks so the archiver reading one group doesn't slow down LGWR writing to another, and avoid RAID 5 for redo logs specifically, since RAID 5's write penalty works directly against the sequential, latency-sensitive writes LGWR needs to perform.
Log buffer space is a different problem: server processes waiting for free space in the redo log buffer itself, because the application is generating redo faster than LGWR can drain it to disk. The fix depends on where the actual bottleneck sits. If the redo log buffer is undersized for your workload, increasing it can help directly. If the buffer is already reasonably sized, the real problem is usually the same I/O contention on the redo log disks that causes log file sync waits, in which case resizing the buffer won't help and you need to address the underlying disk contention instead. It's worth checking both possibilities rather than assuming a bigger log buffer is automatically the answer.

LGWR's core job, making committed redo durable before anything else happens, hasn't changed across decades of Oracle releases, and it hasn't changed in Oracle AI Database 26ai either. What has changed is the architecture it operates within. As established earlier in this module, every 26ai database is a multitenant container database (CDB) holding one or more pluggable databases (PDBs); that's no longer optional the way it once was in older releases. All of the PDBs inside a given CDB share one SGA and one set of background processes, LGWR included. In practice this means LGWR is managing redo generation for every pluggable database in that container through a single redo stream, not running separately per PDB, which is exactly what you'd expect given that the instance itself, SGA and background processes together, is shared across the whole CDB rather than duplicated per PDB.
It's worth closing on why this lesson sits where it does in a backup and recovery course. Every other process this module has covered ultimately depends on LGWR having done its job first. ARCn can't archive redo that LGWR never wrote. CKPT's checkpoint record is only meaningful because LGWR guarantees the redo behind it is already durable. And every recovery scenario ahead in this course, instance recovery, media recovery, point-in-time recovery, Data Guard failover, is fundamentally about replaying or shipping the exact redo stream LGWR produced. If there's one process in this entire module whose correctness you're implicitly trusting every time you rely on Oracle's recovery guarantees, it's this one.
The next lesson describes the function of checkpoints.