Library cache lock常见案例分析（一）
Library cache lock常见案例分析（一）
- 原因：未共享的SQL文本
-
- 解决方案：重写SQL以使用绑定变量
- 解决方案：使用CURSOR_SHARING参数
- 原因：共享SQL被淘汰出内存
-
- 解决方案：共享池扩容
- 解决方案：开启自动共享内存管理（ASSM）
- 解决方案：将频繁使用的对象pin在共享池中
- 原因：失效的库缓存对象
-
- 解决方案：避免在业务繁忙时段进行DDL操作
- 解决方案：避免在业务繁忙时段收集统计信息
- 解决方案：避免在业务繁忙时段进行TRUNCATE操作
- 原因：对象被其他会话编译中
-
- 解决方案：避免不同会话同时编译对象、避免在业务繁忙时段编译对象
- 原因：审计开启导致
-
- 解决方案：评估审计的必要性
库缓存锁通过在对象句柄上获取锁来控制库缓存客户端之间的并发，其作用主要有以下两种：
- 一个客户端可以阻止其他客户端访问同一个对象。
- 客户端可以长期维持一种依赖关系（此时其他客户端无法对该对象进行修改）。
此外，在库缓存中定位某个对象的操作过程中也会获取该锁（首先获取库缓存child latch以扫描句柄列表，找到对象后，再在该对象的句柄上放置此锁）。
下面两个工具可以协助排查库缓存锁等待问题：
TKProf：非递归语句与递归语句的总体等待事件汇总显示，库缓存锁等待占用了大量时间。- AWR或者statspack：严重的库缓存锁等待。
TKProf是Oracle数据库官方提供的核心性能诊断工具，主要用于分析数据库后台生成的SQL Trace（SQL 跟踪文件），将原始、杂乱的跟踪日志转换为结构化、可读性强的报告，帮助数据库管理员（DBA）和开发人员定位SQL语句的性能瓶颈（如执行效率低、资源消耗过高的SQL）。
⭐️ 出现Library cache lock等待事件的常见原因可以分为如下几类：
- 未共享的SQL文本
- 共享SQL被淘汰出内存
- 失效的库缓存对象
- 对象被其他会话编译中
- 审计开启导致
- RAC环境中SQL未共享
- 行级别触发器过度使用
- 子游标的数量过多