Tuning the Cluster Interconnect - Expert Oracle RAC Performance Diagnostics and Tuning - page 462

Every instance in the cluster has a pool of tickets allocated to it during instance startup. The number of tickets
that an instance is allocated depends on the amount of buffer assigned at the O/S level, using the parameters we
discussed earlier. At the database level, Oracle controls the total number of tickets available using the parameter
_lm_tickets 6 and _cgs_tickets 7 for RAC-related messages. Both these parameters default to 1,000. When a message
needs to be sent, the process needs to acquire a ticket from the pool and return the ticket back to the pool once the
message has been transmitted. When there is a message flooding, there may not be a sufficient amount of tickets in
the pool, and the process requesting the ticket will have to wait for the ticket. The allocation and usage of tickets can
be verified in the view V$DLM_TRAFFIC_CONTROLLER:
Script:MVRACPDnTap_dlmtrafficntrl.sql
SELECT inst_id INT,
local_nid LNID,
remote_nid RNID,
remote_rid RRID,
remote_inc RINC,
tckt_avail,
tckt_limit,
tckt_rcvd,
tckt_wait,
snd_seq_no,
snd_q_len,
snd_q_max,
snd_q_tot,
snd_q_tm_base,
snd_q_tm_wrap
FROM gv$dlm_traffic_controller
ORDER BY inst_id,
tckt_avail;
In the output, there are few processes that have the TCKT_WAIT(wait) columns that say YES . This indicates
that the pool has run out of tickets. When several processes go into the wait state, it could cause GCS to hang. It is
important to monitor the ticket usage and ensure that there are enough tickets available, which is indicated in the
TCKT_AVAIL column.
6 Underscore parameters should be modified only with consent from Oracle support.
7 Underscore parameters should be modified only with consent from Oracle Support.