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

DISK_READ_RESULTS indicates the number of times the instance had to read the requested
block from disk because the block was not found in the local buffer, nor was it found in
the buffer of another instance. Significantly high numbers in this column could indicate
insufficient sizing of the buffer cache and the shared pool.
This means that the master sent a cr request to an instance in which it believes the
requested data is cached. However, when the message arrives at that instance, the data
block is no longer in the cache. The LMS returns a disk read status. Such a scenario is a
rare case and mostly caused by a race condition. This could also be due to an undersized
buffer cache.
CR_REQUESTS and CURRENT_REQUESTS together amount to the total number of requests that
the instance had received. It helps to determine the overall load of the instances.
DATA_REQUESTS , UNDO_REQUESTS , and TX_REQUEST together indicate the amount of blocks
processed by the LMS process; it gives pointers on how busy the LMS is and if the number
of LMS processes should be increased or not. DATA stands for data or index blocks, UNDO
indicates undo blocks, and TX indicates undo segment headers.
FAIRNESS_DOWN_CONVERTS indicates the number of times a data block was requested for
modifications and the LMS had granted an exclusive lock. However, if the block was not
modified, the lock had to be down-converted.
The number of times a block that was modified in the past received a consistent read
request before it is down-converted to S to avoid frequent block reads via the interconnect.
The idea is that there a more reads than writes, and therefore the block should not be held
in X mode for too long.
LIGHT_WORKS is the number of times the light-work rule was evoked. This rule prevents
the LMS processes from going to disk or forwarding messages to another instance while
responding to CR requests for data, undo, or undo segment header blocks.
The LMS could not find the block that was requested in the local cache nor could it be constructed (in the case of
cr copies) from local information. That is, when serving blocks, LMS must not be slowed down by reading from disk or
requesting data from another instance, which would be too complex and suboptimal. In such a case, the LMS would
return an appropriate status to the requester. The requester then reads the data from disk and rolls back.
SQL> desc GV$CR_BLOCK_SERVER
Name Null? Type
------------------------ -------- ------------
INST_ID NUMBER
CR_REQUESTS NUMBER
CURRENT_REQUESTS NUMBER
DATA_REQUESTS NUMBER
UNDO_REQUESTS NUMBER
TX_REQUESTS NUMBER
OTHER_REQUESTS NUMBER
CURRENT_RESULTS NUMBER
PRIVATE_RESULTS NUMBER
ZERO_RESULTS NUMBER
DISK_READ_RESULTS NUMBER
FAIL_RESULTS NUMBER
STALE NUMBER
FAIRNESS_DOWN_CONVERTS NUMBER