189 8069 5689
本篇内容介绍了“Oracle RAC DRM中怎么关闭DRM”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
创新互联公司主要从事成都网站建设、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务廊坊,十多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108
查看DRM默认值
SQL>
SELECT x.ksppinm as name,
y.ksppstvl as value,
y.ksppstdf as isdefault,
x.ksppdesc describ
FROM SYS.x$ksppi x, SYS.x$ksppcv y
WHERE x.inst_id = USERENV('Instance')
AND y.inst_id = USERENV('Instance')
AND x.indx = y.indx
AND x.ksppinm in ('_gc_policy_time', '_gc_undo_affinity');NAMEVALUEISDEFAULTDESCRIB
1_gc_undo_affinityTRUETRUEif TRUE, enable dynamic undo affinity
2_gc_policy_time10 TRUEhow often to make object policy decisions in minutes
关闭方法：需要停掉所有实例，才能启动实例
SQL> alter system set "_gc_policy_time"=0 scope=spfile sid='*'; SQL> alter system set "_gc_undo_affinity"=FALSE scope=spfile sid='*';
[oracle@rac01 ~]$ srvctl stop database -d cjcdb [oracle@rac01 ~]$ srvctl start database -d cjcdb [oracle@rac01 ~]$ srvctl status database -d cjcdb -v Instance cjcdb1 is running on node rac01. Instance status: Open. Instance cjcdb2 is running on node rac02. Instance status: Open.
查看修改后的值
SELECT x.ksppinm as name,
y.ksppstvl as value,
y.ksppstdf as isdefault,
x.ksppdesc describ
FROM SYS.x$ksppi x, SYS.x$ksppcv y
WHERE x.inst_id = USERENV('Instance')
AND y.inst_id = USERENV('Instance')
AND x.indx = y.indx
AND x.ksppinm in ('_gc_policy_time', '_gc_undo_affinity');NAMEVALUEISDEFAULTDESCRIB
1_gc_undo_affinityFALSEFALSEif TRUE, enable dynamic undo affinity
2_gc_policy_time0FALSEhow often to make object policy decisions in minutes
如果修改完参数，只想重启其中一个实例，会报错ORA-01105和ORA-01606
---cjcdb1
SQL> alter system set "_gc_policy_time"=0 scope=spfile sid='*'; SQL> alter system set "_gc_undo_affinity"=FALSE scope=spfile sid='*'; SQL> shutdown immediate SQL> startup ORACLE instance started. Total System Global Area 1023004672 bytes Fixed Size 2259640 bytes Variable Size 704644424 bytes Database Buffers 310378496 bytes Redo Buffers 5722112 bytes ORA-01105: mount is incompatible with mounts by other instances ORA-01606: parameter not identical to that of another mounted instance
此时,重启节点2后，节点1也可以启动了
---cjcdb2
SQL> shutdown immediate SQL> startup
---cjcdb1
SQL> shutdown immediate SQL> alter database mount; SQL> alter database open; [oracle@rac01 ~]$ srvctl status database -d cjcdb -v Instance cjcdb1 is running on node rac01. Instance status: Open. Instance cjcdb2 is running on node rac02. Instance status: Open.
如果想只关闭其中一个节点的DRM，显然是和DRM原理冲突的，此方法也是行不通的。
SQL> alter system set "_gc_policy_time"=10 scope=spfile sid='cjcdb1'; SQL> alter system set "_gc_undo_affinity"=TRUE scope=spfile sid='cjcdb1'; [oracle@rac01 ~]$ srvctl stop instance -d cjcdb -i cjcdb1 -o immediate [oracle@rac01 ~]$ srvctl start instance -d cjcdb -i cjcdb1 -o open PRCR-1013 : Failed to start resource ora.cjcdb.db PRCR-1064 : Failed to start resource ora.cjcdb.db on node rac01 CRS-5017: The resource action "ora.cjcdb.db start" encountered the following error: ORA-01105: mount is incompatible with mounts by other instances ORA-01606: parameter not identical to that of another mounted instance . For details refer to "(:CLSN00107:)" in "/u01/app/11.2.0/grid/log/rac01/agent/crsd/oraagent_oracle/oraagent_oracle.log". CRS-2674: Start of 'ora.cjcdb.db' on 'rac01' failed
DRM原理
https://blogs.oracle.com/database4cn/drm
首先，我们对和DRM 相关的一些概念进行介绍。
Buffer: 对于RAC 数据库，当一个数据块被读入到buffer cache后，我们就称其为buffer , cache fusion 会将这个buffer作为resource来管理。 Master：在RAC 数据库的世界里，每一个resource都会有一个master实例，这个master实例会在shared pool 中（例如：gcs resource 和ges resource 部分）分配一些空间来存放和这个资源相关的信息，例如：哪一个实例拥有了这个buffer的最新版本，哪一个实例拥有了这个buffer的什么级别的lock等等。并且，负责维护和这个资源的状态。 接下来，我们对RAC 环境中，访问一个buffer的过程进行简单的描述。我们以一个4节点的RAC 数据库为例。注意，我们只会列出比较典型的一种情况，不会把所有可能的情况都一一列出，而且只是把步骤进行了简单的介绍。
步骤1：实例3需要以X(exclusive)方式访问buffer1, 向master实例（1） 发出了请求。 步骤2：master实例（1）发现实例2 以X方式持有buffer1，之后通知实例2释放X lock，并把buffer1发送给实例3。 步骤3: 实例2释放X lock，并把最新版本的buffer1发送给实例3。 步骤4：实例3获得buffer1, 并通知master 实例（1）更新资源buffer1的最新状态。
从上面的步骤，我们不难看出，在RAC 数据库中，当我们访问一个buffer的时候，最多会有3个实例参与其中，master实例，holder（持有者）实例 和requestor(申请者) 实例。2种数据传输会出现，message:用于和lock相关的信息传输，data：用于传输buffer。同时，根据上面的步骤我们也自然会想到，如果master和requestor在同一个实例上，那么就可以减少实例之间message的传输并且访问的代码路径（code path）会更短，从而提高性能，但是每个buffer在被读取到buffer cache时，master节点的选择是随机的。基于这种考虑， oracle从10g开始，推出了一个新特性DRM（Dynamic Resource management）。
DRM的主要功能是，根据一段时间内（默认10分钟），每个实例，对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式，来决定数据库对象对应的buffer应该被mastering 到哪一个实例。在指定时间内，如果某一个实例访问某个数据库对象次数高于其他实例一定倍数（默认50倍），则oracle 会把这个对象所有的buffer的master信息，转移到对应实例（注意：不是转移buffer）。当然，转移的过程是渐进式的。当oracle 决定将一个buffer的master实例确定到本地实例后，会对这个buffer上加上affinity lock，来实现快速的访问。这也是我们经常提到的object affinity 的由来。
接下来，我们对DRM的基本步骤进行介绍。
1． Oracle停止所有在需要进行remastering的buffer上的操作。注意：DRM是渐进的，也就是说以windows 为单位，每次对一部分的buffer 进行remastering 操作。 2． Lmon 通知所有实例，准备进行remastering 3． 在旧的master实例清除对应buffer的master信息 4． 将master信息传递给新的master实例 5． 在新的master实例构建资源的最新状态 6． 结束，并释放所有之前所有步骤占用的资源。
然后，我们对DRM相关的一些参数进行简单的介绍。
_gc_policy_time ：单位为分钟，控制DRM统计实例访问buffer次数的时间间隔，默认为是10分钟。
_gc_affinity_ratio：控制进行remastering所需要达到的最小比例（阀值），默认为50。也就是说，如果某个实例在10分钟（_gc_policy_time）之内，访问某个数据库对象的次数大于其他所有实例50倍时(注意：是50倍，而不是50次)，对该数据库对象的buffer进行remastering。
注意：请不要修改以上参数的值，除非您很清楚自己在做什么，或者是根据oracle 工程师的建议。
最后，如果您遇到了和DRM相关的问题，建议您查看以下的信息。
1. Lmon，lmd，lms和diag进程的 trace file，来确认问题出现在DRM的哪一步和lms,lmon,lmd进程的状态。 2. AWR 和ASH report，确认那些等待事件持续了很长时间，以及lmon,lms 和lmd的状态。 3. 参照note 1492990.1 获取 DMR 诊断脚本输出。
“Oracle RAC DRM中怎么关闭DRM”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！