There are four conditions that cause LGWR to perform. a redo write.

1.  When LGWR is idle, it sleeps on an rdbms ipc message wait with a timeout of 3 seconds (as does DBWn). If this sleep times out and LGWR finds that there is some redo available to write, a background write is performed spontaneously.

LGWR以rdbms ipc message事件开始休眠（rdbms ipc message为空闲事件，该事件超时设置为3秒，因此LGWR每3秒被触发） 。如果3秒超时时间到并且LGWR发现有Redo需要写，LGWR会被触发

rdbms ipc message  ----The background processes (LGWR, DBWR, LMS0) use this event to indicate that they are idle and are waiting for the foreground processes to send them an IPC message to do some work.

这个事件表示后台进程(LGWR,DBWR,LMS0)空闲，并等待前台进程发送IPC message调度后台进程

2. Whenever a process allocates space in the log buffer, the number of used log buffer blocks is calculated. If the number of used blocks is greater than or equal to the number of blocks specified by the _log_io_size parameter, and if LGWR is not already active, then LGWR is posted to perform. a background write. The default value for _log_io_size is ¹/3 of the log buffer expressed in log blocks, with an upper bound equivalent to 1 Mb from release 8.0. As with many other hidden parameters, unless set explicitly, the _log_io_size parameter reports as zero in X$KSPPSV.

当进程在log buffer中分配了空间，已经使用的log buffer块将被计算，如果使用的log buffer块大于等于_log_io_size参数设置,并且LGWR没有处于活动状态，LGWR会被触发

从8.0版本以来_log_io_size参数默认值为¹/3的log buffer块,上限为1M

从X$KSPPSV中查到的参数值都为0,为缺省值

select a.ksppinm Parameter, a.ksppdesc Description, b.ksppstvl "Session Value", c.ksppstvl "Instance Value"
from x$ksppi a, x$ksppcv b, x$ksppsv c
where a.indx = b.indx and a.indx = c.indx
and a.ksppinm like '\_%' escape '\'
and a.ksppinm like '%_log_io_size%'
order by 1

3.  When a transaction commits, it generates a commit marker in the redo stream. However, the transaction is not recoverable until the log block containing that commit marker has been flushed to disk. So, before the process finishing the transaction can return a response to the user, it must wait for LGWR to flush that log block to disk. The process therefore posts LGWR and then sleeps on a log file sync wait with a timeout of 1 second. For completeness, the_wait_for_sync parameter can be set to FALSE to avoid waiting for redo to be synced, but doing so voids any guarantee of recoverability for committed transactions upon instance failure.

当transaction commit，会在重做流中产生commit marker(提交标记符).直到包含commit marker的日志块写入到硬盘，transaction才是可恢复的。所以在transaction返回信息给用户之前，必须等待LGWR将日志块写入到硬盘，因此进程会触发LGWR，并以log file sync事件休眠，超时为1秒

_wait_for_sync参数可以被设置为false，避免transaction同步等待redo。但如果这样做就无法保证事务在实例崩溃中可以恢复

Note that commits within recursive calls (such as procedural code execute calls) do not need to sync their redo until a response is about to be returned to the user. Therefore recursive calls just sync the commit RBA of their most recent COMMIT upon return to the user call. They do not sync each commit.

这段目前还是不明白

An SGA variable (kcrfshsb, according to bug 182447) is used to communicate the log block number up to which the redo thread needs to be synced. If several commits occur in distinct transactions before LGWR wakes up, this variable records the highest log block number that needs to be synced, and the commit markers are all flushed to disk in a single redo write. This is sometimes called a group commit.

一个SGA的变量用以记录Redo线程需要同步的log block number.如果在LGWR唤醒钱有多个commit发生，这个参数将记录最大的需要同步的log block number，此时所有的提交标记符将由一个redo写入硬盘。这被称为组提交

4. When DBWn needs to write one or more blocks for which the high RBA is beyond LGWR's on-disk RBA, from Oracle 8i, it places those blocks into its deferred write queue and posts LGWR to sync the highest high RBA, but it does not wait. Instead DBWn continues to process other writes that do not need to be deferred. Prior to release 8i, DBWn used to sleep on a log file sync wait in this case.

DBWn将要写的数据块的high RBA超过LGWR的On-disk RBA,DBWn将触发LGWR写。

从8i开始，DBWn将这些数据块放到延迟队列，并通知LGWR同步high RBA，但DBWn并不等待，会继续执行无需等待的数据写出（有些数据写出需要等待LGWR，等待log file sync事件，但有些数据写出无需等待，需要等待的数据块放到延迟队列中）

RBA ---Redo Block Address

the high RBA is the address of the redo for the most recent change to have been applied to the block.

---块上最新更改操作的redo地址 

The on-disk RBA is the point up to which LGWR has flushed the redo thread to the online log files

---

 目前水平有限，会根据最新的理解更新

已经做了进一步更新