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