该等待事件我在前面分析过,但是这次和上次产生的原因有些不一样,上次该等待事件的详细分析链接是:http://blog.sina.com.cn/s/blog_61cd89f60102eeen.html ,本次原理和上次是一样的,但是引起的原因很典型,记录一下排查过程。
结合发生的时间点,从上图我们可以看出,此时数据库负载相对较高,我们年看load profile部分情况
从load profile模块来看,数据库解析比较严重,并且事务数和每秒登陆次数明显有异常,但是我们还需要结合TOP 5等待事件来看数据库在等什么?
从TOP 5我们可以看到,数据库发生了严重的并行等待,PX Deq Credit :send blkd的原理是:
1.有大量的不同进程之间的数据和信息的交互导致等待,原因可能是一个比较糟糕的执行计划用于了并行执行。
2.等待是由于资源的问题,如CPU或相互连接等。例如CPU利用率达到100%,进程达到了CPU的限制,而不能足够
快地发送数据。
3.由于并行查询hang住,如等待事件为"PX Deq Credit: need buffer"。
说明: Deq = DEQUEUE,这是一个关于出队的等待; PX等待事件发生在并行查询的不同进程之间交互数据或信息时。 这些等待事件在系统负载很轻的时候,大都是没问题的,但是当系统的负载很重,此类等待事件已经进入top5等待事件中那就需要注意了。
结合该等待事件的原理我们进行排除,因为本案例中数据库服务器CPU使用率不高,并且没有出现"PX Deq Credit: need buffer"。 等待事件,那么我们可以排除第2、3两条,原因只有是第1条了,并行执行并且是糟糕的执行计划,我们先来看看TOP SQL是什么SQL然后再去分析执行计划
第一条SQL原因已经排除,我们重点关注标红部分,该SQL在这个时间点执行6697次多少有些异常,我们仔细分析一下SQL:
SELECT T.ID,
T.DEPTID,
T.DEPTNAMETYPE,
T.STARTDATE,
T.ENDDATE,
T.SUBPROCSSINSTID
FROM T_REPORT_REALTIME_ITEM T
WHERE T.GLOBLASN = :B1
ORDER BY T.SUBPROCSSINSTID, T.STARTDATE, T.ENDDATE
可以看出,该SQL其实是很简单的一条SQL,也没有hint使用parallel并行,但是问题到底出在那里呢?因为上次案例中是统计信息收集时我使用了degree属性导致的,这时我突想到索引创建时也可以使用parallel索引, 并且在网上看到过因索引degree引发的故障,下面来确认一下
select table_name, index_name, index_type, degree, partitioned, status
from dba_indexes
where table_name = 'T_REPORT_REALTIME_ITEM'
and degree > 2
结果还真是,该表中有五个索引使用了parallel方法进行索引创建,并且创建完成以后并没有将degree改为1,而且该表查询次数较多,导致数据库中产生严重的:PX Deq Credit :send blkd等待事件
该类等待事件处理方法也很简单,将索引degree改为1即可,具体操作方法是:
alter index index_name noparallel;
原因找到了,发给项目组让开发的同事在创建索引时注意此事项,并进行修改就可以了!
http://blog.sina.com.cn/s/blog_61cd89f60102ef1p.html