Four situations of Redo write triggering

Redo write is triggered in four cases. 1. When LGWR is idle, it checks every three seconds to see if any data is written to redelog from redo buffer. If yes, A background process automatically writes data to it. 2. When a process needs to allocate space from the redo buffer, the occupied space in the redo buffer is calculated first. If the space is greater than the value of _ log_io_size, at this time, the LGWR is idle, and the execution of background write is activated. The default value of _ log_io_size is 1/3 of the redo buffer size. Starting from 8.0, the upper value of _ log_io_size is 1 M, which is the same as that of other hidden parameters, the value found in the X $ KSPPSV view is 0. 3. When a transaction commit, a commit mark is generated in the redo stream, before the logs in the redo buffer include the commit mark to be written to the hard disk, this transaction cannot be recovered. Therefore, before returning a message similar to 'commit complete' to the user, wait until LGWR writes the redo buffer to the hard disk. After commit, LGWR is activated and sleeps on a log file sync wait with a timeout of 1 second. To avoid waiting, you can set the _ wait_for_sync parameter to false, but this does not guarantee that the transaction instance that has been committed can be recovered when it fails. _ Log_io_size and _ wait_for_sync both hide parameters. You can use the following SQL statement to view the value [java] select I. ksppinm name, I. ksppdesc description, cv. ksppstvl value, cv. ksppstdf isdefault, decode (bitand (cv. ksppstvf, 7), 1, 'modified', 4, 'System _ mod', 'false') ismodified, decode (bitand (cv. ksppstvf, 2), 2, 'true', 'false') isadjusted from sys. x $ ksppi I, www.2cto.com sys. x $ ksppcv cv where I. inst_id = userenv ('instance') and cv. inst_id = userenv ('instance ') And I. indx = cv. indx and I. ksppinm like '/_ %' escape '/'order by replace (I. ksppinm, '_', ''); note that the commit in the callback statement does not wait for LWGR to write data. For example, there may be n commit operations in the stored procedure, however, only the LWGR write will wait until the result is returned to the user, that is, only the last commit operation will be synchronized. An SGA variable (kcrfshsb, according to bug 182447) is used to determine the largest log block number to be synchronized. When LGWR is in the active state and is being written like a disk, the kcrfshsb variable records the highest block number to be synchronized. These commit will all be written to disk in One redo write, called group commit 4. When DBWn needs to write one or more high RBA blocks and the high rba exceeds the on-disk RBA, from 8i, DWBn puts these blocks into the delay queue and post LGWR to synchronize the highest RBA, but does not wait. DBWn will continue to execute other writes without delay, before 8i, DBWn will sleep a log file sync wait. Author: wudiisss