Oracle Cache Fusion Explained – Part II

Cache fusion potentially expose your database to many contention problem on resources. Typical contentions are:

• Read/Read contention - a false problem as a shared storage can be deal this contention without GCS intervention


• Write/Read contention - solved using consistent read technology


• Write/Write contention - contention addresses to Cache Fusion technology solved shipping needed block across instances using interconnect

Consistent Read Server

How cache fusion can deal the write/read contention? Behavior used in past is well known. When an instance needs to read a block that was currently in transaction from another one, it has to request to DLM that requests to the owning instance to downgrade the lock. If owning instance can downgrade the lock write the block to disk and inform DLM, so the other instance is able to read block from disk. This process is in itself I/O intensive has you have to write and read from disk the block.

What is done with new cache fusion? Suppose that you need to modify a block that is recently modified by another instance.....Cache Fusion will do:

1. Instance sends a message to lock manager to request a shared lock on the block


2. Lock manager asks the owning instance to build a CR copy and ship it to requesting instance


3. The owning instance builds up CR  version in own buffer cache and shit thought interconnect to requesting instance


4. The owning instance informs DLM and requesting instance about block already shipped


5. Requesting instance informs DLM that now it holds the block

This process is really faster than in past and does not involve, normally, disk I/O. In fact during build of CR copy if owning instance does not find block in his own buffer cache will refuse to build the CR copy.

Also owning instance will prevent itself from flooding requests of CR copies. After the fourth request it will release the lock, write block to disk and let requesting instance to read if from disk. This behavior may be controlled with the hidden parameter _fairness_threshold.

Write/Write Cache Fusion

Write/write cache fusion sometimes is called Cache Fusion II just to address this as a second new features. Background is fairly the same. An instance is requesting a block that is recently modified by another instance. To do so in past block would be written and read again from disk. What about with Cache Fusion? The operation is easy:

1. Instance sends a message to lock manager to request a shared lock on the block


2. Lock Manager asks the owning instance to release the lock


3. Owning instance sends current block to requesting instance via interconnect. For recovery porpurses owning instance write all change vectors to online redolog. Also keep a past image of the block and inform DLM that block is sent to requesting instance.


4. The requesting instance acquire the lock and when block is written to disk informs the GCS to broadcast the message to discard the past images of the block.