官方文档描述
14.9.4 Analyzing Cache Fusion Transfer Impact Using GCS Statistics
Describes how to monitor GCS performance by identifying objects read and modified frequently and the service times imposed by the remote access.
Waiting for blocks to arrive may constitute a significant portion of the response time, in the same way that reading from disk could increase the block access delays, only that cache fusion transfers are usually faster than disk access latencies.
The following wait events indicate that the remotely cached blocks were shipped to the local instance without having been busy, pinned or requiring a log flush:
* gc current block 2-way
* gc current block 3-way
* gc cr block 2-way
* gc cr block 3-way
The object statistics for gc current blocks received and gc cr blocks received enable quick identification of the indexes and tables which are shared by the active instances. As mentioned earlier, creating an ADDM analysis will usually point you to the SQL statements and database objects that could be impacted by inter-instance contention.
Any increases in the average wait times for the events mentioned in the preceding list could be caused by the following occurrences:
* High load: CPU shortages, long run queues, scheduling delays
* Misconfiguration: using public instead of private interconnect for message and block traffic
If the average wait times are acceptable and no interconnect or load issues can be diagnosed, then the accumulated time waited can usually be attributed to a few SQL statements which need to be tuned to minimize the number of blocks accessed.
The column CLUSTER_WAIT_TIME in V$SQLAREA represents the wait time incurred by individual SQL statements for global cache events and will identify the SQL which may need to be tuned.
14.9.5.1 Block-Related Wait Events
The main wait events for block-related waits are:
* gc current block 2-way
* gc current block 3-way
* gc cr block 2-way
* gc cr block 3-way
The block-related wait event statistics indicate that a block was received as either the result of a 2-way or a 3-way message, that is, the block was sent from either the resource master requiring 1 message and 1 transfer, or was forwarded to a third node from which it was sent, requiring 2 messages and 1 block transfer.
2-way/3-way：该块是从需要1条消息和1次传输的资源主节点发送的，或者是转发到发送该块的第三个节点，需要2条消息和1次块传输。
3-way只发生在3个以及3个以上实例
block n
master node 主节点
request node 请求节点
Holding node 持有节点
两节点rac，只有持有节点与请求节点不在一个实例，才会发生gc block传输。
对于Block层面的Masters主要用于Cache Fusion。任何节点都可以成为特定Block的Master Node，可以通过V$GES_RESOURCE中的MASTER_NODE列查询。
