RAC Wait Events Summary

GC Current Block 2-Way/3-Way

• For a Current Block in read mode a KPJUERPR ( Protected Read ) lock is requested
• Wait event can occur for READ and WRITE activities
• If accessing a locally mastered block on the local instance no GCS lock is needed ( FG can access this block without any GCS support – Affinity locking )
• Excessive waits for gc current block are either related to inefficient QEP leading to nummerous block visits or application affinity not being in play

GC CR  Block 2-Way/3-Way ( for detail please read follwing article )

• CR block transfers are requested for Read Only access and are specific to a certain session and SQL statment
• Next execution of same statement will again trigger this wait event as SCN is increased and CR block needs to be refreshed
•  No locks are maintained by GCS for CR blocks
• Long-pending transaction on highly accessed objects can lead to CR storm ( Run this sort of transactions at a less busy timeframe )

GC CR Grant 2-Way/GC Current Grant 2-Way

• If a block is not resident in any buffer cache  LMS grants the FG process to read the block from disk
• Excessive waits for gc cr/current 2-way wait event can be caused by a undersize buffer cache or SQL stmt flushing the buffer cache
• This sort of messages can be used to measure your Network performance as very less pressing is done for this event

GC CR Block Busy/GC Current Block Busy

 

•  LMS performed add work due to concurrency-related issues ( like build a CR block and apply UNDO to reconstruct a block with query SCN )

GC CR Block Congested/GC Current Block Congested

• if LMS process did not process a request within 1ms than LMS marks the response to that block with the congestion wait event
• Root cause: LMS is suffering CPU scheduling, LMS is suffering resources like memory ( paging )
• As LMS processes are RT processes OS scheduling delays should be minimal

GC current request/GC CR request

• These are placeholder requests which should which should be mapped to one of the above wait events once the LMS responds
• If there is no response in 0.5s from LMS ( 6s on windows ) the acoounted time is added to GC Lost Block wait event

GC Log Flush Sync

• for details please  read following link..
• in a healthy database 90 % of GCS Log flush Sync requet should be finished in 2ms or less
• Always check related instances for LOG FILE SYNC waiut event as this event also reduces the available Redo I/O bandwith 
• Monitor Wait distribution/histogramms  with following script : @event_histogram_from_awr.sql

 

GC Current Block Busy/GC CR block busy

• Busy events indicate that LMS needs to perform add. work before sending a block ( like apply Redo to build CR block )

GC Buffer Busy Acquire/Release

• For RHS index growth you see GC Buffer Busy Acquire/Release and GC Buffer Busy events and gc current request for the same block
• If the block is on instance 1 all other sessions from instance 1 are waiting on gc buffer busy aquire whereas sessions on the other instances are waiting on gc buffer busy release
• Always monitor GV$session P1,P2,P3 to get detail information about what blocks are used