比如，在对一个数据库segment段进行一个直接读操作前，读进程或者并行查询协调器发出一个ci跨实例调用，给dbwn进程，要求dbwn进程,把属于这个segment的所有缓存的脏块实行一次检查点活动的dbwn进程.
利用锁值块把这个segment上面的所有的数据库对象的编号联系起来.同样，在truncate这个segment之前，重新利用block范围内的ci，用于确保这些受影响的block范围上面的脏缓存块被全部flush到磁盘上,而且
清除或清理受影响范围块block的缓存块之中标识为无效的部分.
     尽管使用一些跨实例的调用ci（原文：despite their name,many cross-instance calls are used,单实例如同在ops环境下一样，也会使用对应的ci enqueue.




library cache instance locks
     在并行服务器数据库情况下，一些library cache lock和pins也需要全局显露.请记住，library cache locks用于解析调用期间，pins用于执行调用期间,防止冲突ddl.在并行服务器ops下，防止在所有的实例上出现冲突的ddl，是非常有必要的.为了达到这个目标，
在数据库对象上加上全局的library cache locks和pins是很有必要的sufficient.（次级）从属或依赖的对象如：cursors，它们上面的本地锁及pin是不需要全局显露的,因为它们间接会得到保护，假如它们所依赖的对象得到保护的话.

     更进一步意识到，以null mode保持或持有的本地library cache locks，会使缓存的library cache object失效，原因在于它们所依赖的对象定义应该发生了改变.
一个数据库对象在多个实例上要提供相同的功能，通过对library cache中缓存的所有数据库对象，以共享模式持有一个iv(invalidatation）实例锁.需要从全局上使一个对象定义无效的任何进程，它仅仅只是对相同的资源持有一个排它锁,因此导致或引起lck0进程删除它们共享的锁并且
使这个对象无效或不合理.


     采用隐含参数可以禁用global library cache locks,pins,及iv(invalidation locks).不建议这样作，除非完全禁用了dml locks.




pcm instance locks

   pcm(parallel cache management)并行缓存管理lock锁不会直接保护cache buffers---至少不会直接保护.pcm locks保护数据结构，这个数据结构就叫lock element锁要素或锁成分或锁分子.而每个lock element保护一系列数据块，这数据块不是cache buffers.但是，包括这些数据块（非cache buffers)的任何cache buffers会链接到它们的lock element.
        (pcm lock 保护lock element,这个lock element保护一系列的数据块，请注意这个数据块不是cache buffer.
         包括这些数据块data block的任何cache buffers会链接到它们的lock element)


   lock elements锁元素也叫作全局缓存锁global cache locks,但这个术语本身没有什么多大作用,因为它们既不是锁也不是资源.它们是在pcm实例锁和cache buffers之间的一个intersection十字交叉点entry条目.




fixed lock elements
    lock elements锁元素既可以release也可以是固定的.可以release的锁元素lock elements可能用于哈希hashed或者精良提练fine-grained的locking，但是固定的lock elements仅仅用于hashed locking.
要是使用hashed locking，数据块通过一个哈希算法映射到lock elements,这样每个lock elements可以马上保护一些缓存块.但是对于fine-grained锁定locking,lock elements每次会动态分配，保护一个单一的缓存块.




   数据块与hashed lock elements的映射关系,以及它们到底是固定或releasable的lock elements，是由gc_files_to_locks和gc_rollback_locks参数来确定的.固定的lock elements的数量是源于这些配置.用于hashed locking的release lock elements的数量，必须小于利用gc_releasable_locks参数配置的releasable lock elements的数量,默认是
缓存中buffer的数量.余下或剩下的releasable lock elements用于fine-grained locking.
   
   fixed固定的和releaseable hashed locking表示出同样的性能,除了一个非常重要的方面.在实例启动期间,lckn进程必须以null mode获取所有固定lock elements的实例锁.这可能要花费几分钟.releasable hashed locking会在实例活动的初始或开始增加期，diffuses这个成本.从那之后，这两种形式的hashed locking性能是一样的哟.请注意：releasable
hashed lock elements之上的锁句柄，实际上是不会released,虽然lock element可以被releasable.从这个层面来讲，你应该为hashed locking仅仅使用releasable lock elements,而不要使用固定的fixed lock elements.

  




hashed locking
    当一个块放入缓存中，这个将会得到保有存的缓存之下的lock element，必须要确认下来(译得别扭：原文the lock element under which it will be protected must be determined),buffer必须被链接到lock element。具体如何实现取决下这个块到底是采用fine-grained或者
hashed locking,对于hashed locking,它也依赖于或者与块的类型或级别有关.会区别处理rollback segment blocks和data blocks.
    对于爱制于hashed locking的数据块,这里有一个索引条目，由它映射文件编号和lock element buckets的关系,以及一个bucket header array,这个array会标识每个bucket上面一系列lock elements.查询x$kclfi及x$kclfh可以查询到这些array队列的信息.对于rollback segment blocks,
同样查询x$kclui及x$kcluh可以查询到它对应的队列信息.在实例启动时，根据gc_files_to_locks和gc_rollback_locks会创建这些队列.


    当一个rollback segment block或data block放入缓存中，这些队列（以上）用于查找正确的lock element bucket.此时不需要用latch,因为这些队列是静态的或静止的.选取用于保护来自于buckets之间某一个特定的块，就是块编号减去2，然后除以这个bucket的blocking factor，最后再除以这个bucket之中的lock element数目,得出的最终结果四舍五入.
哈布函数从块编号中减去2，而不是减去1,因为你要考察到文件头块file header block，同时（而且）确信，如果blocking factor被选择用于以块表示的extent 大小的公约数（整数），此时lock element覆盖范围将align到extent的boundaries界限内或范围内.另者，每个bucket中lock element个数采用质数，确保均匀把这些块分配到对应的lock elements,这也是
最好的一种方法,而不管（不关心）数据库segments内部的数据分布情况.

    lock elements的一种更为严重的集中，应该被分配到数据文件，这个数据文件可能竞争hashed pcm实例锁.如果数据文件上面的块发生了变化，并且多个实例会访问这些块，出现竞争的可能性很大.