RAC Block Access Modes and Buffer States

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.

The buffer state indicates the status of a buffer in the local cache of an instance. Information about the buffer state can be seen in the dynamic performance view v$bh. The buffer state of a block relates to the access mode of the block. For example, if a buffer state is in exclusive current (XCUR) state, it indicates that the instance owns the resource in exclusive mode.

To see a buffer?s state, query the STATUS column of the v$bh dynamic performance view. The v$bh view provides information about the block access mode and their buffer state names as follows:

* Buffer state ?CR? indicates that the block access mode is NULL. It means the owning instance can perform a consistent read of the block, if the instance holds an older version of the data.

* Buffer state ?SCUR? indicates that the block access mode is S (shared). It means the instance has shared access to the block and can only perform reads.

* Buffer state ?XCUR? indicates that access mode is X (exclusive). It means the instance has exclusive access to the block and can modify it.

* Buffer state ?PI? indicates that block access mode is NULL. It means that the instance has made changes to the block but retains copies of past images.

Table 7.3: Buffer States shown in v$bh view.

Only the SCUR and PI buffer states are real application cluster-specific. There can be only one copy of any block buffered in the XCUR state at any time. To perform modifications on a block, a process must assign an XCUR buffer state to the buffer containing the data block.

For example, if another instance requests a read access to the most current version of the same block, then Oracle changes the access mode from exclusive to shared, sends the current read version of the block to the requesting instance, and keeps a PI buffer if the buffer contained a dirty block

At this point, the first instance has the current block and the requesting instance also has the current block in shared mode. Therefore, the role of the resource becomes global. There can be multiple shared current (SCUR) versions of this block cached throughout the cluster database at any given point of time.

Cache Fusion Scenarios

The GCS plays a key role in performing the necessary block transfers. Three scenarios are presented to explain the concept of cache fusion:

* Scenario 1: Read/Read

* Scenario 2: Write/Write

* Scenario 3: Disk Write

Scenario 1: Read/Read

Figure 7.5 (a) shows Scenario 1, where a typical data block is requested from another instance where it is in shared access mode with a local role. Instance(1) desires to read a data block and it makes a request to the GCS, which keeps track of the resources, location, and status. The GCS in turn forwards the request to owning Instance(2).

Figure 7.5(a): Read/Read Cache Fusion ? GCS processing

The holding instance (Instance 2) transmits a copy of the block to the requesting instance (Instance 1), but keeps the resource in shared mode and also retains the local role.

Instance 2 now informs the GCS of its own resource disposition (S, L) and also that of the instance that sent the block (S, L). Thus, there is no disk read involved. The block transfer took place through the high-speed private interconnect.

Scenario 2: Write/Write

As shown in Figure 7.5(b), instance 1 intends to modify or update the data block and submits a request to GCS. The GCS transmits the request on to the holder (Instance 2).

Upon receiving the message, instance 2 sends the block to instance 1. Before sending the block, the resource is downgraded to null mode and the changed (dirty) buffer is kept as a PI. Thus, the role changes to global (G) because the block is dirty.

Along with the block, instance 2 informs the requestor that it retained a PI copy and a null resource. The same message also specifies that the requestor can take the block held in exclusive mode and with a global role (X, G).

Figure 7.5 (b): Write/Write Cache Fusion ? GCS processing

Upon receipt of the block and the resource dispositions, instance 1 informs the GCS of the mode and role (X, G). Note that the data block is not written to disk before the resource is granted to the other instance. That is, DBWR is not involved in the cache coherency scheme at this stage.

Scenario 3: Disk Write

As shown in Figure 7.5(c), instance 2 first sends a write request to the GCS. This might be due to a user-executing checkpoint on instance 2. Note that there is a past image for the block on instance 2. The GCS forwards the request to instance 1 (the current block holder). The GCS remembers that a write at the system change number (SCN) is pending and it also remembers that it has to notify the nodes that have PIs of the same block.

Instance 1 then receives the write request and writes the block to disk. Instance 1 completes the write and notifies the GCS. Instance 1 also informs the GCS that the resource role can become local because the instance has completed the write of the current block. After completion of the protocol, all PIs of the block should be discarded.

Figure 7.5 (c):  Write blocks to disk ? GCS Processing

Upon receipt of the notification, the GCS orders all PI holders to discard (or flush) their PIs. Discarding, in this case, means that upon receipt of the message the PI holder records that the current block has been written and the buffer is released. The PI is no longer needed for recovery. The buffer is essentially free and the resource previously held in null mode is closed.