AWR实战分析之---- PX Deq Credit: send blkd (转载)

该等待事件我在前面分析过,但是这次和上次产生的原因有些不一样,上次该等待事件的详细分析链接是:http://blog.sina.com.cn/s/blog_61cd89f60102eeen.html ,本次原理和上次是一样的,但是引起的原因很典型,记录一下排查过程。

AWR实战分析之---- PX Deq Credit: send blkd (转载)

结合发生的时间点,从上图我们可以看出,此时数据库负载相对较高,我们年看load profile部分情况
AWR实战分析之---- PX Deq Credit: send blkd (转载)

从load profile模块来看,数据库解析比较严重,并且事务数和每秒登陆次数明显有异常,但是我们还需要结合TOP 5等待事件来看数据库在等什么?
AWR实战分析之---- PX Deq Credit: send blkd (转载)
     从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然后再去分析执行计划

AWR实战分析之---- PX Deq Credit: send blkd (转载)
    第一条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等待事件

AWR实战分析之---- PX Deq Credit: send blkd (转载)
     该类等待事件处理方法也很简单,将索引degree改为1即可,具体操作方法是:

alter index index_name noparallel;
     原因找到了,发给项目组让开发的同事在创建索引时注意此事项,并进行修改就可以了!

http://blog.sina.com.cn/s/blog_61cd89f60102ef1p.html

上一篇:linux:网络yum源和制作本地光盘yum源


下一篇:read by other session 等待事件。