MASTER_CNT
from dba_objects o, v$gcspfmaster_info m
where o.data_object_id=73181
and m.data_object_id = 73181 ; OBJECT CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT ―― ――――? ――――― ―――― EMP 0 32767 1 ? Use following SQL to show master and owner of the block. This SQL joins x$kjbl with x$le to retrieve resource name. ? Note that current master is node1(KJBLMASTER=0) and current owner of the block is node2(KJBLOWNER = 1)
SYS@NODE2> select kj.kjblname, kj.kjblname2, kj.kjblowner,
kj.kjblmaster
from (select kjblname, kjblname2, kjblowner,
kjblmaster, kjbllockp
from x$kjbl
where kjblname = '[0x97][0x4],[BL]'
) kj, x$le le
where le.le_kjbl = kj.kjbllockp
order by le.le_addr; KJBLNAME KJBLNAME2 KJBLOWNER KJBLMASTER ―――――――――― ―――――――――― ―――- ―――- [0x97][0x4],[BL] 151,4,BL 1 0 ? Manually master the EMP table to node2 ?
SYS@NODE2>oradebug lkdebug -m pkey 74625
? Check that the current master of the block has changed to node2 (numbering starts from 0) ? Previous master = 0 (Node1) ? REMASTER_CNT = 2 indicating the object has been remastered twice
SYS>select o.object_name, m.CURRENT_MASTER,
m.PREVIOUS_MASTER, m.REMASTER_CNT
from dba_objects o, v$gcspfmaster_info m
where o.data_object_id=74625
and m.data_object_id = 74625 ; OBJECT CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT ―― ――――? ――――― ―――― EMP 1 0 2 ? Find master and owner of the block. ? Note that current owner of the block is Node2 (KJBLOWNER=1) from where query was issued) ? current master of the block has been changed to node2 (KJBLMASTER=1)
SYS> select kj.kjblname, kj.kjblname2, kj.kjblowner,
kj.kjblmaster
from (select kjblname, kjblname2, kjblowner,
kjblmaster, kjbllockp
from x$kjbl
where kjblname = '[0x97][0x4],[BL]' ) kj, x$le le
where le.le_kjbl = kj.kjbllockp
order by le.le_addr; KJBLNAME KJBLNAME2 KJBLOWNER KJBLMASTER ―――――――――― ―――――――――― ―――- ―――- [0x97][0x4],[BL] 151,4,BL 1 1 ――――――――――――――――――――――――――――― ? REMASTERING DUE TO RESOURCE AFFINITY ?
GCS masters a buffer cache resource on the instance where it is mostly accessed. In order to determine whether dynamic remastering is necessary, the GCS essentially keeps track of the number of GCS requests on a per-instance and per-object basis. This means that if an instance, compared to another, is heavily accessing blocks from the same object, the GCS can take the decision to dynamically migrate all of that object’s resources to the instance that is accessing the object most. X$object_policy_statistics maintains the statistics about objects and OPENs on those objects.LCK0 process maintains these object affinity statistics. Following parameters affect dynamic remastering due to resource affinity : _gc_policy_limit : If an instance opens 50 more opens on an object then the other instance (controlled by _gc_policy_limit parameter), then that object is a candidate for remastering. That object is queued and LMD0 reads the queue and initiates GRD freeze. LMON performs reconfiguration of buffer cache locks working with LMS processes. All these are visible in LMD0/LMON trace files. _gc_policy_time : It controls how often the queue is checked to see if the remastering must be triggered or not with a default value of 10 minutes. _gc_policy_minimum: This parameter is defined as “minimum amount of dynamic affinity activity per minute” to be a candidate for remastering. Defaults to 2500 and I think, it is lower in a busy environment. To disable DRM completely, set _gc_policy_limit and _gc_policy_minimum to much higher value, say 10Mi