Oracle故障分析的几点小结

这是学习笔记的第 1851篇文章

今天分析了几类Oracle问题,也算是深有感触。

第一个是协助老同学排查一个性能故障,根据反馈每周的周日跑批量任务前端都会卡住,没有响应,之前拿到AWR分析了下,做了一些系统层面的优化,但是根据后续的跟进,说还是有批量任务卡住的情况。

AWR的部分信息如下:

这张图的信息量非常大,如果分析不够深入,很可能会漏掉一些关键的信息。当然仅仅靠一个报告把问题的前因后果都脑补出来也是不现实的,我等下会给出几个建议。

通过这个报告可以明确的看到这是一个小机环境的数据库环境,DB time指标很高,有近80倍。

而通过profile的信息可以明确的看到,每秒的redo有5M多,值得一提的是每个事物的redo量是11M左右,可以换算为每2秒是一个事务redo的写入量。一个事务11M的redo从哪里来呢,可以看下Executes和 User calls来辅助,可以得到一个相对粗略的估算,那就是一个事务包含大约1300个左右个SQL。按照这个比例,这个事务的粒度确实有些太大了。

而另外一个指标是Rollbacks的指标看起来是0.3,而相比于Transactions为0.5,这个0.3就有点高了,也就意味着事务回滚率是很高的。

只有为什么等待这么高,我们可以看下相关的SQL

可以明显看到问题,那就是很多insert SQL的执行次数为0,是什么情况会导致insert阻塞呢,本身insert操作应该是最直白的一类DML了,是最不应该被阻塞的了。

对于上面的信息我们其实得到的是一个模糊的印象,最近怎么样,1点的时候性能差,那么2:00呢。最近的性能怎么样,其实我们是应该要了解的。

怎么得到这些信息呢,抱歉Oracle原生似乎没有提供这些信息。

我们可以借助于自定义的脚本。

脚本可以参考之前的开源项目: 个人的小项目dbm_lite开放了

脚本showsnap.sh的输出如下。可以看到一个性能的变化情况,对于分析问题的方向是很重要的。

我们可以通过这个脚本来得到redo的切换情况,脚本是showarchrate.sh

通过这个就可以清晰的看到最近一段时间的性能变化,redo的切换是一个非常有效的指标,通过它来反应数据库的负载也是一种比较好的方式。

而对于问题的分析如何深入呢,我守在了电脑前,做了认真的分析,对于一个数据库,产生了上千连接的情况下,如何去定位性能瓶颈呢,最好的一种方式就是ASH,但是显然ASH有一个问题,那就是少了很多会话层面的明细信息,让我们知道问题,但是得到的信息还是有限,所以我们还需要另外一个脚本getash.sh来实时得到活跃会话的数据。

比如通过这个脚本的输出我们清晰的定位到现在在执行哪些SQL,是否有潜在的阻塞和锁的情况,都是一目了然。

通过这种方式定位问题如虎添翼。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-01-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券