实例锁instance locks用于实例内部锁定locking及ops数据库多个实例的通讯.虽然instance locks很少或没有用于单实例数据库中，但是大师建议大家还是要好好阅读本章内容.


     单实例数据库它仅仅只是并行服务器的一种特别例子，你将会发现它的许多操作理解或领会，除非你理解一般或通用的案例。

    

the lock manager
   管理instance locks的哪部分oracle叫作the lock manager.the lock manager这部分或这层的功能会影响所有进程的操作.
但是，最明显的证明或影响就是，你会发现存在许多（一系列）的lock management processes（也叫锁管理进程），以及每个实例中关于实例例信息的内存数据库(取原文：and an in-memory database of instance lock information in each instance)

   the lock manager是采用分布式管理的。并没有一个所谓中心控制。每个实例仅维护它感兴趣的实例锁的相关信息.the lock manager也可以讲是集成或综合（整合的）。这是因为，oracle8以前，lock management的功能是需要由每个具体的os提供的。但从oracle8以
后，这个功能集成到了oracle kernel.
   
  
   虽然lock管理器集成到了oracle内核中，需要一个锁句柄的进程不会访问实例锁数据库来直接分配一个锁句柄。相反，它们还是会构建并发送一个消息到lmdn后台进程，同时等待lmdn进程返回一个锁句柄.这个消息标识这个资源，同时配置一些选项，用于决定锁的获取和随后的管理.


   如果本地实例锁数据库不存在这个资源，会从实例锁资源表the instance lock resource table中获得一个slot.
the instance lock database.如果曾经这个资源上面的锁被release，它被保留下来，这个资源被打个一致性的标志（或称一致性资源）.从资源标识中计算出来目录结点，同时主节点标志为未知（除非资源是一致性的）。一旦本地实例锁数据库存在这个资源的话，实例锁表the instance lock table的一个slot
会分配给这个锁。它的进程或组所有权（所有者关系）会建立起来,设置死锁检测参数.lmdn后台进程此时会构建继而发送一个响应信息给客户端进程。这个信息叫作一个获取异步trap,或者叫获取ast.这个获取ast消息包含一个锁句柄.

    等待lmdn进程返回一个锁句柄的进程，会去等待一个dfs lock handle等待事件(a dfs lock handle wait).dfs代表分布式文件系统,它是oracle实例锁管理功能的旧称。锁句柄等待应该是很短暂的，因为
    instance locks的锁及资源结构驻存在一个sga专有的区域中，被叫作实例例数据库(the instance lock database).锁及资源队列大小由lm_locks和lm_ress来控制。第三个参数lm_procs定义持有这些锁的实例及进程队列的大小.这个队列对于每个本地进程要一个slot，每个远程实例也是一个slot.

   the instance lock database也包含一系列进程组.在这种情况下，instance locks可能被一组进程所持有，而不是单一的进程。组锁关系(group lock ownership)允许多线程服务器会话在共享服务器进程之间迁移，允许从一个进程分离出来的oci事务然后在一个不同的进程上继续。所有锁获取请求可以指定进程或者指定
组所有者.一个进程组的所有成员会在instance lock database中自动trace及infer.进程组内部的以组持有group-owned方式的实例锁的交换，不需要任何lock或者转换。进程组队列的大小由_lm_groups参数来控制，默认为20.
  

实例锁数据库the instance lock database包含除了资源之外的其它一些结构，像锁，进程，进程组.通过hash table访问这些队列；资源结构用于记录统计信息，管理等待和超时，检测死锁，实行恢复；还有一部分内存用于存储消息缓冲message buffers（这些message buffers用于实例内部的通讯）。buffers大小是由_lm_send_buffers来控制，默认为10000.


实例锁数据库大多部分在数据库启动后是不变的（固定的）。但是，oracle有这个一个选项或叫权利吧，如果有可能,为了额外动态分配资源和锁，会从共享池中分配内存。如何发生这些，一个消息会写入alert,同时对应的参数会在下次数据库重启递增，除非是由于另一个实例恢复引起的overrun（过量），就如gv$dlm_misc(dlm表示分布式锁管理）.注意：
动态分配出来的内存不会再次重新release到共享池中.


lock mastering


   实例锁数据库是一个分布式数据库.很少或没有单节点会trace所有资源的锁。对于每个资源，会有一个主节点master node.这个资源的主节点会保存这个资源上面所有锁的完全或全部信息。其它节点只需要维护从本地持有这个资源锁的相关信息。为了动态分配资源，主节点一般情况是首次得到或获取这个资源锁的节点.对于每个资源，也会有一个目录节点,它包含或维护指向主节点的指针信息(可以理解为索引）。使用基于资源确认的一个hash function方式可以确定这个目录节点。对于持续性的资源，
主节点经常就是目录结点.
   只要发生这些情况：由于实例启动或关闭，或者因为某节点实例的故障，活动实例会发生变化，这时节点对分配的资源必须要发生变化或者叫调整.一般而言，每个资源的主节点及目录节点可能改变，这些必需信息必须在每个节点重新构建或叫重建.如果一个实例出现故障，实例恢复的前滚roll forward（或叫cache recovery)必须完成以后，才可以进行验证所有的实例锁信息是否合理或正确.

   实例锁数据库会在资源重新分配和cache recovery期间进行冻结，如何可能（适用或合理）。在这个期间啊，本地活动可以继续进行，但它们只能在已经持有实例锁的情况下进行.但是，如果一个实例没有或丢掉这个实例锁，哪它只能以只读方式访问内存中已经存在的数据，并且还在已经持有一个实例锁.这是一个非常严重的约束或规定.
你应该尝试限制资源重分配和实例恢复前滚的时间，这可以通过使用适度的资源数量和锁,也可以配置检查点活动确认可控制的恢复时间.


 

lock handle acquisition  获得锁句柄

    大多实例锁以两步法（在两个步骤中）获取。第一个步骤：得到一个锁句柄，这是一个锁的标识符，可以实现随后转变或者release操作（对实例锁）.当然，一些实例锁会在整个实例生命周期内持有，也不会发生转变或release.这种实例锁在一个步骤就可以得到，不会返回锁句柄.