Global Cache Service (LMSx)

The GCS tracks the location, status (mode and role) of data blocks, and the access privileges of all instances. Oracle uses the GCS for cache coherency when the current version of a data block is in one instance’s buffer cache, and another instance requests that block for modification. It is also used for reading blocks from other instances.

Following the first read of exclusive resources, multiple transactions running in a single RAC instance can share access to a set of data blocks without involvement of the GCS as long as the block is not transferred out of the local cache. This is similar to non-RAC Oracle9i. If the block has to be transferred out of the local cache, then the GCS updates the Global Resource Directory in the shared pool.

GCS and Cache Coherency

The GCS manages all types of data blocks. Cache coherency is maintained through the GCS by requiring that instances acquire a resource (lock or enqueue on a block) cluster-wide before modifying or reading a database block. The GCS is used to synchronize global cache access, allowing only one instance to modify a block at any single point in time. The GCS, through the RAC wide Global Services Directory, ensures that the status of data blocks cached in any mode in the cluster is globally visible and maintained.

Oracle’s RAC has multi-versioning architecture. This multi-versioning architecture distinguishes between current data blocks and one or more consistent read (CR) versions of a block. A current block contains changes for all committed and yet-to-be-committed transactions. A consistent read (CR) version of a block represents a consistent snapshot of the data at a previous point in time. A data block can reside in many buffer caches under the auspices of shared resources.

In Oracle9i RAC, applying rollback segment information to current blocks produces consistent read versions of a block. Both the current and consistent read blocks are managed by the GCS.

To transfer data blocks among database caches, buffers are shipped by means of the high speed IPC interconnect. Disk writes are only required for cache replacement. A past image (PI) of a block is kept in memory before the block is sent if it is a dirty (modified) block. In the event of failure, Oracle reconstructs the current version of the block by reading the PI blocks.

GCS Resource Modes and Roles

The GCS global resource dictionary tracks resource blocks transmitted throughout the RAC system. The same block can exist in multiple caches as a result of block transfers. The block is held in different modes depending on whether a resource holder (instance) intends to modify the resource data or merely read it.

It is important to understand that a RAC resource is identified by two factors:

• Mode - The modes are null, shared, and exclusive.
• Role - The roles are local and global

Resource modes are generally set by the holder, as part of a request for a resource. The resource modes determine whether the holder can modify the block. The modes of a RAC resource are defined as:

• Null - Identified with an N. Holding a resource at this level conveys no access rights.
• Shared - Identified with an S. This signifies a protected read. When a resource is held at this level, a process cannot modify it and multiple processes can read the same resource.
• Exclusive - Identified with an X. This grants the holding process exclusive access. Other processes cannot write to the resource, but consistent reads of older blocks are still available through the PI process.

Resource roles are set by type of access, local, or global. A resource in exclusive mode is local by definition, while a null or shared mode resource is global.