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,是否有潜在的阻塞和锁的情况，都是一目了然。

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