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