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

It's to be noted that although there are multiple factors that can influence the remastering activity, no one reason,
such as the interconnect latency, can be the only cause for this delay. The data in the output following is an indication
of the overall activity of remaster operations and the time spent at various stages of the operation:
Script:MVRACPDnTap_Dynamicmastersats.sql
SELECT inst_id,
remaster_ops,
remaster_time,
remastered_objects,
quiesce_time,
freeze_time,
cleanup_time,
replayed_locks_sent,
replayed_locks_received,
current_objects
FROM gv$dynamic_remaster_stats
ORDER BY inst_id;
Remaster Remaster Remaster Quiesce Freeze Cleanup
Inst Operations Time Objects Time Time Time
---- ---------- -------- -------- -------- -------- --------
1 765 73676 872 7795 949 5433
2 765 73627 872 7799 765 5365
3 765 73652 872 7756 738 5216
4 10357 666977 12421 116083 12546 74389
5 765 73626 872 8365 778 4793
6 8387 539807 10168 122256 10538 44871
In the preceding output, instance 4 and 6 involve high remaster operations; and quite a bit of time is spent with
related operations. There are potentially volatile objects, and its affinity keeps shifting between the two instances.
The reasons for such high remastering could be two of many reasons: (1) Batch application performing high INSERT
operations causing block movement between instances; (2) Same database services configured on two instances
that access the same set of objects, but the load average keeps shifting between the two instances. If this is a read-
only application, this would be of less concern; however, if this is a highly volatile set of objects that involves high
DML operations, some additional tuning at the object level by distributing data using data partitioning should be
considered.
GV$DLM_TRAFFIC_CONTROLLER
Traffic controller manages the allocation of tickets to processes that need to send messages. The traffic controller
manages a pool of tickets allocated during instance startup and issues tickets to requests from processes sending
messages; once the messages are sent, the ticket is released back into the pool. If there is delay in message
communication and when tickets are not returned back to the pool, the pool may run out of tickets, and the processes
wait to get tickets. At this time, the messages wait in a flow control queue until outstanding messages have been
acknowledged and more tickets are available:
Script:MVRACPDnTap_dlmtrafficntrl.sql
SELECT inst_id INT,
local_nid LNID,
remote_nid RNID,