RAC DRM

资源主节点

由于资源可能出现在多个节点里面,一个数据库里面有多个节点,资源可能在每一个节点都出现,但是不能将资源相关的使用信息和锁的信息在每一个节点都存放,这样会导致资源的浪费并且还不能保持一致性。一般资源的信息只存放在一个节点之上,对于某一个具体的资源存放它的使用信息,锁信息,状态信息的这个节点称为资源主节点。保存资源的定义及相关的锁信息的节点。

 

ORACLE RAC DYNAMIC REMASTERING 

DRM的引⼊
在传统的资源访问过程中,资源主节点在第⼀次确认后不再改变,在正常的情况下,对于N个节点的RAC数据库,只有1/N的资源可以在本地节点访问, n-1/n的资源需要到远程节点访问;如果最初确定的资源主节点对于资源访问远⼩于其他节点,更会加重节点间的交互。给性能带来严重的影响。这样就 引入了DRM来解决这个问题。

DRM定义 

PCM资源的主节点,能够根据资源在各个节点的访问情况图动态地调整

 

 

DRM相关参数 

  1. gc_policy_time:指定了Oracle搜集每个节点对某个数据库对象的访问次数的时间间隔
  2.  gc_policy_minimum:指定了每分钟数据库对象⾄少要被访问多少次,才能考虑修改它的主节点信
  3. gc_affinity_ratio:只有当⼀个节点访问某⼀个数据库对象的次数超过了其他所有节点访问相同的数据库对象的多少倍时,才考虑修改对象的主节点。

 

DRM的实现过程
主节点迁移过程
1、静默阶段: LMON进程通知LMS进程不再接受对相关资源的新的操作请求
2、冻结阶段:对所有要进⾏DRM的数据块进⾏冻结
3、清除阶段:清除旧的主节点信息
4、重建阶段:所有实例将对应数据块的锁信息发送⾄新的资源主节点
5、解冻阶段:完成交接后,结束过程

 

READ MOSTLY - DRM 的延伸

背景:
对于⼀些查询操作占主要的数据块,在正常的RAC访问机制下,需要不断访问资源主节点,消耗不
必要的资源。
实现⽅式

LCK0对数据块的访问⽅式进⾏记录,如果发现某些数据库对象在某⼀段时间内被访问的操作都是读操作,在锁的信息上体现为S的PCM锁,并且访问这些数据库对象经常发⽣实例间通信的话,那么会给这些数据库对象加上read mostly的标志,并且预先对每⼀个节点都赋予对这些数据库对象的读权限。

适⽤场景
1、数据库对象绝⼤部分操作都是读,极少进⾏修改操作; 

2、如果访问该数据库对象,出现⼤量的gc cr grant 2 way和gc current block 2-way和gc current block 3-way等待事件时,那么这个数据库对象适⽤read mostly

DRM对性能的影响
DRM的影响
在DRM的冻结过程中,对应资源的访问请求会被挂起,很可能出现异常,触发bug修改数据IO过⼤;
Read mostly 影响

修改数据IO过⼤;
过渡时期;

 

 

 _gc_policy_time - RAC集群中的DRM管理

 

DRM是 Dynamic Resource Management 的简称,意思就是动态资源管理。在Oracle RAC中,所有的数据块(Data block)都有一个实例作为主实例进行管理,叫做Master,Master 负责照看好自己所管辖的data block的状态,包括锁定等,并对跨实例访问进行授权。

 

如果能随着数据块的访问频繁动态的修改数据块的master节点,那么对应GC的grant message则会大量的减少。基于以上考虑,DRM特性应运而生。但是早期的DRM在进行 re-master的过程中长长带来短时的性能影响,在很多重要环境中,这是不能忍受的。

 

如果希望关闭DRM这个特性,可以结合设置 _gc_policy_time 和  _gc_undo_affinity :

alter system set "_gc_policy_time" = 0 scope=spfile;

alter system set "_gc_undo_affinity" = false scope=spfile;

猜你喜欢

转载自blog.csdn.net/qq_34556414/article/details/81749791
今日推荐