【深入解析】DRM和read-mostly locking

作者简介

何剑敏

Oracle ACS华南区售后团队,首席技术工程师。多年从事第一线的数据库运维工作,有丰富项目经验、维护经验和调优经验,专注于数据库的整体运维。

1了解DRM(Dynamic Resource Remastering)

讲DRM(Dynamic Resource Remastering),首先一定说说cache fusion的机制,cache fusion是在8i OPS中引入,解决的目的是原来在OPS中,instance A读某个block,instance B也要读时,instance A必须把该block写入到磁盘,然后由instance B从磁盘读取。当时在8i中引入cache fusion,使得“读”能跨节点的“读”,但是“写”(或者说修改),还是要写入到磁盘,再在另一个节点读出来,然后修改。

9i中,“写”得到了改进,脏块也能跨节点的传输。这就是常说的Write / Write Cache Fusion。

10gR1引入DRM,但当时的DRM功能很有限,只有在instance变化的时候(如instance被踢出集群,instance加入集群)才进行资源的remastering。

10gR2引入Affinity Locks和Object级别的DRM。

11g引入Read-Mostly和Reader Bypass

2DRM的实现依赖以下的功能:

1、Read-mostly locking

【原理】11g的DRM引入了read mostly locking的机制,它会基于对象的global operation历史。

read mostly locking机制,能减少读访问的消息传递和CPU消耗,但是写访问就会比传统的cache fusion locking机制消耗更多的IO。

oracle的cache层记录着每个对象上的S lock和X lock的数量,如果某个节点打开了大量的S lock并且很少了的X lock,并且block传输的比较少,那么这个对象在这个节点上就是read mostly了。当read mostly发生的时候,对象的共享就停止了,并且block不再通过interconnect进行传输(除非block被修改)。

当一个对象被定义成read mostly,他会被master node授予在所有节点上的S affinity lock,这意味着所有的节点都被“提前”授予了该block的读访问权限,因此,减少了在各个节点间互相传递S lock的消息量。

Oracle使用一种特殊的叫anti-lock,来控制read mostly对象上的X锁。当x lock被申请时,所有的节点会被广播通知到要打开anti-lock,,在anti-lock的淫威之下,所有的对那个块的访问(不管是S lock还是X lock)都会变成标准的cache fusion locking,即使该对象本身还是read-mostly。广播会在分配X lock之前完成,仅当block上没有anti-lock打开的时候。anti-lock将会在read-mostly消失的时候,或者脏块写入磁盘的时候清除掉,并且X lock会降级。

为read-mostly的对象打开x lock是非常昂贵的操作,在分配x lock之前,master node需要广播anti-lock给所有的节点。在x lock关闭之前,anti-lock不能被移除。另外,在节点加入集群的时候,他也会创建anti-lock,anti-lock只是在LE上标记KCLL_F_ANTI,并且在有anti-lock的情况下,read-mostly lock不能被分配。

【性能优势】在读居多的情况下,由于减少了消息传递,因此"gc cr grant 2-way", "gc current block 2-way" and "gc current block 3-way"的等待大大减少,但是你会看到"db file sequential read"的等待有所增多,因为不在内存间传输block块,而改成去物理文件读取了。GCS消息传递和block transfer的统计值也大大减少了。

在写居多的情况下,X lock的请求会增加,anti-lock广播的次数也会增多,此时"gc current grant busy"的等待就会增加,因为GCS的消息传递增加了。 另外,由于打开anti-lock的block的行为都会变成传统的cache fusion的行为,你将又能看到一些2-way grant和block transfer的等待了。

由于减少分配S lock,只要在读居多的情况下(即X lock申请量不多的情况下),cluster还是很能从read-mostly特性中得到好处的。

这是因为在节点数多的情况下,远程分配的机会将会大大增加。这意味着利用read-mostly将能减少消息传递。另一方面,当节点增加时,X lock的请求将会增多,这是因为X lock的请求会传播到每个节点,当节点数增加的时候,消息传递的成本也增加了。

总而言之,clsuster将会在节点数多,且X lock请求少的情况,因为read-mostly特性而收益。但是当X lock请求增加的事情,性能会急剧的降低。从另一方面说,如果你的节点数比较少,那么或许你从read mostly特性那里得不到很多好处。

而由于read mostly会消耗比较多的IO,这个时候你就要估计你一下你的IO情况了,如果你的块和消息传递的收益小于IO负载变重的情况,或者你已经处于IO压力很大的情况下,那么,就不建议你开启read mostly的特性了,你可以禁用read mostly的特性。设置方式是:_gc_read_mostly_locking=FALSE

因此,read-mostly的特性是给那些读很多,写很少的系统来启用比较合适。

【read-mostly的过渡】

oracle的cache层保留着每个object的x/s lock的请求统计信息,他会根据统计信息,自动初始化或者舍弃read-mostly。这种过渡和affinity很相像,通过标准DRM协议。当cache层看到太多anti-lock的时候,read-mostly将会被舍弃。当read-mostly的负载突然变成大量的写的负载的时候,大量的anti-lock增加的时候,这种过渡就会发生了。举例来说,就是当一个大量被read-mostly的表,进行了大量的update操作的时候,这种过渡就发生了。

2、Object affinity

说实在的,我一直不知道affinity这个词该怎么翻译,亲和力?吸引力?我们姑且把它叫做对象吸引吧。

在默认的情况下,即当没有吸引机制或者read-mostly策略生效的情况下,buffer cache的资源master权限是会被均匀分发到每个active的节点,也就是说,某个数据库节点成为master的概率是N分之一,N为active的节点数。

吸引机制能通过master节点上被访问最多的buffer cache资源,来减少消息传递和CPU的负载。吸引机制是在10gR1版本引入的,但是只是针对datafile级别,如果某个datafile被某个instance经常访问,所有属于这个datafile的buffer都会remaster到这个节点上。从10gR2版本开始,吸引机制是基于object级别了。某个对象会在某个实例上特别的受欢迎,因此该节点上对应的global cache资源也会变成master。

吸引机制能通过减少代码路径的长度和GCS的消息传递,从而达到优化性能的效果。当一个block是在远端节点是master,GCS信息就要从请求者处发送到master处。用来接收锁分配和读权限。如果这个block remaster到了请求者的节点上,那么消息传递的过程就免了。其他类似的操作也会免了,如写或关闭操作。

一旦吸引完成,请求者节点就基本上能“廉价”的affinity (b)locks,从而大量的减少代码路径。

3、Undo affinity

undo的吸引和对象吸引类似,只不过它发生在undo block上,也就是说,所有的global cache资源的undo segment,都将master在某个实例上。

undo吸引发生在如下的情况下:

undo_management设置成auto时,发生在instance启动的时候,在undo_tablespace里面指定的undo segment,或者当undo_tablespace发生变化时候。

undo_management设置成manual是,发生在instance启动时,在rollback_segments中指定的rollback_segments,或者运行“alter rollback segment…online”,致使rollback_segments变化。

当instance crash时,recovering instance会暂时master crash instance的undo block,当recover完成之后,所有的undo buffer会flush到disk上,用来优化remaster在crash instance再次启动的时候。

当对象变成read-mostly的时候,打开S lock就变成非常廉价的操作了,因为没有消息传递,并且没有了分配和初始化LE(LOCK ELEMENT)、lock context、KJBL结构、KJBR结构和准备READING buffer。

read-mostly lock是非常简单的在buffer header处标记KCBBHFRM,这和S lock的操作是等价的。read-mostly lock会很快被grant。

3DRM的大致机制

GCS会追踪每个节点、每个对象上的锁请求和锁类型,有3个进程执行DRM的功能:LCK0,LMD0和LMON。

一旦DRM请求开启,它先会将请求插入到请求队列中,接着,LMD0会为DRM请求检查请求队列,如果LMD0找到了一个请求,消息将在各个节点间交换,然后set DRM为freeze状态。

当所有节点都成功的完成此操作后,LMON进程将发起和LMS进程一起进行remaster操作。

remaster的步骤和LMON进程的reconfiguration类似,remaster会在一个所谓的“窗口”完成,(“窗口”的大小原来由_lm_drm_window确定,在11g中由_lm_num_pt_bucket/_gc_latches决定。)这项技术由于只是冻结部分的资源,因此可用性得到了增强。

它的步骤包含以下几个状态:

QUIESCE - 这个状态是发生在相关的block刚刚完成transfer的情况下,没有新的OPENS和CONVERTS发生在remaster的资源上。

FREEZE - LMON进程等待所有节点都确认当前“窗口”已经被冻结。

CLEANUP - 老的master清理remote lock,并且删除需要remaster的所有对象的resource。

REPLAY - 将本地的lock信息传送到新的master上。

FIXWRITES - 重建新master节点上的资源的写状态。

END - 解冻当前“窗口”,移动到下一个窗口。

SYNC 发生在上述的步骤中。本地的节点等待其他节点完成他们之前的DRM操作。

4DRM的相关参数

1. _gc_policy_time (Oracle10g: _gc_affinity_time), default=10

表示检查对象是否进行吸引或read mostly的时间间隔。

2. _gc_affinity_ratio (Oracle10g: _gc_affinity_limit), default=50

表示某节点上的对象访问比其他节点多50倍(2015-11-30 15:40更新,注意是50倍,不是50次。),就认为是满足吸引的条件。

3. _gc_policy_minimum (Oracle10g: _gc_affinity_minimum) default=600 in Oracle10g, 1500 in Oracle11g

表示在发生affinity之前,每分钟每个CPU访问文件/对象的次数。当默认的超过每分钟每个CPU 600次时,触发吸引或read-mostly。

4. _gc_undo_affinity and _gc_undo_affinity_locks, both default to TRUE

决定undo吸引是否进行。这个参数不建议改动。

5. _gc_transfer_ratio defaults to 2 (which means 50%)

如果block在内存间传输量少于从磁盘读取的block的量的50%,那么read mostly将会被允许进行。

6. _gc_affinity_locking and _gc_affinity_locks, both default to TRUE

决定对象吸引是否开启。

7. _gc_read_mostly_locking, defaults to TRUE

决定read mostly特性是否启用。

8. _lm_drm_max_requests, default=100

在一次DRM中,DRM请求能被处理的数量。

回复关键字

资源说明

2016OTC

第六届Oracle技术嘉年华PPT下载

2016OOW

2016OOW大会PPT下载;

2016724

2016首届7.24运维日PPT;

2016DTCC

2016年数据库大会PPT下载;

2015DTCC

2015年数据库大会PPT下载;

2014DTCC

2014年数据库大会PPT下载;

2013DTCC

2013年数据库大会PPT下载;

2012DTCC

2012年数据库大会PPT下载;

EnmoEdu

天道酬勤-恩墨学院分享;

Chinapub

Chinapub读书会分享下载;

2016YHEMSZ

云和恩墨大讲堂2016深圳;

2016GOPSZ

2016深圳全球运维大会PPT;

DBALife

"DBA的一天"精品海报大图;

12cArch

“Oracle 12c体系结构”精品海报;

11gArch

11g体系结构图,Oracle出品;

DBA01

Oracle DBA手记第一本书下载;

BigData

大数据2016图谱Matt Turck绘制;

YunHe

“云和恩墨大讲堂”案例文档下载;

2015ACOUG

2015年ACOUG年会PPT下载;

2015VDO

2015年Oracle技术嘉年华视频;

2015OTC

2015年Oracle技术嘉年华PPT;

2014OTC

2014年Oracle技术嘉年华PPT;

2015OOW

2015年旧金山OOW演讲PPT;

2015RWP

2015年RWP中国行演讲PPT;

2015GOPS

2015上海全球运维大会PPT;

感谢大家支持,我们将不断增加分享资源列表,这些资料中如有侵犯版权,请反馈给我们将立即清除。也欢迎大家反馈意见建议。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-11-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

小技巧:使用Cryptsetup加密U盘

如今U盘的存储和数据传输能力已经非常强了,可以跨各类平台运行,存储空间甚至达到了256G,堪比过去普通硬盘的容量。这里,我们将向你展示如何加密U盘,妈妈再也不用...

1849
来自专栏企鹅号快讯

春运要来了!微信可以实时接收高铁出行信息,无论是购票还是改签

就在今天,更加便民的服务来了! 从今天起,微信可以实时接收高铁出行信息,无论是购票、改签、退票等行程通知,都能在微信上获取! 绑定的方法有两种 第一种——微信公...

1836
来自专栏黑白安全

45种撸进后台的方法

2、到Google,搜索一些关键字,edit.asp? 韩国肉鸡为多,多数为MSSQL数据库! 

1836
来自专栏云计算D1net

XP“退休“ 用户该选择Win 7还是Win 8?

? 微软为Windows XP提供支持已经13年了,4月8日后,Windows XP的技术支持将停止,包括保护PC的自动升级等,同时微软也将停止在其官...

2923
来自专栏何俊林

Android 8.0正式发布 "奥利奥"新功能惊人

尽管 Android 刷版本号的步伐年年加快,但每年带给用户的惊喜从未减少。经历了四个开发者预览版的洗礼后,Android 8.0 终于在今天凌晨迎来了正式版发...

1948
来自专栏指尖下的Android

从一个聚合SDK的Bug解决所展开的人生思考

最近,公司有个做聚合SDK的老铁要离职了,然后它的锅就甩给我了,话说,本来开会的时候说和另一个同事一人负责半个月

1142
来自专栏张戈的专栏

10个超有趣的Linux命令

本文展示了 10 个有趣的 Linux 动态命令,这些命令和实用功能无关,仅供娱乐!看完此文,你会对 Linux 有个全新的认识,谁说 IT 男就没有屌丝娱乐的...

2776
来自专栏张叔叔讲互联网

QQ如何把你消息传递给好友的?(下篇)

话说你已经成功注册了QQ号码,取名叫“村头小伙”。你的同学小芳“村里那个姑娘”也接受了你的好友申请。之后的日子里面,你们经常通过QQ发送文字和语音,偶尔还会视频...

632
来自专栏携程技术中心

干货 | 高吞吐消息网关的探索与思考

作者简介 刘惊惊,唯品会业务架构部高级架构师。主要负责用户线,营销线的业务架构,也参与库存系统的重构改造。 一、背景介绍 唯品会是一家立足于“全球精选,正品特卖...

2714
来自专栏双十二技术哥

Android性能优化(九)之被忽视的电量

移动互联网的大潮到来之后,我们都变身好男人:“用智能手机的男人都是好男人,因为晚上必须回家充电。”一句笑言,但也可以看得出来目前使用智能设备电量方面的问题。

903

扫码关注云+社区