Database Reference
In-Depth Information
19
21
22
SSKY2
SSKY3
SSKY4
SSKY1
R7
R1
R5
R3
R8
R2
R4
500:10016
500:9996
500:10010
500:9996
500:10016
20
SCN 9996
Block 450
Block 490
Block 459
Block 550
Block 500
Block 600
SSKYDB
Figure 2-11.
Write/read behavior
The following list describes the steps:
19.
Instance
SSKY3
once had a read copy of the block; however, based on a request from the
GCS, it had converted it into a
NULL
resource (Step 10, Figure
2-9
). Based on a new query
request from a user, it now requires a read access to the block. To satisfy this request,
instance
SSKY3
makes a request to the GCS for the necessary shared resource.
Instance
SSKY2
is the current holder of the block. To satisfy the request from instance
SSKY3
, the GCS requests instance
SSKY2
to transfer the block.
20.
Instance
SSKY2
, on receipt of the message request, completes all required work (instructs
the LGWR to write redo changes to the redo log files, retains a PI image of the block) on the
block and sends a copy of the block image to instance
SSKY3
. The block is to be transferred
in a shared status with no exclusive rights; hence, instance
SSKY2
has to downgrade its
resources to shared mode before transferring the block across to instance
SSKY3
. While the
transfer happens, instance
SSKY2
retains the block's PI.
Instance
SSKY1
and instance
SSKY2
have a PI of the block at their respective SCNs.
21.
Instance
SSKY3
now acknowledges receipt of the requested block by sending a message to
the GCS. This includes the SCN of the PI currently retained by instance
SSKY2
. The GCS
makes the required updates to the GRD.
Instance
SSKY3
now has the most recent copy of the block and it is now in a global shared mode.
22.
Search WWH ::
Custom Search