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未共享
• 行级别触发器过度使用
• 子游标的数量过多