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
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.
BLOCK ACCESS MODE
BUFFER STATE NAME
Instance has exclusive
access to the block and therefore can modify the block.
Instance has shared access
to the block and can only perform reads.
Contains an older version of
the data. Can perform consistent read
Past Image Exist
(useful for recovery)
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
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
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
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
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.