Database Reference
In-Depth Information
Global Cache and Enqueue Services - Workload Characteristics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg global enqueue get time (ms) : 16.8
Avg global cache cr block receive time (ms) : 17.1
Avg global cache current block receive time (ms): 14.9
Parameters
There are a few underscore parameters controlling the behavior of DRM activity. Parameter _gc_policy_minimum
decides the minimum gc activity per minute of an object to be considered for resource mastering (default value,
1,500). Parameter _gc_policy_time governs the duration of an observation window (default value, 10 minutes). During
the observation window, objects are observed, objects exceeding a minimum threshold are considered for resource
mastering, and DRM is triggered.
There are many other underscore parameters controlling the behavior, and those parameters usually start with
_lm_drm_ and do not normally need any adjustments. However, if you find that DRM activity is slower, it is possible
to tune DRM speed using these parameters, but you must contact Oracle Support before changing these initialization
parameters.
If your database performance suffers from excessive amount of DRM activity, you can tune that by
adjusting
_gc_policy_minimum
parameter to a much higher value, such as 1 million. While DRM can be disabled
by adjusting _gc_policy_time to zero, this choice disallows manual remastering too. So, the preferred action is to
increase
_gc_policy_minimum
to a bigger value.
Changes in 12c
DRM has slight changes in release 12c, mostly for the PDB feature. Every PDB generates its own object_ids, and so
pkey format has been changed to accommodate plugged-in databases. For example, remastering of an object with
object_id=89911 uses pkey including con_id of plugged-in database. A snippet from LMD trace file follows.
*** 2013-03-17 21:57:49.718
Rcvd DRM(3) AFFINITY Transfer pkey 4.4.89911 to 1 oscan 1.1
ftd (30) received from node 1 (4 0.0/0.0)
all ftds received
In this example, pkey is 4.4.89911, where the first 4 is con_id of the object, my guess is that the second 4 is also
a container_id, and 89911 is the object_id of the object. You can query v$container or cdb_pdbs to identify the
plugged-in database of this object.
DRM and Undo
Undo segments also can be remastered. In RAC, every instance has its own undo tablespace. For example, if
undo_tablespace parameter is set to undots1, then all undo segments onlined in instance 1 will be allocated in
undots1 tablespace. So, by default, an instance onlining an undo segment will also be the resource master for that
segment. But, if another instance accesses an undo segment excessively, then resource mastership for an undo
segment can be remastered to another instance.
LMD0 trace file will show an object_id exceeding 4 billion. Here is an example of an undo remastering event:
Begin DRM(104) - transfer pkey 4294951403 to 1 oscan 0.0*** 2011-08-19
