Oracle RAC Cache Fusion:First things first - What is Cache Fusion?

Whoever knows the basics of RAC should very well be aware of the fact that CACHE FUSION is one of the most important and interesting concepts in a RAC setup. As the name suggests, CACHE FUSION is the amalgamation of cache from each node/instance participating in the RAC, but it is not any physically secured memory component which can be configured unlike the usual buffer cache (or other SGA components) which is local to each node/instance. We know that every instance of the RAC database has its own local buffer cache which performs the usual cache functionality for that instance. Now there could be occasions when a transaction/user on instance A needs to access a data block which is being owned/locked by the other instance B. In such cases, the instance A will request instance B for that data block and hence accesses the block through the interconnect mechanism. This concept is known as CACHE FUSION where one instance can work on or access a data block in other instances cache via the high speed interconnect. Cache Fusion architecture helps resolve each possible type of contentions that could be thought of in a multi-node RAC setup. We will look at them in detail in coming sections but first let us understand few very important terms/concepts which will be useful in understanding the contentions which we are going to discuss in later sections. August 18 at 10:22am Like

Yogesh Singh Global Cache Service Global Cache Service (GCS) is the heart of Cache Fusion concept. It is through GCS that data integrity in RAC is maintained when more than one instance need a particular data block. Instances look up to the GCS for fulfilling their data block needs. GCS is responsible for: 1. Tracking the data block 2. Accepting the data block requests from instances 3. Informing the holding instance to release the lock on the data block or ship a CR image 4. Coordinating the shipping of data blocks as needed between the instance through the interconnect 5. Informing the instances to keep or discard PIs More about the above functions will be clear from the following discussion on contention. Please note that GCS is available in the form of the background process called LMS. Past Image The concept of Past Image is very specific to RAC setup. Consider an instance holding exclusive lock on a data block for updates. If some other instance in the RAC needs the block, the holding instance can send the block to the requesting instance (instead of writing it to disk) by keeping a PI (Past Image) of the block in its buffer cache. Basically, PI is the copy of the data block before the block is written to the disk. There can be more than one PI of the block at a time across the instances . In case there is some instance crash/failure in the RAC and a recovery is required, Oracle is able to re-construct the block using these Past Images from all the instances. When a block is written to the disk, all Past Images of that block across the instances are discarded. GCS informs all the instances to do this. At this time, the redo logs containing the redo for that data block can also be overwritten because they are no longer needed for recovery. Consistent Read A consistent read is needed when a particular block is being accessed/modified by transaction T1 and at the same time another transaction T2 tries to access/read the block. If T1 has not been committed, T2 needs a consistent read (consistent to the non-modified state of the database) copy of the block to move ahead. A CR copy is created using the UNDO data for that block. A sample series of steps for a CR in a normal setup would be: 1. Process tries to read a data block 2. Finds an active transaction in the block 3. Then checks the UNDO segment to see if the transaction has been committed or not 4. If the transaction has been committed, it creates the REDO records and reads the block 5. If the transaction has not been committed, it creates a CR block for itself using the UNDO/ROLLBACK information. 6. Creating a CR(consistent read) image in RAC is a bit different and can come with some I/O overheads. This is because the UNDO 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