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

Instance SSKY2 initiates the I/O with a write to disk request. 25.

Once the I/O operation is complete, instance SSKY2 logs the fact that such an operation
has been completed and a block written record (BWR) is placed in the redo log buffer. This
activity advances the checkpoint, which in turn forces a log write and prevents redo prior
to this point to be used for recovery purposes.

26.

■ during a database recovery operation, the recovery process uses the BWr to validate if the redo information for
the block prior to this point is needed.

Note

Instance SSKY2 informs the GCS of the successful completion of the write operation. This
notification also informs the GCS of the current resource status of the block and that the
resource is going to a local role because the DBWR has written the current image to disk.

27.

28. On receipt of the write notification, the GCS sends a message to all instances holding a PI

instructing them to flush the PI. After completion of this process or if no PI remains, the
instance holding the current exclusive resource is asked to switch to the local role. In the
scenarios discussed previously, SSKY1 and SSKY2 are the two instances holding a PI. When
instance SSKY2 receives a flush request from the GCS, it writes a BWR without flushing the
log buffer. Once this completes, instance SSKY2 will hold the block with an exclusive local
resource with no PIs, and all other PIs to this block held across various instances are purged.

After the dirty block has been written to disk, any subsequent operation will follow similar steps to complete any
requests from users. For example, if an instance requires read access to a block after the block has been written to
disk, the instance would check with the GCS and based on the instruction received from the GCS would retrieve the
block from disk or will retrieve it from another instance that currently has a copy of the block.
The write/write behavior and write to disk behavior are possible during a DML operation.
In all the scenarios it should be noted that, unless necessary, no write activity to the disk happens. Every activity
or state of the block was maintained as a resource in the instance where it was utilized last and reused a number of
times from this location.
It should also be noted whereas in the preceding illustrations, we have discussed block sharing from various
instances in the cluster, in a real world there could only be two possibilities.

Block Request Involving Two Instances or Two Hops
As discussed in the re-mastering section and subsequently in Step 1 (Figure 2-7 ), the resource master is maintained
on the instance where the demand for the object is the highest, meaning usually the requested block should be on the
instance that contains the resource master and the GRD for the resource.

1. In Figure 2-13 , the instance SSKY3 requires a row from a block 500 and sends a request to

the GCS of the resource.