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

Write to Disk Behavior
What happens when a block needs to be written to disk? Before we step into the mechanics of this, we recap the
current state of the environment:

SSKY4 continues to be the master of the resource and holds the GRD for the block. • Instance

SSKY1 had once modified the block and currently holds the block with SCN 10010,
having a global null resource and a PI.

• Instance

SSKY2 also contains a modified copy of the block with SCN 10016. The current status
of the block held by instance SSKY2 is in exclusive resource mode. This instance also holds a PI.

• Instance

SSKY3 holds the latest consistent read image version of the block (in shared global
mode) received from instance SSKY2 , which means it is a copy of a block held by instance
SSKY2 .

• Instance

• The disk contains the original block SCN 9996.

What could cause a write activity in a RAC environment? Transactional behavior in a RAC environment is no
different when compared to a single-instance configuration. All normal rules of single instance, “flushing dirty blocks
to disk,” apply in this situation also. For example, writing to disk could happen under the following circumstances:

• The number of dirty buffers reaches a threshold value . This value is reached when there is not
sufficient room in the database buffer cache for more data. In this situation, Oracle writes the
dirty buffers to disk, freeing up space for new data.

• A process is unable to find free buffers in the database buffer cache while scanning for blocks .
When a process reads data from the disk and does not find any free space in the buffer, it
triggers the least recently used data in the buffer cache (dirty buffer) to be pushed down the
stack and finally written to disk.
• A timeout occurs . A timeout is configured by setting the required timeout interval ( LOG_
CHECKPOINT_TIMEOUT ) through a parameter defined in the parameter file. On every preset
interval, the timeout is triggered to cause the database writer (DBWR) to write the dirty buffers
to disk. In an ideal system, where the data is modified but not immediately written to disk
(due to not having sufficient activity that would cause other mechanisms to trigger the write
operation), this parameter is helpful.
• The checkpoint process . During a predefined interval defined by LOG_CHECKPOINT_INTERVAL
or FAST_START_MTTR_TARGET parameter, when the CKPT process is triggered, it causes the DBWR
and log writer ( LGWR ) processes to write the data from their respective buffer cache to disk. If
neither of these parameters is defined, the automatic check pointing is enabled.

In a RAC environment, any participating instance could trigger a write request.
Figure 2-12 illustrates the various steps involved during a write to disk activity. In the current scenario, instances
SSKY1 and SSKY2 have a modified version of the block and are different from the version on disk.