Earlier in this chapter, I introduced block cloning as it relates to CBC latch contention. Now I will delve deeper into exactly how Oracle does this using ITLs, undo blocks, SCNs, and other interesting Oracle tidbits.

If you recall, when a server process locates a desired buffer and discovers a required row has changed since its query began, it must create a back-in-time image of the buffer. This is known as a consistent read (CR) buffer of the current (CU) buffer. Once the buffer is copied, the appropriate undo is applied, bringing the copied buffer back in time until the CR buffer has been properly cloned. Now let's step through this process.

Figure 6-40 is the basis for this example. Suppose our query begins at SCN time 12330. At SCN time 12355, our query finally gets around to accessing buffer 7,678. However, we notice there is some ITL activity. Transaction 7.3.8 is currently active, and the buffer may have been changed since our query began. Transaction 5.2.6 is no longer active (Flag of C, has an SCN assigned, and Lck is 0), but its changes were committed after our query started and are reflected in this CU buffer. Both of these block changes mean the CU buffer has been changed after our query began at SCN time 12330 and cannot be used as is in our query. We need a version consistent copy, which is one taken back in time, at time 12330. Therefore, the CU buffer 7,678 must be cloned and undo applied, creating a SCN time 12330 CR buffer.