公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2015-08-27 23:37:16 · 原文链接

在使用orabbix进行监控的时候，得益于使用 实时DB time监控的选项，对于几分钟内的性能抖动也能够狠容易的记录下来，而且会把这个监控的结果基本真实反应出来，不会随着两个快照的间隔被平均，这样性能问题的分析和排查如虎添翼，我直接通过性能抖动的情况就能够快速定位在哪个时间段内可能存在问题，然后借助ASH就可以得到一个更具有针对性的报告，可以精确到1分钟甚至秒级。
可以看到在早上的七点左右的时候还是有一些明显的性能抖动，DB time会瞬间提高。

这对于一个OLAP的系统来说还是有些不正常的。
并行session的情况如下，可以看到在问题发生的时间段里，产生了大量的并行session.

而且同时我也收到了orabbix的告警邮件。

监控项目: Session Active：153
*UNKNOWN*：*UNKNOWN*
————————————
故障时间:2015.08.27-07:22:04
所以这个问题还是需要关注一下，这种情况就犹如给一个静坐的人用针突然扎一下，会出现很明显的性能抖动。
首先为了进一步验证，得到了在快照时间内的负载信息，可以看到在问题发生的时间内DB time还是蛮高的。
BEGIN_SNAP END_SNAP SNAPDATE DURATION_MINS DBTIME
———- ———- ——————————— ———-
36343 36344 27 Aug 2015 04:00 60 85
36344 36345 27 Aug 2015 05:00 60 118
36345 36346 27 Aug 2015 06:00 60 150
36346 36347 27 Aug 2015 07:00 60 180
36347 36348 27 Aug 2015 08:00 60 137
36348 36349 27 Aug 2015 09:00 60 140
36349 36350 27 Aug 2015 10:00 60 67
36350 36351 27 Aug 2015 11:00 60 8
所以说得到了上面的信息，能够让我们更加清楚问题的背景和基本情况。
查看alert日志，在问题发生的时间段里，没有看到其它异常的信息。
Thu Aug 27 00:07:08 2015
Archived Log entry 63315 added for thread 1 sequence 688962 ID 0xa4527950 dest 1:
Thu Aug 27 00:07:23 2015
LNS: Standby redo logfile selected for thread 1 sequence 688964 for destination LOG_ARCHIVE_DEST_3
Thu Aug 27 00:07:32 2015
Archived Log entry 63317 added for thread 1 sequence 688963 ID 0xa4527950 dest 1:
Thu Aug 27 00:07:38 2015
Thread 1 advanced to log sequence 688965 (LGWR switch)
所以从数据库层面来说，可能没有什么明显的活动。
但是问题不可能无中生有，我们怎么去找到问题的根源呢，为了更加精确的定位问题，我们需要借助于ASH来还原那个时间段的问题情况。
为了排除Orabbix监控的延迟，我抓取的时间范围略大了些，是7分钟内的ash.
得到的报告如下，可以看到在问题发生的时间段内，取样数也确实蛮高的。