To explain this situation, I need to first discuss the topic of block cloning and then weave it into hashing. When an Oracle database block is cached, only the single current mode buffer can be modified. If a row in the buffer needs to be changed, the single current mode buffer must be available. Current mode buffers are sometimes called CU buffers. On an RAC system, if the current mode buffer you need resides in another instance, it must be sent to your instance, and then you can modify the buffer.

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.