Say you are inserting a row, updating a row, deleting a row.

Each of those will generate redo.

Say we wrote redo to the files immediately, and we didn't buffer it at all. So, the insert would suffer a 3-5ms write, the update would too, the delete - yes. And if they had indexes on the table (say three of them) each of the index modifications would suffer these waits as well - so another 3-5ms x three for each of the statements.

So, the insert would wait between 12-20ms and so on.


So, now we buffer, the insert puts it's redo into the redo log buffer (not measurable in time really) and goes onto the update part. While it is doing its update part- LGWR is free (and will) write the data in the log buffer to disk - in the BACKGROUND. You (end user doing the insert/update/delete transaction) didn't have to wait four times for 3-5ms. Same with the update. Same with the delete.

At worst - you wait 3-5ms ONCE during the commit.
At best - you don't wait at all because between the time you did the delete and the commit - lgwr might have done its magic (or been half way through).



The time to commit 1,000,000 records updated is the same as the amount of time to update 1 record. Because of this buffer.

If you update 1,000,000 rows - you'll be generating gobs of redo into the log buffer. LGWR (in the background, you do not wait for this) is constantly putting this to disk. When you go to commit - the redo for the previous 999,999+ rows is already on disk. The commit has to wait (log file sync is the wait event) a very short amount of time to commit those 1,000,000 rows.