锁管理与锁定位问题.docxVIP

RAC 锁管理与锁问题的定位（一）(第二篇，实践篇已经整理出来：/thread-1596447-1-1.html/thread-1596447-1-1.html）?从我一到公司，主要工作就是维护我们的一套大RAC。主库5个节点，备库最多时曾有4个节点，后来备库减至单实例了。主、备一共8套存储，总间共300T空间。内部互联采用业内最快的InifiniBand。也算是豪华配置了。最高峰时，主库数据130T左右，每天归档量巅峰时接近6T，是我见过的最大、最忙的数据库。?库一大，很多本来不是问题的问题，就会变成问题。比如数据字典维护，/tree/index_1/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吧。详在中的第一遍日志，或在上个帖子中参加讨论：/thread-1583811-1-3.html）（三）、还有，就是针对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认为每个实例中的每个进程都可以获得空锁，所以，如果进程想获得独占锁，但没有成功，那么它是要从空锁转换成独占锁而没有成功。所以这里没有等待者队列，只有转换者队列。我们可又把转换