DPA在电信计费系统故障诊断案例

3月20日中午,电信客户的计费系统故障,所有操作响应缓慢,应用无法正常运行。现场DBA已经迅速将应用连接转移到RAC集群的另一节点,恢复应用服务,我们使用DPA来回看事故现场,此时离故障发生,已经一小时了……

回溯负载情况,如下图

 

问题最严重时,实例堵塞了近700个连接操作…针对此时间段,进一步点击、下钻分析当时系统发生了什么

系统先是每分钟4~5次堵塞(像是咳嗽),到了13:40后,就处于长时间“梗”住的状态,对于外部业务来说,数据库实例已不可用了。

 

利用DPA,继续下钻,查看堵塞原因:

1654#会话导致80个会话被堵塞,这80个会话的等待事件是 sga:allocation forcing component growth,这80个会话中的一些会话又堵塞了一些其他会话,如下图

266号会话堵塞了3个会话,这三个会话的等待事件都是cursor:pin s wait on x,这个等待事件一般都是跟sql parse相关,所以,现场工程师开始查看oracle 自己的ADDM报告,说是解析有问题,建议应用分析解决问题…被误导了

 

至此,DPA下钻后清晰显示,堵塞的根源是1654号会话,DPA显示是MMAN进程,它堵塞了80个会话,这些会话又堵塞了更多其他会话,是一个3级的堵塞关系,幸好DPA以“树型”显示方式,把这种多层级堵塞关系显示的非常清晰。

结论:Oracle MMAN进程进行过于频繁的SGA内存组件(本例中是share pool)resize操作,导致了问题…

 

这张图中显示的share pool内部情况,看官能看出异常么?

 

“划一条线1美元,知道在哪里划线9999美元”。

至此,后续我们如何解决这个问题的就不再讨论了,解决问题从来不是难事,难的是发现问题。

后记: 从DPA的负载雷达上,我们看到在系统出现问题之前的一小段时间内,系统负载不正常的降的很低,其后负载飙升上去…… 那段时间负载异常降低,说明了什么? 应用程序发生了什么…… 这些从Database Performance Analyzing层面,就无从知晓了。

Leave a Reply to thedopamineflux Cancel reply