以前和一个好友探讨经过意外检测的方法去剖析某个缺点的发生要素，咱们是经过常识图谱找到与这个缺点现象有关的目的，经过对这些目的做意外检测发现其中存在的疑问，而后再依据这些疑问启动归类剖析，找出疑问的主因和次因。他觉得既然意外检测算法与疑问归类算法都曾经比拟完备，还经过常识图谱去搜集目的集干嘛，罗唆用全量目的集去计算好了，只管算力要求比拟高，不过大局部企业还花得起这个算力的。
实践上算力并不是关键疑问，关键的疑问是咱们的系统往往是处于亚肥壮形态的，往常系统中就有这个那个的疑问，有一些性能瓶颈。这些疑问是常态化存在的，很或许和出现的缺点有关，假设拿全量目的去做剖析，那么诊断论断里就会掺杂一些和这个缺点有关的要素在外面。
做优化上班也是如此，很多好友在做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/秒。不过目前这些疑问还都在可控范围内，本阶段上班的功效曾经看得很分明了。下一阶段的优化上班才是真正处置用户觉得系统太慢的关键要素。这种状况下，疑问的关键要素扩散了，优化上班的笼罩面就更大了，因此上班也须要做得更为粗疏了。