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.