下午的时候收到这么一条报警。 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列值，本身处理起来也是一个很庞大的工程。所以这个语句从应用层面来看也是存在问题。而另外一个就是并行度，这个表的并行度有些太高，可以适当做一个调整，同时结合起来和开发同学做进一步的确认。我想这个问题在监控体系之内应该是不会报警了。
