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

问题描述：

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日重新部署后解决