20141113理赔工作流系统核心数据源连接数过高分析-项目组.doc

理赔工作流系统核心数据源连接数过高分析 一、系统呈现现象及过程 1、2014年11月13日早8点40分，理赔工作流系统出现无法登录情况。 2、2014年11月13日早8点41分，理赔工作流系统核心数据源连接数超过130，无释放。 3、2014年11月13日早8点42分，理赔工作流系统数据源连接数正常，范围在10以内，登录人员数量为，操作不足以造成如此大量的数据源。 2014年11月13日早8点45分，与客户周凯确认，数据库压力正常，数据库系统状态良好，未有资源争抢情况。 2014年11月13日早8点45分，系统因无法登录，向客户周凯要求传送中间件的access、claim_domain、ClaimServer、nohup四项LOG日志，AWR监控日志、数据库的trace文件，并由客户重新启动系统，以恢复系统的正常操作，减少客户的损失。 二、系统现象分析及工作安排 1、根据现象对实际问题定位 (1)、理赔流系统从未出现过单一数据源持久占用不下的情况。 (2)、理赔流自身数据源正常，但部署的核心数据源出现大量占用。 (3)、数据库压力无异常。 (4)、核心业务系统部署的数据源正常，范围在10以下，无异常。 总结：根据以上四点判断，多数为程序所造成，平日出现连接数超高不下的原因多为数据库资源争占所致，其它情况从未出现；在2014年11月11日晚理赔工作流系统做过升级，升级节点为单一节点，属于部分节点的处理操作，有可能是数据源未释放，属于连接池泄露。 2、工作安排 (1)、Access.log日志由孙宗宝调整分析软件，将登录信息日志加载至分析软件中进行分析。 (2)、理赔工作流代码开发人岳云波、项目组长刘硕、项目经理刘齐共同分析后台日志nohup.log文件，查找是否存在特殊性错误信息。 (3)、岳云波分析升级文件中是否存在连接池创建的操作，查看升级代码，并将可疑代码发送出来。 (4)、所有人辅助查看可疑代码，分析是否存在连接池泄露情况。 (5)、刘齐负责整体性资料收集及问题原因定位，并与客户交流。 三、根据系统现象详细分析 1、中间件日志分析： （1）、后台日志显示2014年11月13日上午6时54分系统连接出现异常。 （2）、后台日志显示2014年11月13日上午8时系统连接超时。 （3）、后台日志显示2014年11月13日上午8时14分系统连接异常。 （4）、后台日志显示2014年11月13日上午8时16分Socket出现异常，属于连接出现问题。 2、AWR分析 (1)、Top 5 资料分析，健康的Top 5中，CPU Time 应是排在第一位的。 分析：当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如如果“buffer busy wait”是较严重的等待事件，我们应当继续研究报告中Buffer Wait和File/Tablespace IO区的内容，识别哪些文件导致了问题。如果最严重的等待事件是I/O事件，我们应当研究按物理读取排序的SQL语句区以识别哪些语句在执行大量I/O，并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。一个性能良好的系统，cpu time应该在top 5的前面，否则说明你的系统大部分时间都用在等待上。 A、通过事件定位相关SQL。 --通过事件名称来查询相关ID信息，查看parameter的1、2、3字段来判断是否存在锁。“block” select * from v$event_name en where en.NAME = db file scattered read; --通过ID信息定位锁的相关信息 select * from v$lock vl where vl.SID in ( select se.SID from V$SESSION_EVENT se where se.WAIT_CLASS_ID = 1740759767 and se.EVENT_ID = 506183215 ); --其中的prev_sql_addr可以与v$sql中address字段对应查询，也可以通过其它SQL开头的变量进行查询。 select * from v$session s where s.SID = 465; --查到对应的SQL后，进行分析效率。 select * from v$sql sq where sq.address =7C46CB8; B、一些重要事件需要经常性关注： db file scattered read等待事件是当SESSION等待multi-block I/O时发生的，通过是由于full table scans或 ind