以前和一个朋友讨论通过异常检测的方法去分析某个故障的产生原因，我们是通过知识图谱找到与这个故障现象有关的指标，经过对这些指标做异常检测发现其中存在的问题，然后再根据这些问题进行归类分析，找出问题的主因和次因。他觉得既然异常检测算法与问题归类算法都已经比较完备，还通过知识图谱去收集指标集干嘛，干脆用全量指标集去计算好了，虽然算力要求比较高，不过大部分企业还花得起这个算力的。
实际上算力并不是主要问题，主要的问题是我们的系统往往是处于亚健康状态的，平时系统中就有这个那个的问题，有一些性能瓶颈。这些问题是常态化存在的，很可能和发生的故障无关，如果拿全量指标去做分析，那么诊断结论里就会掺杂一些和这个故障无关的因素在里面。
做优化工作也是如此，很多朋友在做Oracle数据库优化的时候，会抓取AWR报告，然后根据TOP EVENT从上到下分析一遍，把存在的问题解决掉。实际上有时候这种做法会适得其反。
从 TOP EVENT，你的第一反应是什么呢？肯定绝大多数DBA会认为共享池出问题了，CURSOR争用很严重。
如果我们来看LOAD PROFILE会发现什么呢？每秒执行量很小，只有几百，每秒解析的数量也只有几百。我们再来看看命中率指标。
LIBRARY HIT 指标只有89%，有些朋友就会说，SQL解析出问题了。实际上当时参与这个项目的有位专家也提出了这个问题，建议开启CURSOR_SHARING，降低硬解析的比例。实际上我们不能仅仅看几个指标就下结论。首先这个系统中NO-PARSE CPU的比例很高，说明解析对系统的影响并不大。哪怕解决了SQL解析的问题，对系统整体性能的提升是帮助不大的。而对于ERP系统这样十分复杂的，大多数是人操作的系统，SQL的并发执行量是有限的。在这个系统业务高峰期比较正常的时候，每秒执行数的一小时平均值也只有5000多。使用CURSOR_SHARING或者全面使用绑定变量并不一定是一件好事，这会增加执行计划错误的机会，从而引发更为严重的性能问题。
为什么这个系统会出现如此严重的CURSOR问题呢，我们先来看一下OS的情况，LOAD居然高达2814，对于一个128核256线程的服务器来说，这个值相当地高。
在CPU上%SYS的比重极高，这是因为严重的闩锁和MUTEX冲突引起的。实际上我们只要找出引起这些等待的SQL语句就可以了。通过V$SESSION我们很容易可以找出这些SQLID。并且根据我的猜测，肯定这些SQL是相同或者类似的。
在这个系统中，经过分析我们发现，是几条创建全局临时表的DDL引发了CURSOR的争用。这其实应该是应用的一个BUG导致的，而并不是因为SQL 硬解析过大引发的问题。如果我们判断错了问题，采取了错误的优化手段，可能会引发更大的危机。
对于刚刚参加优化工作的DBA来说，我今天说的这个问题是个常见问题，没有抓住重点，从主要矛盾入手去解决问题，那么很可能在小河沟里翻船。我最近参与的这个项目，经过几天的救火，昨天终于出现了好转的迹象。虽然用户使用起来还不爽，不过系统基本上可用，不会出现长时间无响应的情况了。消除掉了前面的瓶颈，系统中让应用变慢的最核心的问题也逐渐露出来了。
从昨天的监控数据看，r队列得到了有效的控制，活跃会话数也从2000+下降到了一个比较合理的范围，CPU也出现了空闲。不过RAC集群流量从前两天的4-50MB提高到了100M左右，单个节点的每秒REDO量也达到了新高，两个节点都超过了30MB/秒。不过目前这些问题还都在可控范围内，本阶段工作的成效已经看得很清楚了。下一阶段的优化工作才是真正解决用户感觉系统太慢的主要原因。这种情况下，问题的主要原因分散了，优化工作的覆盖面就更大了，因此工作也需要做得更为细致了。
