Waits, Enqueues, and Latches - Expert Oracle RAC Performance Diagnostics and Tuning - page 599

DeFer tIMe
When a current block is requested, LMs may defer the shipping of the block to the requestor if the cleanout of the
block is pending. this defer time maybe as high 30 ms or the value specified by the GC_DEFER_TIME parameter.
the default value of this parameter is 3 milliseconds.
the hidden parameter _GC_DEFER_TIME defines the time that a LMs process grants to a user process to complete
the transaction before starting to down-convert the lock and sending the block to a requestor on another instance.
gc current/cr grant
This wait indicates that the block access grant was received. However, the block was not present on the local instance
of the requestor. The wait time only indicates the time to provide access from the remote instance or read the block
from disk.
High wait times would indicate network transfer speed and bandwidth, high context switching at the O/S level
of the instances involved in the transfer, and overall load on the servers. Tuning SQL statements to reduce high buffer
activity due to high LIO would help reduce wait times for this event.
gc current grant busy
This wait indicates that a current block was requested and a grant message received. The busy hint implies that the
request was blocked because others were ahead of it or it could not be handled immediately. This normally occurs
when the current block is shared by several instances, and the requestor is waiting for exclusive access to this block.
All holders of the block would have to release this block before exclusive access (S to X conversion) can be granted to
the requestor.
High wait times on this event would indicate tuning SQL statements and database objects involved in frequent
block activity (hot blocks) should be monitored. Almost always environments where multiple instances are inserting
rows (highly insert intensive batch loads) could cause index block splits and could be the primary reason for high wait
times for this event.
gc current/cr multiblock request
Oracle is attempting to read multiple blocks into one message to save on CPU. This read process may include either
grants or blocks. These requests are usually caused by a full table scan or index full scan. If the request involves
“current” blocks, the space management layer would setup multiblock requests when viewing blocks with contiguous
data block addresses.
Multiblock requests normally don't cause any additional performance issues unless there are transmission issues
over the interconnect and blocks are lost. In that case, there would be performance degradation, followed by gc cr
failure and cr request retry activities.
gc current/cr lost blocks
Data is transferred over the interconnect; however, the data does not reach the target server, but the data was lost
during transmission. When blocks are lost or corrupt over the interconnect, the GCS process will retransmit the
block to the requestor; this would mean the requestor would wait for a longer duration until such time as the block
is received.