elapsed 诊断案例：Failed parse elapsed time引发db time过高的案例

作者|卢:云和恩墨交付工程师，有多年数据库运维经验，擅长数据库性能优化和数据迁移，长期服务于政府、能源、通信等行业客户。

在awr的时间模型统计中有一个失败的解析运行时间指示器，它指的是执行SQL解析所花费的时间，最终由于一些解析错误而失败。在12.2版之前，我们可以通过事件10035来跟踪这个异常的根本原因。对于12.2版，我们可以在alert中直接查看分析。

抽象的

这几天遇到一个awr，发现它的db时间比平时高200倍左右，这个时间段(大概一个小时)的对话是平时的两倍，但是对应awr中Load Profile的一些指标，比如执行、事务、重做大小等。，而不是通常的减少，这引起了我的好奇心，所以我想探索。

1.awr分析

下图显示了高负载期间的awr

从上面可以看出，DB Time为2458.93分钟，平均每秒40.98 dbtime，也就是说，节点1的活动会话数平均为40.98(不包括数据库后台进程会话)。对于8 cpus的服务器，DB占CPU资源的512.25%。

我们在看一段正常的db时间(我的一个随机截图，通常db时间在80到120左右)

比较负载概况中的信息

通过比较大多数负载概况指标，可以发现事务量、解析次数、日志、执行频率等。正常时期的低于高负载时期的，这意味着系统的运行效率在高负载时期下降，或者系统的运行没有随着会话(业务量)的增加而增加。

根据前5条，发现SQL*Net break/reset到客户端先等待。

使用db_link时，如果应用运行不正确，服务器端本地服务进程会将信息通知给远程客户端，服务进程在通知过程中等待SQL*Net break/reset给客户端，直到客户端收到问题信息，这种情况一般是应用端捕获异常不够造成的，可以通过10046事件捕获。

但是，我今天想研究的是下面这个。在这个环境下，它呼应了上面的等待事件，因为这个系统中的大量数据操作都是通过dblink实现的；

失败的解析运行时间意味着当我们的sql被硬解析时，出现了一个错误。错误的主要原因可能包括:SQL语法错误、对象不存在、权限不足。我们正在查看高负载期间的实例活动统计数据

硬解析次数143次，解析失败次数已达131次。我们看到的是一段正常的时间

我们可以通过10035事件观察解析sql失败的操作，找到问题语句，从而改善代码处理逻辑，降低解析失败的概率，一定程度上减少了SQL*Net break/reset对客户端等待事件的影响。

其次，测试环境模拟10035来观察失败的sql

创建一个测试表；

SQL >从v$mystat中将表aa创建为select *,其中rownum & lt6;

表已创建。

SQL >desc aa；

名字Null？类型

- - -

样本号

统计数字

计算值接收数

打开10035事件，做一些错误sql；

SQL >从aa中选择sdi1

从aa中选择sdi1

*

第1行出错:

ORA-00904:“SDI 1”:无效标识符

SQL >更新aa set sid=sysdate，其中value = 0；

更新aa set sid=sysdate，其中值=0

*

第1行出错:

ORA-00932:不一致的数据类型:预期的数字得到日期

SQL >从抄送中选择*；

从抄送中选择*

*

第1行出错:

ORA-00942:表或视图不存在

检查跟踪日志

Fri 2016年5月06日05:05:04

PARSE ERROR: ospid=23029，语句的error=904:

从aa中选择sdi1

附加信息:HD = 0x 861 a 7168 PhD = 0x 861 DFC 90 flg = 0x 20 cisid = 0 sid = 0 ciid = 0 uid = 0

Fri 2016年5月06日05:06:10

PARSE ERROR: ospid=23029，语句的error=932:

更新aa set sid=sysdate，其中值=0

附加信息:HD = 0x 85132 Fe 8 PhD = 0x 853760 b 0 flg = 0x 20 cisid = 0 sid = 0 ciid = 0 uid = 0

Fri 2016年5月06日05:06:43

PARSE ERROR: ospid=23029，语句的error=942:

从抄送中选择*

附加信息:HD = 0x 852332 a 0 PhD = 0x 8524d 360 flg = 0x 28 cisid = 0 sid = 0 ciid = 0 uid = 0

通过10035事件，可以帮助我们发现程序中需要改进的不完善的sql语句；作为临时解决方案，您还可以调整_cursor_features_enabled的隐藏参数。对于具体的调整方式，可以查看mos文档:

如何识别硬解析失败(文档号1353015.1)

解决由于在分析/执行时SQL接收错误导致的高“分析失败运行时间”问题(文档标识1476070.1)