Oracle RAC is a pool of servers interconnected each other and acts as a single server. It provides scalability, Robustness, availability, and load-balancing. In a cluster, communication between nodes is very important, so monitoring the inter communication is very crucial, and it helps to bring down the response time and service availability to end-users.

What to Monitor in a cluster?
As an Oracle DBA, we always see different RAC related events in databases but we need to make sure those events not causing any communication latency.  In this article, I gathered information on different wait events, and their impact.

RAC events:

— GCS events (gc current block received, gc cr blocks received, gc current block 3-way, gc cr grant 2-wayt etc.).
— GES events (ges remote message, ges message buffers etc)

We can see the events in these views:

Gv$system_event
gv$session_event
gv$active_session_history
gv$waitstat
gv$session_wait

Type of events:

Block-Related Wait Events
Message-Related Wait Events
Contention-Related Wait Events
Load-Related Wait Events

Block Related wait events:

gc current block 2-way
gc current block 3-way
gc cr block 2-way
gc cr block 3-way

Message-Related Wait Events

gc current grant 2-way
gc cr grant 2-way

The message-related wait event statistics indicate that no block was received because it was not cached in any instance.
Instead a global grant was given, enabling the requesting instance to read the block from disk or modify it.

Contention-Related Wait Events

gc current block busy
gc cr block busy
gc buffer busy acquire/release

Load-Related Wait Events

gc current block congested
gc cr block congested

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.