I understand that this is difficult to believe, so I created a simple script to demonstrate it, as shown in Figure 8-2. The script is executed while other sessions are making changes to the customers table. First, the script records the redo associated with my connected session. The v$mystat view's redo size statistic shows how much redo in bytes a connected session has generated since connection.

Figure 8-1. Shown is a script that will report a session's redo generation since connect, sleep for 5 seconds, touch every block in the customers table, and then again report on a session's redo generation since connect. The redo generation statistic (redo size) number depends on the Oracle release. In this script, the redo size statistic number is 133. Of course, the where clause could have filtered based on the statistic name.

The redo size statistic number depends on the Oracle release, so I always double-check. This script was run on an Oracle Database 10g Release 1 system, which assigns the redo size statistic as number 133. In Oracle Database 11g Release 1, the redo size statistic number is 140. While Oracle does occasionally change a statistic number, changing the name is even less likely. Therefore, the query in Figure 8-1 could easily have filtered on the statistic name instead of its number.