waitevent：library cache lock

1、library cache lock

---

该事件通常是由于执行多个DDL操作导致的,即在library cache object上添加一个排它锁后,又从另一个会话给它添加一个排它锁,这样在第二个会话就会生成等待。可通过到基表x$kgllk中查找其对应的对象。

-- 查询引起该等待事件的阻塞者的sid、会话用户、锁住的对象

select b.sid,a.user_name,a.kglnaobj

from x$kgllk a , v$session b

where a.kgllkhdl in

(select p1raw from v$session_wait

where wait_time=0 and event = 'library cache lock')

and a.kgllkmod <> 0

and b.saddr=a.kgllkuse

当然也可以直接从v$locked_objects中查看，但没有上面语句直观根据sid可以到v$process中查出pid，然后将其kill或者其它处理。

 

2、Casue and Solutions

---

Casue 1 :Unshared SQL Due to Literals：

由于sql语句执行时没有绑定变量，导致sql不共享进行了硬解析

Sollutions:Rewrite the SQL to use bind values

检查语句是否绑定变量以及执行情况是否硬解析，使用绑定变量重写SQL并且对比执行计划

Use the CURSOR_SHARING initialization parameter：

使用CURSOR_SHARING参数将自动用语句中的绑定值替换文字值

EXACT：保留使用文字值的语句（默认值）

FORCE：用绑定替换所有文字（尽可能多）

SIMILAR：仅当查询的执行计划不会更改时才使用绑定替换文字（即，安全文字替换）

 

Casue 2 :Shared SQL being aged out

共享池太小，导致许多语句可以共享以从库缓存中老化，然后重新加载。 每次重新加载都需要硬解析并影响CPU和锁存器。

Sollutions:Increase the size of the shared pool：

增加共享池的大小，减少shared sql重reload

10g+: Use the Automatic Shared Memory Manager (ASMM) to adjust the shared pool size：

ASMM将自动调整共享池的内存大小，以确保可用的最佳数量。 您需要为SGA_MAX_SIZE和SGA_TARGET设置合理的值以启用ASMM。

Keep ("pin") frequently used large PL/SQL and cursor objects in the shared pool

使用DBMS_SHARED_POOL.KEEP（）过程标记共享池中经常使用的大型PL / SQL和SQL对象，并避免它们老化。 这将减少重新加载和碎片，因为对象不需要一遍又一遍地重新进入共享池。

 

Casue 3 : Library cache object Invalidations

当通过DDL或收集统计信息更改对象（如表或视图）时，依赖它们的游标将失效。 这将导致游标在再次执行时被硬解析并将影响CPU和锁存器。

Sollutions:Do not perform DDL operations during busy periods

DDL通常会导致库缓存对象失效，这可能会级联到许多不同的依赖对象，如游标。 失效对库缓存，共享池，行缓存和CPU有很大影响，因为它们可能需要同时进行许多硬解析

Do not collect optimizer statistics during busy periods

收集统计信息（使用ANALYZE或DBMS_STATS）将导致库缓存对象失效，并且可以级联到许多不同的依赖对象（如游标）。 失效对库缓存，共享池，行缓存和CPU有很大影响，因为它们可能需要同时进行许多硬解析。

Do not perform TRUNCATE operations during busy periods

TRUNCATE操作会导致对象失效

 

Casue 4 : Objects being compiled across sessions

一个或多个会话正在编译对象（通常是PL / SQL），而另一个会话想要在执行或编译它之前固定同一个对象。 一个会话在shared mode（如果想执行它） or exclusive mode（如果想重新编译或者改变对象）下造成library cache pin等待

Sollutions:Avoid compiling objects in different sessions at the same time or during busy times

不要跨并发会话或在高峰使用期间编译相互依赖的对象。

 

Casue 5 :Auditing is turned on

审计将增加获取库高速缓存锁的需求，并可能增加对它们的争用。 在RAC环境中尤其如此，其中库高速缓存锁定在数据库范围内（跨所有实例）。

Sollutions:Evaluate the need to audit

如果不是绝对必要，请考虑disable audit

 

Casue 6 :Unshared SQL in a RAC environment

当应用程序不共享SQL时，RAC环境中可能会发生库高速缓存锁等待。在单实例环境中，库高速缓存和共享池锁存器争用通常是非共享SQL的症状。但是，在RAC中，主要症状可能是库缓存锁争用。

Sollutions:Rewrite the SQL to use bind values

Use the CURSOR_SHARING initialization parameter

 

Casue 7 :Extensive use of row level triggers

广泛使用行级触发器当频繁触发行级触发器时，可能会发生高于通常的库缓存活动，因为需要检查是否正在读取变异表。在触发器执行期间，应用程序可能会尝试读取变异表，即正在被导致触发器触发的语句修改的表。由于这可能导致不一致，因此不允许，应用程序应收到错误ORA-4091。检测此错误的机制涉及每个执行的select语句中引用的每个表的一个库高速缓存锁获取。

Sollutions:Evaluate the need for the row trigger

 

Casue 8 : Excessive Amount of Child Cursors

正在为某些SQL语句创建大量子游标。此活动导致在同时创建子游标的各个会话之间或与还需要类似资源的其他会话（锁存器和互斥锁）之间发生争用。

Sollutions:Inappropriate use of parameter CURSOR_SHARING set to SIMILAR

 

参考官方文档：‘library cache lock' Waits: Causes and Solutions文档 ID 1952395.1