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

16. If the GCS has completed all previous activities pertaining to other requests, the GCS

makes a request to instance SSKY1 (the current holder of the block) to give exclusive
resource on the block and to transfer the current image of the block to instance SSKY2 .

Instance SSKY1 transfers the block to the requesting instance ( SSKY2 ) after ensuring the
following activities against this block have been completed:

17.

• Logging any changes to the block and forcing a log flush if this has not already occurred.

SSKY1 posts the LGWR to write the redo for the dirty data buffer.

• LMS on

SSKY1 performs a log I/O. • LGWR on

NULL with a past image (PI) status of 1, indicating that the buffer
now contains a PI copy of the block.

• Converting its resource to

SSKY2 . This indicates the
block image has an SCN 10010, with an exclusive resource in global mode. SSKY1 also
piggybacks a message indicating that the instance SSKY1 is holding a PI of the block.

• Sending an exclusive-keep copy of the block buffer to instance

GCS resource conversions and cache fusion block transfers occur completely outside the transaction boundaries.
That is, an instance does not have to wait for a pending transaction to be completed before releasing an exclusive
block resource.
18. After receipt of the message from instance SSKY1 , instance SSKY2 will update the row in the
block, assign it a new SCN number 10016, and send a message to the GCS. This message
informs the GCS that instance SSKY2 now has the resource with an exclusive global status
and that the previous holder instance SSKY1 now holds a PI version of the block with SCN
10010. The GCS will update the GRD with the latest status of the block.
Instance SSKY1 no longer has an exclusive resource on this block and hence cannot make any modifications to
the block.

■ despite multiple changes to the block made by the various instances, it should be noted that the block's SCn
on disk remains at 9996.

Note

Write/Read Behavior
We have looked at read/write behavior before; what would be the difference in the opposite situation? That is,
what happens when a block is held by an instance after modification and another instance requires the latest copy
of the block for a read operation? Unlike the previous read/write scenario, the block has undergone considerable
modification, and the SCN held by the current holder of the block is different from what is found on disk.
In a single-instance configuration, a query looks for a read consistent image of the row, and the behavior in a
clustered configuration is no different; Oracle has to provide a consistent read version of the block. In this example,
the latest copy of the block is held by instance SSKY2 (based on our previous scenario as illustrated in Figure 2-10 ).
Figure 2-11 illustrates the steps involved when instance SSKY3 requires a block for read purposes. From our previous
scenario, it is understood that the latest version of the block is currently held by instance SSKY2 in exclusive mode.