Waits, Enqueues, and Latches - Expert Oracle RAC Performance Diagnostics and Tuning - page 601

• Misconfigured jumbo frames

• NIC force full duplex and duplex mode mismatch

• Flow control mismatch in the interconnect communication path

• Packet drop at the O/S, NIC, or switch layer

• NIC driver/firmware configuration

• NIC send and receive queue lengths

• High CPU usage and scheduling latencies

gc current retry
A current block was requested; however, the requested block was not received due to a failure status either because
the block was corrupted or the block was lost during transmission over the interconnect. Reasons for the failure to
receive the block could be one or many of the reasons listed previously under the “gc current/cr blocks lost” event.

gc cr failure
This is similar to the gc current retry wait event, but in this case, “cr” block was requested. However, a failure status
was received either because the block was corrupted or the block was lost during transmission over the interconnect.
Reasons for the failure to receive the block could be one or many of the reasons listed previously under the “gc
current/cr blocks lost” event.

Mutex Waits
Mutex waits refers to waits resources associated with the management of cursor objects in the shared pool during
parsing. Mutex is a type of latch and was introduced with Oracle Database 10g Release 2. Similar to latches and other
type of waits, these are excessive waits causing contention and performance problems in Oracle database systems.
Mutex contention is normally a CPU-using resource; and high mutex-related contention can cause excessive
CPU usage and impact user response times. Mutexes are local to the instance in a RAC environment. Mutex waits are
characterized by sessions waiting for one or more of the following events:

•

cursor: mutex X —Cursor is being parsed and is trying to get the cursor mutex in
exclusive mode.

• c

ursor: mutex S —Cursor is parsed and is trying to get the cursor mutex in share mode.

•

cursor: pin S —Cursor is being parsed and trying to get the cursor pin in shared mode.
There are currently no concurrent X holders, but the cursor could not acquire the mutex
immediately. The wait time indicates the sessions have to increment the mutex reference
count and requires performing an exclusive atomic update to the mutex structure.

•

cursor: pin X —Cursor is being parsed and trying to get the cursor pin in exclusive mode.

•

cursor: pin S wait on X —Cursor is being parsed and has the cursor pin and is trying to get
the mutex in shared mode; however, another session is currently holding the same mutex in
exclusive mode. The session continues to wait for the current holder to release the mutex.