前言
好消息！本期，小编终于第一次邀请到了中亦科技数据库团队的老猫（mason）做为我们的分享嘉宾，撒花，兴奋，捂脸！
老猫，混迹DBA江湖30载有余,小编心中的真正大神级人物，同时也是我们的段子大湿，为我们team和客户带来了无数的欢乐。
老猫平时行事低调，网上几乎看不到他的文章，说话做事从不啰嗦，文中未尽事宜可加他的微信，masonchen_2015 进一步交流。
接下来下面我们直接来看看看中亦老猫飘逸的故障处理过程，以及文末从案例分享提炼出来的共性风险提示吧

01问题描述

客户新投业务模块，需要做压力测试，在测试压力并不大的情况下，数据库的性能竟然很差。其中AWR报告显示有大量的异常等待事件，客户首先怀疑的是数据库配置不合理导致的，于是第一时间收集了相关信息发了过来。

02分析中。。。

首先，我们来看看AWR报告能提供的信息：

图中显示10分钟的AWR报告中，DBTime繁忙达到了385分钟，那么真的是从应用端上来的压力太大吗？
继续检查发现系统的CPU时间还是很低的，可以认为数据库平均才使用0.6颗CPU，大多时间还是花费在了等待上；

接下来查看TOP等待事件：

主要的等待事件是在cursor:pin S wait on X和library cache lock上，两项分别占了DBTime的42.8%和32.3%，均与解析相关，此点可以在AWR报告的time model部分中进一步确认：

报告中的Load profile告诉我们每秒的硬解析次数达到200次，这个数据一定会出现问题！！！

03猜测与验证

压力测试理论上是不应该出现大量硬解析的，老猫猜想是不是应用设计不合理（比如没有使用绑定变量）导致的呢？

但是当看到AWR报告中的“Library Cache Activity“部分时，发现SQL AREA部分存在大量的Reloads 和Invalidations时，果断的推翻了之前的猜测。
于是我们进一步收集ASH报告中问题时刻的librarycache lock等待对象的namespace；

从数据中可以看出：P3值为5373954，将其转换为16进制就是0x520002，将0x52继续转为10进制就是82；
在ASH报告中，问题发生在『SQL AREABUILD』这个NAMESPACE上，这块内存是在构建Child Cursor时请求的，如此频繁地出现，基本可以排除收集统计信息，DDL引致的硬解析，但我们依然要求证！幸运的是，客户DBA非常资深，顺便给了systemstate dump；
从中看到一条关键记录：

这是一个存储过程，硬解析次数334108次，cursor失效次数334107次，执行次数0次，明显的解析失败。

04疑问与解答

再回过头来看之前的time model，还是能看到存在的错误解析的情况：

强调一下：作为一个负责任的第三方运维工程师，必须要要协助客户把问题缩小到最小粒度，才能准确定位硬解析失败的原因。
那么新的问题来了：解析失败，对于一个比较复杂的存储过程来说，我们怎么快速的定位到是什么语句什么原因导致的失败解析呢？
答： oracle提供了一系列的跟踪事件来帮助定位各种问题，下面介绍的这个方式一定可以找到一些event来进行跟踪：

搞定，原来10035事件可以帮助到我们，那么我们只要在系统级设置上10035事件就可以了：

因为客户也是一位资深的DBA，主要的原因已经找到，余下的事情自然就不需要我们帮忙，最后他从alert log果然找到了解析错误的SQL，并且解决了问题。

我们学到了什么！

老猫的经验分享完毕，我们可以总结为两点：
根据个人以往的经验，SQL错误在功能测试阶段未必能完全测试完成，特别是一些应用代码中存在着SQL拼接的情况时更是容易出现SQL错误的情况；
通过CASE可以看出，错误SQL带来的影响绝对不仅仅是在功能上的缺失，同时也会对数据库的整体性能产生影响，继而影响测试结论；
综合上述两点，小编给出的建议是：在测试环境中，在系统级开启10035跟踪事件，及时发现错误SQL的情况，才不会影响后续的生产哦
那么今天的小分享就先到这里，下期我们将会请来哪位大咖呢~~