Tuning Global Cache - Expert Oracle RAC Performance Diagnostics and Tuning - page 396

ii) Request another instance to transfer the block.

a. Instance SSKY2 sends a request for a read resource on the block to the GCS master.

Because the master for this resource is maintained on instance SSKY4 , SSKY2 makes a
request to SSKY4 requesting access to this block.

b. At the master, instance SSKY4 , the request is verified against its GRD and determines that

the block is currently held by instance SSKY3 . The LMS for this resources ends a request to
instance SSKY3 requesting it to transfer the block for shared access to instance SSKY2.

c. 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 access mode.

Instance SSKY2 receives the block along with the access right transferred via the message header from instance
SSKY3 . To complete the communication cycle, instance SSKY2 sends a message to the master that it has received a
copy of the block. At the end of the transfer, the global cache is consistent on sender, receiver, and master nodes.
The statistics collected for this scenario are similar to those collected in the previous scenario illustrated in
Figure 13-3 . However, because more than two instances are involved in this scenario apart from the statistics we
discussed earlier, the instances could experience one or more of these wait events:

gc current block 3 way
gc current grant busy
gc current grant congested
gc cr block 3 way

■ Note Wait events are discussed in Chapter 17.

From the RAC architecture discussed previously, the cluster interconnect is the backbone and primary
component in a RAC configuration. For obvious reasons and because the way the RAC is architected, one tends to
blame the interconnect latency or bandwidth for performance issues on the interconnect versus looking at the root
cause of the problem.
In a RAC environment, illustrated in Figure 13-3 and Figure 13-5 , when a session on one instance requests for a
block, if the block is not found on the local buffer of the requesting instance, the block is requested from the holding
instance and transferred to the requesting instance. During this process, instead of rereading the block of data
from disk, the data is transferred from the holding instance to the requesting instance. When a request for a block
is received, the GCS processes get involved, locating the block with the help of the GRD; and based on the type of
operation, the user is granted appropriate rights before the data is physically transferred across the interconnect to the
requesting instance. At the block serving instance, this entire process can be grouped under two primary phases: the
prepare phase and the transfer phase. As obviously noted, the transfer phase involves shipping or sending the block
of data from the holding instance to the requesting instance and it involves the interconnect. However, the point to
be noted is that unless the block is prepared and ready to be shipped, it cannot be transferred. So the first step is to
prepare the block.