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

Write/Write Behavior
Previous discussions centered on shareable scenarios such as multiple instances having read copies of the same
block. Now we look at how cache fusion operates when multiple instances require write access to the same block.
Please note from our previous scenario in Figure 2-9 that the block has been modified by instance SSKY1 (new SCN
value is 10010); the SCN for the block on disk remains at 9996.
In a continuous operation, where there are multiple requests made between instances for different blocks, the
GCS is busy with the specific resource documenting all the block activities among the various instances. The GCS
activity is sequential, unless it has recorded the information pertaining to previous requests; it does not accept or
work on another request. If such a situation occurs, the new request is queued and has to wait for GCS to complete its
current operation to accept this request.
Figure 2-10 illustrates the steps involved when an instance has acquired a block for write activity and another
instance requires access to the same block for a similar write operation.

15

18

17

SSKY2 SSKY3 SSKY4

SSKY1

R7

R5

R1

R3

R8

CR

R2

R4

500:9996
500:10010

500:9996

500:10016

16

SCN 9996

Block 450
Block 490

Block 459 Block 550

Block 500

Block 600

SSKYDB

Figure 2-10. Write/write behavior

These are the steps:

15. Instance SSKY2 , which originally had a read copy of the block, and based on the write

request from instance SSKY1 received instructions from the GCS to clear the block buffer
(marked as CR), now requires a copy of the block to make updates. Since the block is no
longer in the local cache (local cache miss), instance SSKY2 makes a request to the GCS for
an exclusive resource on the block.