记录一次数据库游标引起的性能问题的调优过程

事件时间：2019年1月下旬

事件坐标：浙江省绍兴市

事件概述：

　　那天晚上10点左右，我在杭州家中接到绍兴某项目总监的电话，说是某业务系统在压力测试中发现严重的性能问题，由于项目临近上线时间紧张，希望我尽快到现场协助处理。

　　挂掉电话后我qq联系现场做压测的兄弟，了解了下基本情况：单台服务器300并发的情况下，某业务录入功能的耗时在100秒以上，与3秒的预期相去甚远。

　　第二天一早赶赴绍兴，与压测的兄弟一起分析问题原因。

　　经过1天多的调试、分析、压测，再调试、再分析、再压测，终于找到问题根源。（下节详述）

　　第三天下午问题解决后返回杭州。

解决过程：

　　根据功能特性，压测的脚本分了3个部分，为了区分就暂且把它们称为：校验A、校验B、数据保存。

　　目前压测的数据显示：校验A耗时90多秒，占了总耗时的90%，校验B和数据保存的耗时相对较小，均在5秒以内。据此判断可能校验A的代码存在性能问题。

　　于是我开始分析校验A的代码，发现校验A不同于校验B的地方是，校验A仅有的一个sql采用了预编译执行，我把这个预编译执行改成了sql硬拼接的方式，然后压测，此时的压测结果显示校验A的耗时降到了5秒以内，可是校验B的耗时大大增加到了80多秒，占了总耗时的90%以上。（奇怪，我只把一个sql从预编译执行改成了sql硬拼接方式）

　　然后开始分析校验B的代码，对校验B的sql进行了索引上的优化，然后压测，此时的压测结果显示校验A和校验B的耗时都降到了5秒以内，可是数据保存的耗时增加到了80s以上。（啥情况？故障又转移了，奇怪）

　　接下来优化数据保存，可是优化后又出现校验B的耗时大大增加的情况。

　　就像跷跷板，摁下这头，起来了那头

　　

　　一筹莫展之计，脑子突然闪现”数据库“三个字，难道数据库存在性能问题？于是开始把分析的对象从应用转移到数据库。

　　该项目使用的是Oracle数据库，可以获取awr性能报告来做分析：

　　

　　在awr报告中发现以上异常，且在topsql中发现某些简单的sql也存在耗时很长的情况，怀疑是数据库游标存在问题，于是把分析对象转向数据库游标。

　　分析方法：在压测过程中通过以下sql查询游标的使用情况：

　　

　　发现查询出的游标使用率在压测开始不久后就会达到100%。

　　于是我们与dba协商调高该值，调整后，压测出的性能得到明显的提升。

　　经过几次调整和压测后，我们把session_cached_cursors调整到了一个合适的值。

　　最终压测达标，问题解决。

总结：

　　1、当调优时出现了按下葫芦起了瓢的现象，问题可能出现在各部分均依赖的对象上。

　　1、数据库往往是系统的性能瓶颈，调优时应优先或重点考虑。

　　2、尽量给系统配备性能监控工具，可加速性能问题定位。