下面的分享是笔者在2月份处理的一起性能故障，笔者将分析过程分享出来，给大家起到抛砖引玉的作用。

接到XXX项目组报障：XX系统Connecttodatabasetimeout，请求协助检查数据库是否有异常。通过DPM检查数据库状态(现场所有交维，为交维的数据库都纳入了DPM)，发现大量cursor: pin S wait on X(数据库还未交维平台侧，纯友情协助)；

使用DPM下钻功能，找到阻塞sql；

通过查看DPM概览发现确实存在大量等待事件告警信息：

与业务侧紧急沟通核实，确定已造成业务积压，考虑到服务连续性，本着先抢通再核查根因的原则，经过应用侧同意，对堵塞会话予以查杀，以保证业务的连续性。堵塞会话查杀后，数据库恢复，业务恢复正常。

故障第一次分析：

采用故障时间段相关现场信息排除法进行相关分析。

• version count 信息

Version count正常，非此次故障原因，可排除。

• 相关负载及硬解析物理读等

硬解析在正常范围内，非此次故障原因，可排除

• DDL变动信息

相关对象最后DDL操作和此次故障时间不一致，可排除

• shared pool 变动信息

Shared pool 存在抖动情况，内存抖动是导致cursor: pin S wait on X等待事件发生原因之一；

• 会话信息

根据会话变动找出阻塞源以便排查原因；

• session变动量

故障时段session并发连接数量明显增加。

造成cursor: pin S wait on X几种原因：

• version count过高

• 硬解析过多

• 在问题时段有做DDL操作，导致异常阻塞

• sql用的对象使用了DBLINK访问，dblink不通

• shared pool抖动造成

• 业务变更

• 相关bug

根据故障时间段的相关数据一一排除version count、硬解析、ddl、dblink等原因，查找相关sql执行计划并分析，查找相关类似bug文档，排查相关原因分析，初步确定shared pool抖动为本次故障原因；

分析到这里时，客户侧也在催促结论，需要向上汇报。逐将上述分析过程整理发于客户侧。

2月22日第二次发生故障

晚上睡觉一直惦记着这事儿，整个晚上睡的都不踏实。早上到达现场第一时间登陆巡检发现问题复现，继续用排除法进行原因分析。

• 未共享sql

根据查询显示未绑定变量sql在正常范围内，非造成此次性能故障原因

• sga变动

通过awr显示sga存在内存抖动

• 查询源阻塞信息

为保障业务连续性，联系业务侧对堵塞会话予以核实及查杀。

业务恢复后继续分析：

造成抖动的ddl信息

• 查询相关官方文档

• 收集相关信息

进行故障时间段awr、ash、addm等报告的收集及shared pool变动信息查询并进行hang分析；

2月22日第三次发生故障

正在分析的时候，同事通过DPM实时监控发现问题再次出现，与业务侧核实后立马进行会话查杀，以防止影响业务感知。

根据addm报告、shared pool变化信息结合DPM等待事件相关故障开始时间等信息的联合诊断，确定shared pool过小是导致此次性能故障的原因，依据如下：

1、addm报告显示(见下图)，shared pool latches 对此次故障的影响；

2、对比shared pool数据与DPM所记录等待情况，发现在故障发生时，shared pool发生明显抖动且与等待事件发生时间一致。

Shared pool 和故障等待开始时间对应表格

原因找到，马上制定调整shared pool大小的解决方案，并紧急申请实施窗口。

实施方案如下：

参数修改后，数据库恢复正常

09：00实时监控未见异常；

12：00实时监控未见异常；

17：00实时监控未见异常；

21：50实时监控未见异常；

至此该性能故障解决完成。通过该性能故障的处理过程，我们发现在运维的过程如果现场有相关运维工具平台，对于日常工作及性能故障的处理都会起到事半功倍的效果。毕竟工欲善其事，必先利其器。