ITPub博客

首页 > 数据库 > Oracle > 技术人生系列·我和数据中心的故事(第十二期)-风险预警·如何预防开发问题流到生产

技术人生系列·我和数据中心的故事(第十二期)-风险预警·如何预防开发问题流到生产

Oracle 作者:记录每一次错误 时间:2018-12-03 14:04:09 0 删除 编辑

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


1
问题描述

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

2
分析中。。。

     首先,我们来看看 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 次,这个数据一定会出现问题!!!

3
猜测与验证

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

     但是当看到 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 次,执行次数 次,明显的 解析失败

4
疑问与解答

   再回过头来看之前的 time model ,还是能看到存在的错误解析的情况:     强调一下: 作为一个负责任的第三方运维工程师,必须要要协助客户把问题缩小到最小粒度,才能准确定位硬解析失败的原因。

那么新的问题来了:解析失败,对于一个比较复杂的存储过程来说,我们怎么快速的定位到是什么语句什么原因导致的失败解析呢?

答:   oracle 提供了一系列的跟踪事件来帮助定位各种问题,下面介绍的这个方式一定可以找到一些 event 来进行跟踪:

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

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

我们学到了什么!

老猫的经验分享完毕,我们可以总结为两点:

  1. 根据个人以往的经验, SQL 错误在功能测试阶段未必能完全测试完成,特别是一些应用代码中存在着 SQL 拼接的情况时更是容易出现 SQL 错误的情况;

  2. 通过 CASE 可以看出,错误 SQL 带来的影响绝对不仅仅是在功能上的缺失,同时也会对数据库的整体性能产生影响,继而影响测试结论;

综合上述两点,小编给出的建议是: 在测试环境中 ,在系统级开启 10035 跟踪事件,及时发现错误 SQL 的情况, 才不会影响后续的生产哦 ~~


本文转载于中亦安图的文章


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547066/viewspace-2222466/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
性格开朗,有较强的学习能力,对oracle数据库的体系结构,搭建RAC,timesten,goldengate,分布式数据库,dataguard,系统调优有较深入的了解, 尤其是oracle优化,深入学习的主机命令,对数据库的优化,SQL语句的优化有深入的认识,目前正在shell脚本,mysql,以后会有计划学习大数据和python。

注册时间:2018-07-23

  • 博文量
    182
  • 访问量
    326115