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 2.11 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 2.11:
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 2.12, 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 2.12:
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 2.13, 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 2.13:
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.
