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

gc remaster
This wait indicates the delay encountered when remastering the resource master from one instance to another
instance in the cluster. RAC architecture allows for dynamic remastering from a less busy instance to an instance
where the demand for the object is the highest. This movement is called resource affinity.
Apart from remastering based on demand, remastering also happens when an instance leaves (failure) or joins
the clustered configuration. During instance failure, remastering may happen more than once, first to place the master
dynamically on one of the surviving nodes and second, once the cluster has reached a stable state to reassess the
situation and remaster is again based on demand. Monitoring the remastering activity was discussed in Chapter 13.
wait for master SCN
Each instance in the cluster will generate its own SCN and subsequently, using the propagation method,
will resynchronize to the highest SCN in the cluster.
This wait indicates the number of times the foreground processes waited for SCNs to be acknowledged from
other instances in the cluster.
Before Oracle database 10g Release 2, the method of SCN propagation was driven by the parameter
MAX_COMMIT_PROPAGATION_DELAY . Setting this to a value higher than zero uses the Lamport algorithm. Now this
parameter is deprecated and is maintained for backward compatibility only and defaults to zero. This functionality
is now driven by the underscore (hidden) parameter _IMMEDIATE_COMMIT_PROPAGATION 13 and has a Boolean value of
TRUE or FALSE .
When the value of the parameter is set to TRUE (default) Oracle uses the “Block on Commit” (BOC) algorithm for
messaging. Although the method of propagation remains similar to the Lamport algorithm, in the case of BOC, the
global high water mark for the SCNs sent and received is maintained, thereby reducing messaging traffic for global
SCN synchronization and in turn improving overall performance.
gc cr/current request
This event indicates the time waited when a session is looking for a CR version of a block and cannot find it in its local
cache and so has made a request to a remote instance for the block. However, the transferred block has not yet arrived
at the requesting instance. The event ends when the requesting session gets the block or permission to read the block
from disk. This is normally a placeholder event, and the times here are cumulative of wait times for all other wait
events that had an impact on the operations. Placeholder wait events are transient (illustrated in Figure 17-5 ) and are
part of every view that captures active wait information.
gc current/cr block busy
This wait indicates that a current or CR block was requested and received but was not sent immediately by LMSn
because some special condition that delayed the sending was found. Wait times for these events are dominated by
block flush times (log file sync) and the defer time for the current blocks. Increased wait times are indications of high
concurrency and block contention and are caused by high I/O and overall system load.
Querying GV$INSTANCE_CACHE_TRANSFER view would help determine instances involved in high current and
CR block activity. Reducing log file sync times by monitoring the LGWR I/O and DBWR latencies would also help in
determining some of the performance bottlenecks that are causes for high wait times.
At the database level, tuning SQL statements by using sparse blocks, sequence number ranges, or by hash
partitioned indexes would help improve wait times.
13 Underscore parameters should be modified only after consulting with Oracle support.