Normally, Oracle's hashing algorithm, combined with more than twice the number of chains than buffers, results in a very, very short chain. The only way for a long chain to occur would be for multiple buffers to hash to the same chain. Typically, this is not a problem, but it can occur. And this is the focus of this discussion.

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.