Forgot your password?    
+ Reply to Thread
Results 1 to 1 of 1

Thread: Cache Fusion in Oracle RAC

  1. #1
    Expert Oracle Administrator
    Join Date
    Oct 2011
    New Delhi, India

    Cache Fusion in Oracle RAC

    Cache Fusion is a shared cache architecture that uses high speed low latency interconnects available today on clustered systems to maintain database cache coherency. Database blocks are shipped across the interconnect to the node where access to the data is needed. This is accomplished transparently to the application and users of the system.

    Overview of Cache Fusion Processing

    By default, a resource is allocated for each data block that resides in the cache of an instance. Due to Cache Fusion and the elimination of disk writes that occur when other instances request blocks for modifications, the performance overhead to manage shared data between instances is greatly diminished. Not only do Cache Fusion's concurrency controls greatly improve performance, but they also reduce the administrative effort for Real Application Clusters environments.

    Cache Fusion addresses several types of concurrency as described under the following headings:

    Concurrent Reads on Multiple Nodes
    Concurrent Reads and Writes on Different Nodes
    Concurrent Writes on Different Nodes
    Concurrent Reads on Multiple Nodes

    Concurrent reads on multiple nodes occur when two instances need to read the same data block. Real Application Clusters resolves this situation without synchronization because multiple instances can share data blocks for read access without cache coherency conflicts.

    Concurrent Reads and Writes on Different NodesA read request from an instance for a block that was modified by another instance and not yet written to disk can be a request for either the current version of the block or for a read-consistent version. In either case, the Global Cache Service Processes (LMSn) transfer the block from the holding instance's cache to the requesting instance's cache over the interconnect.

    Concurrent Writes on Different Nodes
    Concurrent writes on different nodes occur when the same data block is modified frequently by different instances. In such cases, the holding instance completes its work on the data block after receiving a request for the block. The GCS then converts the resources on the block to be globally managed and the LMSn processes transfer a copy of the block to the cache of the requesting instance. The main features of this processing are:

    The Global Cache Service (GCS) tracks a each version of a data block, and each version is referred to as a past image (PI). In the event of a failure, Oracle can reconstruct the current version of a block by using the information in a PI.

    The cache-to-cache data transfer is done through the high speed IPC interconnect, thus eliminating disk I/O.

    Cache Fusion limits the number of context switches because of the reduced sequence of round trip messages. Reducing the number of context switches enables greater cache coherency protocol efficiency. The database writer (DBWn) processes are not involved in Cache Fusion block transfers.

    Write Protocol and Past Image Tracking
    When an instance requests a block for modification, the Global Cache Service Processes (LMSn) send the block from the instance that last modified it to the requesting instance. In addition, the LMSn process retains a PI of the block in the instance that originally held it.

    Writes to disks are only triggered by cache replacements and during checkpoints. For example, consider a situation where an instance initiates a write of a data block and the block's resource has a global role. However, the instance only has the PI of the block and not the most current buffer. Under these circumstances, the instance informs the GCS and the GCS forwards the write request to the instance where the most recent version of the block is held. The holder then sends a completion message to the GCS. Finally, all other instances with PIs of the block delete them.

    Resource Control, Cache-to-Cache Transfer, and Cache Coherency
    The GCS assigns and opens resources for each data block read into an instance's buffer cache. Oracle closes resources when the resources do not manage any more buffers or when buffered blocks are written to disk due to cache replacement. When Oracle closes a resource, it returns the resource to a list from which Oracle can assign new resources.

    Block Access Modes and Buffer States
    An additional concurrency control concept is the buffer state which is the state of a buffer in the local cache of an instance. The buffer state of a block relates to the access mode of the block. For example, if a buffer state is exclusive current (XCUR), an instance owns the resource in exclusive mode.

    To see a buffer's state, query the STATUS column of the V$BH dynamic performance view. The V$BH view provides information about the block access mode and their buffer state names as follows:

    With a block access mode of NULL the buffer state name is CR--An instance can perform a consistent read of the block. That is, if the instance holds an older version of the data.

    With a block access mode of S the buffer state name is SCUR--An instance has shared access to the block and can only perform reads.

    With a block access mode of X the buffer state name is XCUR--An instance has exclusive access to the block and can modify it.

    With a block access mode of NULL the buffer state name is PI--An instance has made changes to the block but retains copies of it as past images to record its state before changes.

    Only the SCUR and PI buffer states are Real Application Clusters-specific. There can be only one copy of any one block buffered in the XCUR state in the cluster database at any time. To perform modifications on a block, a process must assign an XCUR buffer state to the buffer containing the data block.

    For example, if another instance requests read access to the most current version of the same block, then Oracle changes the access mode from exclusive to shared, sends a current read version of the block to the requesting instance, and keeps a PI buffer if the buffer contained a dirty block.

    At this point, the first instance has the current block and the requesting instance also has the current block in shared mode. Therefore, the role of the resource becomes global. There can be multiple shared current (SCUR) versions of this block cached throughout the cluster database at any time.

+ Reply to Thread

Similar Threads

  1. How to Tune Shared Pool Cache ?
    By ajaychandi in forum Database Performance Management,Database Links,Materialized Views
    Replies: 0
    Last Post: 11-12-2012, 03:31 AM
  2. Download Fusion Middleware Products from e-delivery
    By Hemant in forum Oracle Fusion Middleware 11G - OIM , OAM , ODS , Weblogic , Webgate ..
    Replies: 0
    Last Post: 04-24-2012, 01:05 AM
  3. Create Repository for Oracle Fusion Middleware Components using RCU Utility
    By Hemant in forum Oracle Fusion Middleware 11G - OIM , OAM , ODS , Weblogic , Webgate ..
    Replies: 0
    Last Post: 04-18-2012, 01:35 AM
  4. Db buffer cache
    By dbaANKIT in forum Core Database Administration and Monitoring
    Replies: 0
    Last Post: 11-29-2011, 02:54 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

DBA Lounge (P) Ltd. deals in Oracle Technologies on Consulting, Resourcing, Corporate Training

Online and corporate training available on Oracle Database 11g, Oracle 11g Real Application Cluster (RAC), Oracle Applications 11i/R12, Oracle Fusion Middleware 11g, Oracle Identity Management-OIM, Oracle Internet Directory 11g-OID, Oracle Business Intelligence Enterprise Edition-OBIEE, Oracle Golden Gate, Oracle Access Management-OAM, Oracle Internet Directory-ODS, Oracle Identity Analytics Architecture-OIA Statistics