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

 

Leave a Reply

Your email address will not be published. Required fields are marked *