RAC锁管理与锁问题定位一.docVIP

RAC 锁管理与锁问题的定位  一 从我一到企业，主要工作就是维护我们的一套大 RAC。主库 5 个节点，备库最多时曾有 4 个节点，后来备库减至单实例了。主、备一共 8 套存储，总间共 300T 空间。内部互联采用业内最快的 InifiniBand。也算是豪华配置了。最顶峰时，主库数据 130T 左右，天天归档量顶峰时靠近 6T，是我见过的最大、 最忙的数据库。 库一大，很多本来不是问题的问题，就会变成问题。比方数据词典维护， Oracle 在这一块上做的很好， 因为这是 Oracle 的根本。这一块上稀有问题的。 可是，当数据库中有几百万个段时呢！其实就算有几百万个段， Oracle 也运行的好 好的，在极偶然的情况下，会遇到问题。还有控制文件，往常也就几十 M，但当它靠近 1G 呢，它就会像一个活火山同样， 偶而爆发。 此外，还有更容易想到的， 如备份的问题，搭建备库的问题等等。如果一个库只有 1T，搭建个备库只需要几个小时，可是上百 T 呢！不只是时间问题， 选择合适的方法是另一个需要考虑的问题。 平时工作太忙， 现在有时间了，慢慢和大家分享， 总比烂在我的肚子里强。 开始今天的正题，聊一聊 RAC中的锁管理。 大家一般对 RAC中的 CacheFusion比较熟悉，而对锁管理，议论的不多。其实，锁管理更为基础，因为块，或者更正确点， Buffer cache 中的 Buffer，也是锁管理的对象之一。好，下面我们开始。 一、 首先，认识一下 RAC中要管理的锁的种类： （一）、你在 V$LOCK中看到的全部锁，这一部分我们能够称之为高级行列锁。 （二）、 Library cache lock/pin，还有 Row cache lock，这一部分我们称之为中级内存锁。（中级内存锁还有一个，就是 Buffer pin，它致使的竞争，就是我上遍文章中所讲的 buffer busy waits。注意啊，想降低 buffer busy waits 吗，哪就使用更迅速的设施寄存 Redo File吧。详在中的第一遍日志， 或在上个帖子中参加议论：） （三）、还有，就是针对 Buffer cache 中的块的锁了， Oracle 为它定义的种类为BL。 上面这些，就是 RAC锁的全部了。也就是说， RAC的数据库在运行期间，只有这些东西，需要在节点间同步。 下面提个问题，猜猜看哪种锁数量最多？ 你一定会说针对 Buffer 的 BL锁，但不是。大部分情况下，是 Row cache lock 的数量最多（这里不议论极致情况）。 可是 Row cachelock往常是静止的，很少改正。数据词典，元数据吗，变动自然不多。而 Buffer 的 BL锁就不同样的，改正频繁。因此， Oracle 在普通的锁管理体制之外，针对 BL又搞了个 Cache Fusion。好，这里就不议论它了，以后我会再详尽议论 Cache Fusion的。 二、 资源池与主节点 和单实例中的行列锁同样， RAC中的锁，也分为两部分：资源构造和锁结 构。 在共享池中，还有一个资源构造池，审请锁的第一部，就是到这个池中审请一个 Free 的资源构造。 能够把资源池想像一块内存，其时，它就是一大块内存，在实例启动时分派。如下列图： 在资源池中，内存又被分成一个个小块，每个小块，就是上图中的一行， Oracle 称为一个 Slot。每个 Slot，就叫做一个资源构造（ Resource struct）。每个资源构造中的主要信息如下： 资源名（ RESOURCE_NAME） 变换者行列地点（ ON_CONVERT_）Q 拥有者行列地点（ ON_GRANT_Q） 主节点（ MASTER_NODE） 能够进一步把资源池想像成如下的表格： 我们把其中重要的东西解释一下。 1、资源名：和单实例中的行列锁同样。资源名由资源种类加两个参数组成。比方 TM 锁的资源名，一般写为 TM-ID1-ID2，TM 是资源种类（也就是锁种类）。参数 ID1 是 DBA_OBJECTS中的对象编号， ID2 为 0。假定有个表，对象编号是 195，它的 TM 资源（或称为 TM 锁）的资源名为： TM-195-0。这点关于单实例、多实例来说，是同样的。 再来找个不同样的，比方一个 Buffer 。资源种类是 BL，两个参数 ID1、ID2分别是从块地点计算出来的（计算规则我会在 Cache Fusion中详尽描绘）。这个BL-ID1-ID2锁，在单实例中，绝对不会出现。 2、变换者行列和拥有者行列： 这分别是两个链表， 记录有多个进程拥有锁， 或正在等待锁。 RAC认为每个实例中的每个进程都能够获得空锁，所以，如果进 程想获得独占锁， 但没有成功， 那么它是要从空锁变换成独占锁而没有成功。 所