重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛

标题: Oracle library cache lock等待事件 [打印本页]

作者: 刘泽宇 时间: 2026-3-8 12:34
标题: Oracle library cache lock等待事件
在 Oracle 共享池（Shared Pool）中，Library Cache 是 SQL、PL/SQL、对象元数据等最核心的组件之一。当系统出现明显的 library cache lock 等待时，通常意味着：
共享池中的对象访问、解析、失效或并发控制已经成为系统瓶颈。

一、Shared Pool 与 Library Cache Lock 的作用机制
共享池主要包含以下内容：

·Library Cache
·Data Dictionary Cache
·SQL Query Result Cache
·PL/SQL Function Result Cache
·Buffers for parallel execution messages
·Control structures

1. Library Cache Lock 的本质
library cache lock 用于控制多个客户端（Session）对同一对象的并发访问，它是：

在对象句柄（object handle）上获取的锁
用于保证：
某一时刻只有合法的访问者可以操作对象
对象在被依赖期间不被修改
其获取过程包括：
1.获取 library cache 子锁，扫描对象句柄列表
2.找到目标对象后，在句柄上放置 library cache lock

2. 它意味着什么？
一个 Session 正在：
·解析 SQL
·编译对象
·执行依赖对象的 PL/SQL
·另一个 Session 想：
·使用同一对象
·修改 / 失效该对象
此时就会产生 library cache lock 等待。

二、如何在报告中识别
library cache lock
1. TKProf
Overall wait event summary
·non-recursive / recursive statements
·library cache lock 等待时间显著
2. AWR / Statspack
·Top Wait Events 中出现：
library cache lock
·Library Cache Statistics 异常

三、常见成因一：SQL 因文字值无法共享（硬解析）
问题描述
SQL 本可使用绑定变量，却使用了字面量（literal），导致：
·SQL 无法共享
·每次执行都触发硬解析
·频繁获取 library cache lock

定位方法
TKProf：
·按 parse time 排序
·检查：
Misses in library cache ≈ Parse count
·查找 SQL 中是否存在大量文字值

解决方案
重写 SQL，使用绑定变量
优点：
·显著提升 SQL 共享率
·降低硬解析与 library cache 争用
代价与风险：
·费劲程度：中 / 高
·风险：中
可能影响执行计划
必须充分测试

验证方式
实施后重新分析：
·AWR
·TKProf
若无改善：
·重新确认是否为主要原因

四、常见成因二：共享池过小，已共享 SQL 被刷出
问题描述
·Shared Pool 太小
·可共享 SQL 被频繁老化
·再次执行 → 硬解析 → library cache lock

定位方法
AWR / Statspack：
·Library Cache Statistics：
Reloads 很高（每小时几千）
Invalidations 很少
·% SQL with executions > 1 > 60%

解决方案一：增大 Shared Pool
·费劲程度：低
·风险：低
除非物理内存不足

解决方案二（10g+）：启用 ASMM
·设置：
SGA_TARGET
SGA_MAX_SIZE
·自动调节共享池大小

解决方案三：Pin 关键对象
·使用：
DBMS_SHARED_POOL.KEEP()
保留：
·大型
·高频使用
·PL/SQL / Cursor
风险：
·中度风险
·过度 pin 可能引发 ORA-4031

五、常见成因三：Library Cache 对象失效（DDL / 统计信息）
1. DDL 导致失效
·CREATE / ALTER / DROP
·级联失效依赖游标
·引发大量硬解析

解决方案：
·避免在繁忙期执行 DDL
·安排到维护窗口

2. 收集优化器统计信息
·ANALYZE
·DBMS_STATS

影响：
·对象失效
·大量硬解析

解决方案：
·避开高峰期
·使用 no_invalidate（10g+）

3. TRUNCATE 操作
·本质是 DDL
·同样会引发对象失效

解决方案：
·延后到低负载时段

六、常见成因四：跨 Session 编译对象
问题描述
·一个 Session 编译对象（PL/SQL）
·另一个 Session 正在执行 / 解析该对象
·出现 library cache pin / lock 等待

定位方法
TKProf：
·library cache pin waits
·伴随对象编译行为

解决方案
·避免并发编译
·避免高峰期编译
·使用 HangAnalyze 定位阻塞链

七、常见成因五：开启审计（尤其 RAC）
问题描述
·审计会增加 library cache lock 获取频率
·RAC 中影响更明显（全局资源）

定位方法
AWR / Statspack：
·library cache lock waits

参数：
·audit_trail != none

解决方案
·评估审计必要性
·非强制合规场景可关闭

风险：
·低风险
·但需考虑合规要求

八、常见成因六：RAC 环境中的非共享 SQL

典型特征
·单实例：表现为 latch 争用
·RAC：表现为 library cache lock

定位方法
·TKProf：
大量硬解析
·AWR：
% SQL with executions > 1 < 60%
Soft Parse Ratio < 80%
解决方案一：绑定变量
（同原因一）

解决方案二：CURSOR_SHARING 参数
·EXACT（默认）
·FORCE
·SIMILAR
建议：
·优先 Session 级设置
·避免 Instance 级 FORCE

风险：
·中度风险
·可能导致执行计划劣化

九、常见成因七：大量使用行级触发器
问题描述
·行级触发器频繁触发
·每次触发：
检查 mutating table
获取 library cache lock

关键点：
触发频率比触发器数量更重要

定位方法
·TKProf：
硬解析多
recursive SQL
trigger 相关痕迹

解决方案
·评估是否必须使用行级触发器
·设计替代方案

风险：
·中度风险
·需充分测试

十、常见成因八：过多的子游标（Version Count）
问题描述
·单条 SQL 生成大量子游标
·多 Session 并发创建 → 争用加剧

定位方法
·AWR：
SQL ordered by Version Count
·V$SQLAREA.version_count > 500
·V$SQL_SHARED_CURSOR

常见诱因
·CURSOR_SHARING = SIMILAR
·范围谓词（>、<）导致计划差异

解决方案选择
·重写 SQL 使用绑定（最佳）
·或改用 CURSOR_SHARING = FORCE（有风险）

十一、总结：排查library cache lock的正确姿势
一句话原则：

先判断是不是“非共享 SQL”，再判断是不是“对象失效或并发编译”，最后才考虑参数和内存。

实战顺序建议：
1.TKProf 看解析
2.AWR 看共享率 / Reload
3.排查 DDL / Stats / Compile
4.再谈参数调整

欢迎光临重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛 (http://bbs.cqsztech.com/)