4.8 Global cache management

 < Day Day Up > 



Cache fusion brings about interinstance transfer of data blocks between the buffer cache of one instance to the buffer cache of another instance.

It is the GCS that tracks the locations, modes, and roles of data blocks and makes updates to the GRD. By tracking these states, the GCS plays an important role in global cache management, acquiring resources at a cluster-wide level and providing cache coherency when the current version of a data block is in one instance's buffer cache and another instance requests that block for modifications. GCS, in its ultimate wisdom of managing the global cache, also ensures that only one instance could modify a block at a given time.

Figure 4.7 illustrates the global cache management between the various background processes. When a user process from another instances makes a request for a block of data that the current instance is holding, the LMD process builds the initial block and passes it to GRD. If the GRD contains the block information (based on the type of request) it creates a PI, assigns an SCN and passes the block to the LMS process. In turn, the LMS process returns the block to the requesting instance and it finally reaches the user process.

click to expand
Figure 4.7: Global cache management.

When an instance needs to write a block to disk upon a checkpoint request, the instance checks the role of the resource covering the block. If the role is global, the instance must inform the GCS of the write requirement. The GCS is responsible for finding the most current block image and informing the instance holding the image to perform the block write. The GCS then informs all holders of the global resource that they can release the buffers holding the PI copies of the block, thus allowing the global resources to be released.

As shown in Figure 4.7, a block written record (BWR) is placed in the redo log buffer when an instance writes a block covered by a global resource, or when it is told it can free up a PI buffer. Recovery processes use this record to indicate that redo information for the block is not needed prior to this point.

During interinstance transfer of blocks, there could be a situation when an instance receives a current copy of a block for which it already has a PI copy. If, during the write request operation, an instance receives a current copy of the block for which it already has a PI copy, the instance will keep both the copies of the block. The receiving instance has to serve the block to another instance and the GCS includes an indication of whether a write is in progress that would free the PI.

If a write is not occurring, the instance replaces the old PI with a new PI created from the current image. This creates a single string of redo for the block, terminated by just one BWR when the block is finally written to disk. Under such circumstances the instance creates a new PI from the current image.

When the current image is served, a write-in-progress bit is set in the block if the block is holding an exclusive mode resource. This is required to synchronize block writes when the serving instance holds the original local role resource. The SCN of the PI is used during instance recovery to reconstruct the current and consistent read version of the block.



 < Day Day Up > 



Oracle Real Application Clusters
Oracle Real Application Clusters
ISBN: 1555582885
EAN: 2147483647
Year: 2004
Pages: 174

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net