Tuning Global Cache - Expert Oracle RAC Performance Diagnostics and Tuning - page 406

CPU usage. Monitoring the priority setting of the LMS background processes indicated they are running at the correct
priority levels.
The LMS does not wait for a log flush unless there is nothing else to do and a log flush is pending. The LMS keeps
processing arriving messages, and each time it completes a request, it checks if the log flush queue for any completed
operations. In the scenario discussed previously, the log flush by LGWR took a long time delaying the sending of data
that was on the log flush queue. These delays are usually in the order of magnitude of an I/O while an immediate
block send would complete in a few microseconds.

Mastering and Remastering
Based on the access to the data of a specific object, the global state of the object is maintained (aka mastered) on the
instance that uses it more than other instances. For example, if instance SSKY1 was accessing an object A1, and data
from the object was read in about 1,500 user requests all connected to instance SSKY1 , and say instance SSKY2 also
required access to object A1 for 100 users. It's obvious that SSKY1 has more users accessing this object A1. Hence,
instance SSKY1 would be elected as the resource master for this object. When another instance, for example, SSKY2 ,
needs to access data in an object mastered on SSKY1 , it will coordinate with the GCS and the GRD on instance SSKY1 .
If the usage pattern changes, for example, the number of logical reads on instance SSKY2 increases due to 2,000 user
requests and on SSKY1 it drops to 500 causing reads from disk. The global cache would monitor and detect the current
usage pattern and transfer the mastering of the object via the interconnect to instance SSKY2 . This entire process of
remastering serves the purpose of supporting object affinity . In other words, object affinity implies the use of dynamic
resource remastering to move the location of the resource masters for the database object (e.g., table, index, partition) to
the instance where block operations are most frequently occurring .

■ if blocks from an object move around frequently between instances, but most accesses are on SSKY2 , affinity
will not kick in. it will only kick in when most of the OPENS are from SSKY2 (i.e., reads from disk).

Note

Object affinity optimizes the system in situations where update transactions are being executed on one instance.
If activity is not localized, the resource ownership is distributed to the instances equitably on the basis of data block
addresses. Whereas remastering is based on the number of times the object is touched in a particular instance, the
requirement is that it has read 1,500 times more than the other instance in a period of approximately 10 minutes.
The touch count logic for remastering and the maximum period before remastering occurs is tunable using the
underscore parameters 5 _GC_POLICY_MINIMUM and _GC_POLICY_TIME . 6
Figure 13-9 illustrates resource distribution in a four-node cluster. That is, instances SSKY1 , SSKY2 , SSKY3 , and
SSKY4 are mastering resources R1, R2, R3, R4, R5, R6, and R7, respectively.

5 Underscore parameters should be modified only after consultation with Oracle support.
6 In previous versions of Oracle, this was based on parameters _GC_AFFINITY_MINIMUM and _GC_AFFINITY_TIME .