One of Oracle's database integrity rules is to never allow a block change (not buffer, but block) to occur unless that change is first recorded in an online redo log group. So if, for any reason, a database writer wants to write to a database block, the database writer will first trigger the log writer background process to flush the log buffer, just to ensure the change is in the redo stream. While the log writer background process is busy flushing the log buffer, the database writer background process will be posting a log file sync wait event.

Once the log writer has completed the write, the database writer is free to complete its write. To reduce the likelihood of the database writer background process needing to wait, the general strategy is to ensure that the log writer background process is writing frequently.

It's pretty obvious that having the log writer background process waiting until the redo log buffer fills to begin writing could cause serious performance problems. The log writer background process could potentially need to immediately write tens of megabytes. Plus, a user could have committed during a log writer background process flush and will need to wait for the write to complete, and then for the redo log buffer to fill once again. So, to avoid this type of performance behavior, if the log writer is not triggered to write for some other reason, it will flush the general log buffer when it is the minimum of one-third full, 1MB full, or reaches the value of the initialization parameter _log_io_size multiplied by the operating system block size. The operating system block size (in bytes) can be quickly determined by issuing the following code snippet: