等待事件：latch:library cache

本篇整理内容是本周四晚李华在“云和恩墨大讲堂”中授课的课件资料

故障分析 - library cache latch 竞争案例分享

 

背景介绍

 

客户的一套重要生产系统，出现了性能问题。这个问题涉及的信息如下：

月底时候数据库主机的 CPU 利用率长期在100%左右。

数据库中出现大量的 latch: library cache 竞争

 

系统概况

---

该系统为 OLAP OLTP 混合系统,平时为交易型数据库。每个网点实时数据上传,月底会有统计类报表产生。

 

以下为数据库负载曲线，可以看到在月底复杂急剧上升，导致业务不能正常操作。

 

 

以下为故障时间点部分 AWR 截图。

 

 

从 LOAD PROFILE 看当前数据库每秒有158次的硬解析，总的解析在1082次。

 

这个时间点的 TOP 5 等待事件中 latch: library cache 与 kksfbc child completion 排在前列，library cachelatch 占到将近有 70%。

 

Latch: Oracle 用于控制内存并发的串行锁机制

 

共享池 latch 竞争一般导致的原因有以下集中:

 

1. literal SQL 所谓的 literalSQL 就是没用使用绑定变量值的 SQL 比如 select * from enmo where id=100;

2. 硬解析比如一个新执行的 SQL 没有在共享池中,那么就要经历一个硬解析的过程，关于过程这里就不在多讲

3. SQL 不能共享，不能共享的原因有很多比如没有在同一个用户下面执行

4. SQL VERSION 大量高版本 SQL 也会导致共享池的竞争

5. 另外就是主机出现大量换页，比如在 AIX 环境下大量计算内存使用了 SWAP 会导致类似的问题

6. 还有就是查询一些底层的视图比如 x$ksmsp 在某些版本下高并发的系统中直接查询这些视图会出现大量的 latch 竞争

7. 还有就是 SGA 大量抖动或者模拟调整的时候也会导致此问题

8. Oracle 各个版本上也存在相关的 BUG 会导致

 

根据以上几点我们去分析到底此问题出现在什么地方。

 

首先数据库等待事件除了 library cache latch 之后就是 kksfbc

K[Kernel]K[Kompile]S[Shared]F[Find]B[Best]C[Child]

 

该函数用以在软解析时找寻合适的子游标，是否该故障是由于大量 VERSION COUNT 引起呢？

 

 

从这个时间点 AWR 来看没有看到大量 version count 的SQL出现。

分析 latch 的时候 AWR