深入解析：由SQL解析失败看开发与DBA的性能之争
李华
云和恩墨高级技术顾问
编者注：在很多生产系统中，程序员经意不经意写下的一条SQL都可能带来性能上的巨大隐患，正确的、不正确的。而DBA就要不断在这些问题中出生入死，本案例描述的那些不正确的SQL可能给我们带来的麻烦，而这类错误SQL往往为大家所忽视。这样的问题在最近的客户案例中不断涌现，在12c中同样为我们带来麻烦，而很多DBA可能并不了解，转引这篇文章与大家为警示。
以下案例来自大讲堂的一次分享，从这个案例中我们可以了解“错误的SQL”可能对数据库产生的种种影响。如何找到这些错误的、解析失败的SQL呢？我们先把方法列举在这里：
通过关联 x$kglcursor x$kglcursor_child_sqlid 视图；
通过使用 Oracle 10035 Event 事件可以找到解析失败的SQL；
通过 oracle systemdump 也可以找到解析失败 SQL；
以下我们来看看这个精彩的案例分享。
背景介绍
客户的一套重要生产系统，出现了性能问题。这个问题涉及的信息如下：
月底时候数据库主机的 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 竞争一般导致的原因有以下集中:
literal SQL 所谓的 literalSQL 就是没用使用绑定变量值的 SQL 比如 select * from enmo where id=100;
硬解析比如一个新执行的 SQL 没有在共享池中,那么就要经历一个硬解析的过程，关于过程这里就不在多讲
SQL 不能共享，不能共享的原因有很多比如没有在同一个用户下面执行
SQL VERSION 大量高版本 SQL 也会导致共享池的竞争
另外就是主机出现大量换页，比如在 AIX 环境下大量计算内存使用了 SWAP 会导致类似的问题
还有就是查询一些底层的视图比如 x$ksmsp 在某些版本下高并发的系统中直接查询这些视图会出现大量的 latch 竞争
还有就是 SGA 大量抖动或者模拟调整的时候也会导致此问题
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 有一个非常重要的数据。
从 Latch Miss Source 的数据可以看到，绝大多数都是对于 shared pool latch 的 sleeps，
从 AWR Sleep 来看 shared pool 排在了第一位。从调用的函数来看都是发生在硬解析这个过程中。
以下为一些常见函数的功能:
Kghfrunp: KGH: Ask client to freeunpinned space
Kghdmp : x$ksmsp is a fixed table based onkgh metadata. The number of latch sleeps for "kghdmp" will increaseif x$ksmsp if an installation selectsfrom this fixed table too frequently.
kghupr1 : un-pin recreatable
kghalo KGH: main allocation entry point
kghgex KGH: Get a new extent
kghalf KGH: Non-recoverably allocate afreeable chunk of memory
有很多函数这里就不一一列举。
当前现在也可以排除人为查询底层视图导致的 latch 竞争因为没有看到相关函数出现，插播一个类似的案例。
像这种情况很明显就是有人查询了底层的视图导致的 shared pool 竞争。
从主机最早的信息来看也是没有 SWAP 竞争出现的。
SGA 没有大量的 resize 也可以排除掉由于 SGA 组件抖动引起的。
从以上信息，我们没有找到想要的结果，那么问题出现在哪里。
把上面几个原因都排除掉了，难道真是遇到 Oracle BUG 了么。
有的时候分析问题会陷入一些误区，比如一个数据库出现大量的 latch 竞争导致会话飙升然后把 process 撑满，从 time mode 里面来看的话可以发现 95%都是花费在了连接上面,那么到底是大量不正常的连接(比如连接泄漏)导致了数据库出现竞争呢，还是数据库出现问题导致会话不能等了然后不停的重连导致了问题呢。
从这个库这个时间点的 time mode 可以发现 75%的 db time 都是花费在了解析上面，这也是没有问题的因为这个时间点数据库竞争就出现在解析上面，但是为什么其中有 38%的 db time 发生在解析失败上面呢，也就是总共解析的一般时间都是错误的解析。硬解析只有5%左右。
我们来看一张正常时间点的 time mode 。
