Oracle must now either find a copy of the buffer or build a copy of the current mode buffer so the buffer represents the situation at time T100. A buffer copy is commonly called a buffer clone. Cloning a buffer is a relatively expensive process. First, a free buffer must be found, and then the buffer header must be properly connected into the CBC structure and also the LRU chain structure. As I will detail in the next section on LRU chains, completing this process requires multiple latches, consumes CPU, and potentially generates IO.

The key to understanding the potentially significant performance impact is in understanding where the cloned buffer's buffer header will be placed in the CBC structure. Because a cloned buffer is a legitimate buffer, it occupies space in the buffer cache, can be shared, and must be locatable. This means it must be properly placed in the CBC structure. The "ah ha!" moment occurs when we realize that the cloned buffer's file number and block number are the same as its current mode buffer, which means it must be hashed to the same CBC! Therefore, if a buffer has 50 clones, its associated CBC will be at least 50 buffer headers long. and possibly even longer if collisions with other buffers have occurred. And there is nothing Oracle can do about this, because the hashing algorithm is based on the file number and block number. OraPub's OSM clone script, clone.sql, displays all buffers with at least one clone. During a nonpeak time, run this clone script, as shown in Figure 6-11. An example output snippet is shown in Figure 6-12. Cloned buffers are a common occurrence in Oracle systems, and in fact are required to satisfy read consistent queries. Still, it is surprising to see that so many clones are invading your buffer cache.

Figure 6-11. This script will show the number of clones for buffers having at least one clone. It is simple to tell if there are clones because there will more than one buffer header with the same file number and block number.