文档内容

适用于:

用途

下面文档中将提供关于 Library cache lock, Library cache pin 与 Library cache load lock 等待事件的一些简明的知识。

排错步骤

• 什么是"Library cache lock" ?

  这个事件控制对 library cache 的并发使用。 它获取一个对象句柄（object handle）上的锁，从而：

  • 一个使用者可以防止其它使用者访问同一个对象。
  • 这个使用者可以长时间地维护一个依赖对象(例如，其它使用者不能更改这个对象)。

  定位 library cache 中的一个对象同样也需要这个锁。
  在解析或编译 SQL 或 PL/SQL 语句期间，我们需要获得被引用的数据库对象(表，视图，过程，函数，包，包体，触发器，索引，聚簇，同义词)的 library cache lock；这个锁在解析与编译结束时会被释放。
  
  cursor(SQL 与 PL/SQL 区)，管道（pipes）和其它的瞬时（transient）对象不使用这个锁。
  Library cache lock 上的死锁不会被自动检测到，对其的操作是同步进行的。
  
  参数:

  • handle address
    对象地址
    
    
  • lock address
    锁地址。它与 latch 与 enqueue 不同，它是一个 State Object。
    
    
  • Mode
    申请锁的级别
    
    
  • Namespace
    对象使用的 namespace, 取自于 V$DB_OBJECT_CACHE。

• 什么是"Library cache pin" ?

  这个事件管理 library cache 并发。Pin 住一个对象会使它使用的 heap 被载入到内存中。如果一个使用者想要修改或检查这个对象，它必须在获得 lock 之后再取得一个 pin。Pin 可以用 NULL, SHARE, EXCLUSIVE 模式获得，并且可以看做是一种特殊的 lock。等待"library cache pin"意味着这个 PIN 正被某个其它 session 以不兼容的模式持有。

  访问当前被缓存到 library cache 中的数据库对象（表，视图，过程，函数，包，包体，触发器，索引，聚簇，同义词）的时候需要获得 library cache pin; 在 library cache 中，数据库对象被缓存成两部分：句柄(handle)和对象(object); 这个锁（pin）只有当"object"部分被缓存的时候才会被持有。

  Library cache pin 上的死锁不会被自动检测到，对其的操作是同步进行的。
  
  注意：在10g以后，"library cache pin"已经被 mutex 取代。
  参见：Document 1298015.1 WAITEVENT: "cursor: pin S wait on X" Reference Note

• 如何减少 Library cache load lock

  如果一个对象不在内存中，那么我们不能对其申请 library cache lock。
  因此，需要将这个对象加载到内存中。
  然后，session 尝试找到数据库对象的 load lock，以便它能载入这个对象。
  为了阻止多进程同时请求加载同一个对象，其它同样请求的 session 将等待 library cache load lock 因为这个对象正在被加载到内存中。
  
  等待 library cache load lock 是由于对象在内存中是不存在的。
  Library cache 中的对象不存在，是由于 shared pool 过小引起的频繁重新装载，或太多的硬解析缘于不共享的 SQL。
  
  避免这种等待的通常建议:

  • 增加 shared pool(避免 reload).
  • 增加 session cached cursors(避免 cursor 被刷出 shared pool)
  • 设置 cursor_sharing 为 force(减少硬解析)。---可能改变执行计划与查询的性能，所以要作充分的测试。
  Document:94036.1 Init.ora Parameter "CURSOR_SHARING" Reference Note

• Library cache pin 与 library load lock 是什么关系

  Library cache pin 和 load lock 可能出现在对 PL/SQL, views, types 等的编译与重编译期间。这种编译总是显式的(比如应用安装，升级，打补丁)。但是对象重编译也可能发生在对象失效期间。
  
  在处理那些“奇怪“的 library cache pin 和 load lock 等待时，我们需要检查为什么对象失效了。很有可能失效是由于某些操作修改了它所依赖的对象的"LAST_DDL"。通常来说这些操作包括对象维护操作，比如 ALTER, GRANT, REVOKE, replacing views 等等。还有就是收集 optimizer statistics 也会造成 cursor 失效，进而导致 library cache 的重装载。这个现象在 Oracle Server Application Developer's Guide 的object dependency maintenance 部分有描述。
  
  对象失效以后，Oracle 尝试在第一次访问这个对象时去重编译它。有些情况下，如果其它 session 已经 pin 住这个对象，可能就会出现问题。 很显然，在有大量活跃用户与复杂依赖关系(例如，很多交叉依赖的 packages 或package bodies)的情况下更容易出现问题。有些时候对对象的编译会持续数小时从而阻止其它 session 对其的访问。
  
  
  
  在 library cache dump, level 10 可以看到:
  查找 ALTER ... COMPILE 语句和 lock=X 或 pin=X 的 objects/handles.
  
  

• 提示

  • 需要频繁使用的 stored PL/SQL 所依赖的对象，对其 altering, granting, evoking 操作需要特别小心。实际上，解决这种问题很大程度上依赖于应用程序和系统维护的时间。应用程序开发者需要考虑某些决定可能会对应用程序的可扩展性及性能产生负面影响。
  
  
  • Load lock总是以排它模式获得的。
    如果 session load lock 繁忙，session 将一直等待，直到锁变成可用。

• 已知问题:

  Document 1309738.1 High 'library cache lock' Wait Time Due to Invalid Login Attempts
  
  Document 10018789.8 Spin in kgllock / DB hang with high library cache lock waits
  Document 7423411.8 Process may hang waiting for "library cache load lock" with no holder
  Document 7706138.8 Process may hang waiting for "library cache load lock" with no holder
  Document 9675816.8 Bug 9675816 - Self deadlock with 'library cache lock' waits

参考