Database Reference
In-Depth Information
but always by the same instance. The following query against the GV$DYNAMIC_REMASTER_STATS 7 view gives the current
remaster activity:
SELECT INST_ID INT, REMASTER_OPS OPS,
REMASTER_TIME RT,
REMASTERED_OBJECTS RO,
CURRENT_OBJECTS CO,
SYNC_TIME ST
FROM GV$DYNAMIC_REMASTER_STATS
ORDER BY INST_ID;
INT OPS RT RO CO ST
---------- ---------- ---------- ---------- ---------- ----------
1 1152 97023 1870 232 47257
2 1151 97191 1869 1 55836
3 1151 97114 1869 2 54963
4 1152 97146 1870 2 58169
5 1151 97182 1869 3 57783
6 1151 97150 1869 21 31957
7 1151 97528 1869 21 70858
8 1151 97148 1869 36 34547
8 rows selected.
In the preceding output, REMASTER_OPS indicates the number of remaster operations completed this far;
REMASTER_TIME indicates the time spent on remaster activities; REMASTERED_OBJECTS indicates the number of objects
remastered; CURRENT_OBJECTS column indicates the number of objects mastered on the current instance and has not
been remastered; and SYNC_TIME indicates the amount of time spent in cache synchronization activities during the
remaster operation.
Note
all values in this view are cumulative, meaning they reflect the remastering activity since the instance started.
On a clustered configuration with more than two nodes, if there is significantly high number of three-way
wait events (numbers greater than two-way wait events), it would indicate there is a significant amount of data
sharing across all nodes in the cluster. In such cases, there is a high amount of gc cr/current two-way grants and the
remastering algorithm may not occur.
The statistics gc local/remote grants would also indicate whether locality of masters is effective or not. The goal is
to maximize local grants. Remastering statistics can also be viewed from the AWR report (illustrated in Figure 13-11 ).
GV$DYNAMIC_REMASTER_STATS is based on X$KJDRMAFNSTATS .
7
 
 
Search WWH ::




Custom Search