Cache Fusion and Resource Coordination
Since each node in Real Application Cluster has its own memory(cache) that is not shared with other nodes, RAC must coordination the buffer caches of different nodes while minimizing additional disk I/O that could reduct performance. Cache Fusion is the technology that uses high-speed interconnects to provide cache-to-cache transfers of data blocks between instances in a cluster. Cache Fusion functionality allows direct memory writes of dirty blocks to alleviate the need to force a disk write and re-read(or ping) the commited blocks. However, this is not to say that disk writes do not occur. Disk writes and still required for cache replacement and when a checkpoint occurs. Cache Fusion addresses the issues involved in concurrency between instances: concurrent reads on multiple nodes, concurrent reads and writes on different nodes, and concurrent writes on different nodes.
Oracle only reads data blocks from disk if they are not already present in the buffer caches of any instance. Because data block writes are deferred, they often contain modifications from multiple transactions. The modified data blocks are written to disk only when a checkpoint occurs. Before we go further, we need to be familiar with a couple of concepts introduced in Oracle 9i RAC:resource modes and resource roles. Because the same data blocks can concurrently exist in multiple instances, there are two identifiers that help to coordinate these blocks:
l Resource mode: The modes are null, shared, and exclusive. The block can be held in different modes, depending on whether a resource holder intends to modify data or merely read them.
l Resource role:The roles are locally managed and globally managed.
Global Resource Directory(GRD) is not a database. It is a collection of internal structures and is used to find the current status of the data blocks. Whenever a block is transferred out of a local cache to another instance’s cache, GRD is updated. The following information about a resource is available in GRD:
l Data Block identifiers(DBA)
l Location of most current versions
l Modes of the data blocks(N,S,X)
l The roles of the blocks (local or global)
To maintain the data integrity, a new concept of past image was introduced in 9i Version of RAC. A past image(PI) of a block is kept in memory before the block is sent and serves as an indication of whether or not it is a dirty block. In the event of failure, GCS can reconstruct the current version of the block by reading PIs. This PI is different from a CR block, which is needed to reconstruct read-consistent images. The CR version of a block represents a consistent snapshot of the data at a point in time.
As an example, Transaction-A f instance-A has updated row-2 on block-5, and later another Transaction-B of Inst-B has updated row-6 on same block-5. Block-5 has been transferred from Inst-A to B. At this time, Past Image(PI) for block-5 is created on Insta-A.
System change numbers(SCNs) uniquely identify a commited transaction and the changes it makes. An SCN is a logical time stamp that defines a committed version of a database at one point in time. Oracle assigns every committed transaction a unique SCN.
Within RAC, since you have multiple instances that perform. commits, the SCN changes need to be maintained within an instance, but at the same time, they must also be synchronized across all instances with a cluster. Therefore, SCN is handled by the Global Cache Service using the Lamport SCN generation scheme, or by using a hardware block or dedicated SCN server. SCNs are recorded in the redo log so that recovery operations can be synchronized in Oracle 9i Real Application Cluster.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/104152/viewspace-167568/，如需转载，请注明出处，否则将追究法律责任。