一条报警信息的快速处理和分析(r9笔记第99天)

时间:2022-05-04
本文章向大家介绍一条报警信息的快速处理和分析(r9笔记第99天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

下午的时候收到这么一条报警。 ZABBIX-监控系统: ------------------------------------ 报警内容: Too many parallel sessions on xxxxx_xx机房_xxxxx ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: parallel_session_cnt:66 ------------------------------------ 报警时间:2016.08.22-17:27:54 这个报警的意思是并行会话数达到了66个。已经远超出了阈值。

在几分钟后我又收到了恢复的邮件,可见问题自动修复了。那这个问题该怎么解释呢。 如果通过AWR来定位很可能捕捉不到这个抖动,而且把AWR快照的收集频度降低本身也不能完全解决问题,所以这个时候就需要借助ASH了。 对于ASH生成报告而言,我对于里面需要设置的时间格式深恶痛绝,所以在很早之前就做了简单定制,手工输入两个时间戳,还可以灵活调整范围,很快就定位到了一条语句。 可以看到在时间范围内的SQL基本都是从Orabbix端触发的,而这里有一条语句引起了我的注意。

其它的语句都是查询数据字典的信息,而蓝色部分标示的这条语句一看就是应用层面的。查看执行计划,马上就明白了原委。

这条语句做了全表扫描,因为数据量巨大,所以执行效率低下,而且同时启用了并行,所以相对来看执行效率还可以,但是由此可见系统层面的资源消耗会非常大。 所以问题又来了,为什么全表扫描,启用了并行,怎么会有66个并行会话。看这个语句似乎也没有什么Hint的痕迹。 那么这个问题的原因就更加容易定位了。 SQL> select degree,table_name from dba_tables where table_name='TEST_VIP_NEW' and owner='TEST’; DEGREE TABLE_NAME -------------------- ------------------------------ 32 TEST_VIP_NEW 可以通过这个配置看出并行度为32,所以问题的原因就马上可以定位出来了。现在的问题是这个语句存在性能问题,一方面会导致大量的资源耗费,二来执行时间也相对比较长,为什么这个大的表执行效率会如此差呢,问题的方向应该在于索引,排除了其它的因素,发现这个表的数据千万级,存在几个索引,但是唯独这个语句where条件中的字段不存在相关的索引,而这个问题可以进一步分析和查看,其实就是根据rank=0,grade=0来得到结果集,从执行计划可以看出这个结果集非常大,其实就算是得到了对应CN列值,本身处理起来也是一个很庞大的工程。所以这个语句从应用层面来看也是存在问题。而另外一个就是并行度,这个表的并行度有些太高,可以适当做一个调整,同时结合起来和开发同学做进一步的确认。我想这个问题在监控体系之内应该是不会报警了。