Oracle Cache Fusion Cache Fusion Concepts, Data Block Shipping, and Recovery with Cache Fusion.

download Oracle Cache Fusion Cache Fusion Concepts, Data Block Shipping, and Recovery with Cache Fusion.

of 24

  • date post

    18-Jan-2016
  • Category

    Documents

  • view

    216
  • download

    0

Embed Size (px)

Transcript of Oracle Cache Fusion Cache Fusion Concepts, Data Block Shipping, and Recovery with Cache Fusion.

  • Oracle Cache FusionCache Fusion Concepts, Data Block Shipping, and Recovery with Cache Fusion

  • ObjectivesAt the end of this module the student will understand the following tasks and concepts.Cache fusion conceptsBlock transfers using cache fusionCache Fusion and Recovery

  • OverviewSynchronizationPast ImagesCache Fusion ScenariosRecovery Methodology and stepsRecovery Process Scenarios

  • Synchronization of Concurrent TasksRAC synchronization through Cache Fusion:Maintains cluster-wide concurrency of resources Ensures integrity of shared dataData blocks and enqueues are synchronized when nodes within a cluster:Acquire block or enqueue ownership Release block or enqueue ownership

  • Minimize SynchronizationKey is to optimally divide tasks among nodes, so that very little synchronization is necessaryMinimize inter-node communication, because block access in local cache is cheapest:Block access in local cache ~ 0.01 msecBlock access in remote cache ~ 2.5 msecBlock access on disk ~ 14 msec+

  • Past ImagesPast Images introduced in Oracle 9i RAC to maintain data integrityDirty data block not written to disk immediatelyAnother instance may request the same block for read or writeImage of the block is created at owning instance, and is shipped to requesting blockBackup image kept at owning block is a Past Image, and is kept in memory for local consistency

  • Juggling Data with Multiple Past ImagesMultiple Past Image versions of a data block may be kept by different instancesUpon a checkpoint, only the current image is written to disk; Past Images are discardedIn the event of a failure, current version of block can be reconstructed from PIsSince PIs are kept in memory, they aid in avoiding frequent disk writesThis avoids disk pinging experienced with 8i OPS due to frequent writes to diskData is juggled in memory, without touching down on the disk

  • Cache Fusion Scenario 1: Read/Read Cache Fusion GCS ProcessingGlobal Cache Service (GCS)BlockBlockSGABufferCacheSGABufferCache(3) Ship(1) Request(4) Inform GCS1: (Shared, Local)2: (Shared, Local)(2) ForwardLocks:(None) (Shared, Local)Locks:(Shared, Local)Instance 1Instance 2Based on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Cache Fusion Scenario 2: Write/Write Cache Fusion GCS ProcessingGlobal Cache Service (GCS)BlockBlockSGABufferCacheSGABufferCache(3) Ship(1) Request(4) Inform GCS1: (Exclusive, Global)2: (Null, Global, Past Image)(2) ForwardLocks:(None) (Exclusive, Global)Locks:(Exclusive, Local) (Null, Global, Past Image)Instance 1Instance 2Based on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Cache Fusion Scenario 3: Write Blocks to Disk GCS ProcessingGlobal Cache Service (GCS)BlockBlockSGABufferCacheSGABufferCache(2) Forward(4) Notify GCS of write and inform GCS1: (Exclusive Local)2: (None)(5) Flush PILocks:(Exclusive, Global) (Exclusive, Local)Locks:(Null, Global, Past Image) (None)Instance 1Instance 2(1) Write Request(3) WriteBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Online Instance Recovery StepsInstance Failure detected by Cluster Manager and GCSReconfiguration of GES resources (enqueues); global resource directory is frozenReconfiguration of GCS resources; involves redistribution among surviving instancesOne of the surviving instances becomes the recovering instance

  • Online Instance Recovery Steps (cont.)SMON process of recovering instance starts first pass of redo log read of the failed instances redo log threadSMON finds BWR (block written records) in the redo and removes them as their PI is already written to diskSMON prepares recovery set of the blocks modified by the failed instance but not written to diskEntries in the recovery list are sorted by first dirty SCNSMON informs each blocks master node to take ownership of the block for recovery

  • Online Instance Recovery Steps (cont.)Second pass of log read begins. Redo is applied to the data files.Global Resource Directory is unfrozen

  • RAC Recovery Solving the MysteryRecovering from a failed RAC instance is like solving a Detective mysteryPart of the evidence is missing by definition, the failed instance is inaccessible at recovery timeThere are clues in this case the lock state and mode of the blocks on the surviving nodes.Tip 1: Whichever node has an exclusive lock on a given block has the most recent version of that blockTip 2: If the mode of surviving blocks is local, any change made was on one node ony. If the mode of surviving blocks is global, changes have been made on multiple nodes.Tip 4: If the block mode is global and a node has a past image, there is a newer version of the block on another node.

  • Lock Remastering (Scenario-1)Exclusive, LocalNone

    Exclusive, LocalNoneRemove fromrecovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAquiredXCurrent copyof bufferBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-2)Exclusive, GlobalNull, Global,Past Image

    Exclusive, GlobalNull, Global,Past ImageRemove fromrecovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAcquiredXWrite to diskBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-3)NoneExclusive, Local

    NoneExclusive, LocalRemove fromrecovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAcquiredXNo need to write to diskBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-4)Null, Global,Past ImageExclusive, Global

    Null, Global,Past ImageExclusive, GlobalRemove fromrecovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAcquiredXWrite to diskBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-5)NoneExclusive, Global

    Null, Global,Past ImageNoneRemove fromrecovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAcquiredXwrite to diskBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-6)NoneNone

    (Exclusive, LocalImplied)

    Exclusive, LocalNoneKeep in recovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAcquiredXBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-7)None

    Exclusive, GlobalNull, Global,Past ImageKeep in recovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAquiredXSend Cr block to A(Exclusive, GlobalImplied)Null, Global,Past ImageBased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma

  • Lock Remastering (Scenario-8)Null, Global,Past ImageNull, Global

    Exclusive, Global,Past ImageNull, GlobalKeep in recovery listRecoveringInstance AOpenInstance BFailedInstance CLock HeldLockAquiredXSend Cr block to ABased on Oracle 9i RAC Oracle Real Application Clusters Configuration and Interals Mike Ault, Madhu Tumma(Exclusive, GlobalImplied)

  • ReviewName two times that data blocks and enqueues are synchronized.True or false: since communication across the private interconect is fast, you want to maximize the amount of inter-node communication.True or false: multiple instances may hold Past Images of the same block at the same time.All cache fusion requests must pass through the ___.True or false: an instance with an exclusive lock with a global resource role contains the most current version of a block.

  • SummaryCache Fusion synchronizes resources cluster-wide such as:Data blocksEnqueuesPast Images are used to maintain data block integrity No immediate disk write requiredAvoids disk pingingThe GCS plays a key role in performing the necessary block transfers Including lock mode conversionsUpon recovery, GCS remasters cache resources of a failed node or nodes on one or more recovery nodes

    In this cache fusion scenario, Instance 1 wants to read a block from instance 2. Instance 1 forwards a request to the GCS, which keeps track of the resources, data block locations, and status of each instance. The GCS forwards the request to instance 2. On instance 2, the requested data block is currently in a shared access mode and is assigned a local role. Instance 2 forwards the block as requested, but since the requesting instance is only requesting shared access, Instance 1 is able to keep its shared access lock in a local role. Upon receiving the block, Instance 2 informs the GCS of the resource dispositions of both Instance 1 and 2 (both are shared, local).

    The block was successfully transferred through the high speed interconnect, and no disk read had to occur.In this scenario, Instance 1 wishes to update a data block and submits a request to the GCS. The GCS forwards the request to Instance 2. Instance 2 has already modified the requested block in memory, but the modification has not been written to disk. Instance 2 ships the block to instance 1 through the private interconnect. Instance 1 downgrades its own lock from exclusive to null. Since the block is dirty and now involves more then one instance, the block role is elevated to global on both instances. Instance 2 retains its version of the dirty buffer as a Past Image. Meanwhile, Instance 1 makes its own modification, and changes its