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

Figure 2-8 illustrates the steps involved when instance SSKY2 requires a block that is currently held by instance
SSKY3 . (To maintain clarity of the figure, Steps 1 to 4 are not repeated. Readers are advised to see Figure 2-7 in
conjunction with Figure 2-8 .)

8

5

SSKY2 SSKY3 SSKY4

SSKY1

R5

R3

R1

7 6

R8

500:9996

R4

R2

500:9996

SCN 9996

Block 450
Block 490

Block 459 Block 550

Block 500

Block 600

SSKYDB

Figure 2-8. Read/read behavior with transfer

The steps in the figure include the following:

Instance SSKY2 sends a request for a read resource on the block to the GCS. Because the
GRD for this resource is maintained on instance SSKY4 , SSKY2 makes a request to SSKY4
requesting access to this block.

5.

Instance SSKY4 checks against its GRD regarding the whereabouts of this block and
determines that the block is currently held in instance SSKY3 . GCS as the global cache
manager for this resource sends a request to instance SSKY3 requesting it to transfer the
block for shared access to instance SSKY2 .

6.

Instance SSKY3 ships a copy of the block to the requesting instance SSKY2 . During this copy
operation, SSKY3 indicates in the header of the message that instance SSKY3 is only sharing
the block (which means SSKY3 is going to retain a copy of the block). It also informs SSKY2
that it is supposed to maintain the block at the same resource level.

7.

Instance SSKY2 receives the block along with the shared resource level transferred via the
message header from instance SSKY3 . To complete the communication cycle, instance
SSKY2 sends a message to the GCS that it has received a copy of the block. The GCS now
updates the GRD.

8.