oracle rac cache fusion

Upload: thota-mahesh-dba

Post on 14-Apr-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/30/2019 Oracle RAC Cache Fusion

    1/1

    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 importantand 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 cachefunctionality 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 SinghGlobal 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 copyof 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 not4. 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

    https://www.facebook.com/groups/oraclegeeks/permalink/645469395478431/?comment_id=645677968790907&offset=0&total_comments=18https://www.facebook.com/https://www.facebook.com/https://www.facebook.com/https://www.facebook.com/yogesh.singh.56614https://www.facebook.com/yogesh.singh.56614https://www.facebook.com/yogesh.singh.56614https://www.facebook.com/yogesh.singh.56614https://www.facebook.com/https://www.facebook.com/groups/oraclegeeks/permalink/645469395478431/?comment_id=645677968790907&offset=0&total_comments=18