Suppose a server process is running a query at time T100. The process accesses the data dictionary and knows it must access a specific block, so it hashes to the appropriate chain, acquires the appropriate latch, scans the chain, and finds the current mode buffer's buffer header. However, upon examination of the buffer header, it is discovered the current mode buffer was changed at time T200, which is after the server process started its query. This means it is possible that the row(s) needed could have been changed after the query started. Oracle's default read consistency model demands the information returned will be as it was when the query started. Therefore, Oracle must take action to ensure the returned information is correct as of time T100.

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.