核心系统某业务超时的问题分析


		核心系统某业务超时的问题分析
 
问题描述：
 
2012年3月某日日，业务返回“调用失败或用户密码错误” 5579次，其中在11点通知业务部门系统恢复后为4396次，全天共查询号码次数为26553次，其他数据可参考附件
 
原因分析：
 
采用自底向上的分析方法
 
1，  看硬件和日志，通过前面的方法论，硬件无报错，日志无异常；
 
2，  操作系统资源利用率不超过60%，不存在资源不足的情况；
 
3，  分析等待事件，从3月5日起，开始出现大量latch free等待事件，很可能和此时业务超时有关
 
4，  由于oracle 9i版本的限制，相关statspack报告没有按照时间模型来排序（资源消耗排序），通过只有脚本按照时间排序，定位到可疑sql
 
5，  对可疑sql(3274434087)分析执行计划和趋势分区，执行计划问题不大，但是执行速度却是越来越慢，并且执行时间慢的时间和故障时间非常吻合
 
6，  通过业务部分确认，该sql即为空选空写相关业务sql，随着业务量（对应于该sql执行次数）和表中数据量的增加，执行速度越来越慢，当执行时间超过1秒（业务逻辑设计）时即超时，报错“调用失败或用户密码错误”；
 
优化方案
 
问题找到了，解决问题的方法也就相对容易了。按照优化的方法论，由于执行执行计划无明显问题，最终根据空选空写业务的业务特点进行如下优化措施
 
1，  Where条件选择性不足，选出的号码数据过多，需要增加必要的选择条件
 
2，  不必要的Order by排序操作，消耗大量系统资源，建议取消排序操作
 
优化效果
 
经分析，数据库的异常等待时间latch明显减少。
 
主机CPU利用率降低了10%
 
 
后续：3月26日，异常sql再次出现，cpu利用率再次增加，联系业务部分，是业务部署导致，28日重新部署后解决