Oracle RAC Cache Fusion

Cache Fusion is one of the most Important concepts in Oracle RAC.

As we know each and every instance of RAC cluster is having its own local buffer cache where it does cache functionality.But when multiple users are connected to different nodes , a need to access or lock a data block owned by other instance often happens.

In such cases requesting instance requests a holding instance for that data block and access it through interconnect mechanism.This concept is known as CACHE FUSION.

As interconnect work on a high-speed private network, access block from other instance’s cache is much faster than accessing it from disk.This data block shipping eliminates the disk I/O and optimizes read/write concurrency.

When multiple instances are trying to access same data block the Integrity of data must be maintained. For that Oracle uses locking and queuing mechanisms to coordinate inter-instance request of a data block.

Cache Fusion is implemented by a controlling mechanism called Global Cache Service[GCS].And yes, to maintain the integrity of data is a task of GCS.

We can say that GCS is a heart of CACHE FUSION process. GCS is available in RAC as LMS background process.

To know more about How GRD works in Oracle RAC.

Before going to example let us see, what is CR image of a data block and Past Image of the data block.

CR Image: A consistent read (CR) block represents a consistent snapshot of the data from a previous point in time. Applying undo/rollback segment information produces consistent read versions.

Past Image:  Past Image is converted from Exclusive current block , when another request comes for exclusive lock on the same block. Past Images are not written to the disk , After the latest version of that block is written to the disk all  Past Images are discarded.

Let us understand how GCS works , through examples ,

Example 1[write-read] :

1. Instance A is holding a data block in exclusive mode.
2. Instance B is trying to access the same block for read purpose.
3. If transaction is not yet committed by Instance A, in this case instance A cannot send current block to requesting instance as data yet not committed , so it will create consistent read version of that data block by applying undo to that block and sends it to requesting instance.
4. Creating a CR image in RAC can come with some I/O overheads. This is because the UNDO data could be spread across instances and hence to build a CR copy of the block, the instance might has to visit UNDO segments on other instances and hence perform certain extra I/O.

Now what actually happens inside  :

When any Instance access any data block , GCS keep track of it and store it in GRD saying the latest block is with this instance in our case, Instance A. So when other instance [Instance B] ask for same block, it can easily find that block is with Instance A.It also stores the block is being accessed in Exclusive mode.So when other instance asks for shared lock on this , it will check transaction is committed or not , if not it creates a read consistent image for that data block and send it to requesting instance. After shipping block to requesting instance it also stores that details in GRD, CR image is with Instance B which is having shared lock and Instance B still holds exclusive lock.

Example 2[write-write]:

In case of write-write operations , past image comes into the picture , Instance A is holding a data block in exclusive mode and Instance B is trying to access the same data block in exclusive mode too.So , here Instance B needs a actual block and not a consistent read version of the block. In this scenario, holding instance sends an actual block, but is liable to keep past image of the block in its cache until that data block has been written to the disk. In case of node failure or node crash, GCS is able to build that data block using PI image across the cluster. Once the data block is written to disk, all PIs can be discarded as it won’t need a recovery in case of a crash.

Past Image[PI] and Consistent Read[CR] image in above example:

CR image is used in read-write contention, in this case, one instance is holding the block in exclusive mode and the second instance requests a read access to that block so it won’t need an exclusive lock, consistent read image consistent with the requested query scn is sufficient here.

Whereas the first Instance has acquired the exclusive lock and the second instance also wants the same block in an exclusive mode it is write-write contention.
In this case two possibilities are there either instance A releases the lock on that block (if it no longer needs it) and lets instance B read the block from the disk OR instance A creates a PI image of the block in its own buffer cache, makes the redo entries and ships the block to the requesting instance via interconnect .

Another specification we can give is, the CR image is to be shipped to the requesting instance whereas the PI has to be kept by the holding instance after shipping the actual block.

In order to facilitate Cache Fusion, we still need the Buffer Cache, the Shared Pool, and the Undo tablespace just like a single-instance database. However, for Oracle RAC, we need the Buffer Caches on all instances to appear to be global across the cluster.

To do this, we need GRD – Global Resource Directory to keep track of the resources in the cluster.There is no true concept of a master node in Oracle RAC. But each node belongs to a cluster , becomes the resource master for a subset of resources.The GCS processes [LMS] are responsible for facilitating blocks through interconnect.

Stay Tuned for Split Brain Syndrome in Oracle RAC.

Thank you for giving your valuable time to read the above information.

If you want to be updated with all our articles send us the Invitation or Follow us:

Skant Gupta’s LinkedIn: www.linkedin.com/in/skantali/

Joel Perez’s LinkedIn: Joel Perez’s Profile

Anuradha’s LinkedIn: Anuradha’s Profile

LinkedIn Group: Oracle Cloud DBAAS

Facebook Page: OracleHelp