Capacity Planning and Architecture - Expert Oracle RAC Performance Diagnostics and Tuning - page 47

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.