Figure 8-2 shows what we hope to see. The session initially generated 441,628 bytes of redo. Next, it slept for 5 seconds, and then it touched all customers table blocks by doing a full-table scan. It's important to understand that the session did not change any customers rows. However, other sessions had made changes, and those changes were committed. It just happened that this session was the first session to touch customers table blocks after one of the block's rows had been committed. As a result of the session touching the buffer, block cleanouts occurred, generating redo associated with my session. The ending redo bytes generated value was 881,952, which clearly demonstrates that by simply querying the customers table, my session generated 440,324 bytes of redo!

Some DBAs have experienced this seemingly strange phenomenon. Their story is very similar: During nightly batch processing, many blocks were changed. When the employees arrived in the morning and started querying the database, the DBA noticed a lot of redo being generated. So, what may seem like an anomaly makes perfect sense after all.

Compared to the buffer cache and shared pool memory structures, the redo log buffer is very straightforward. While Oracle continues to enhance the redo log buffer architecture, the central idea has remained the same: buffer and batch redo changes to improve log writer background process efficiency and enable extremely quick commit times.