应用程序执行周期性时快时慢问题解决一例

       作Oracle DBA，常常会遇到一些性能问题，有些性能问题是一开始就很慢的，有些性能问题是逐渐变慢的，有些性能问题是忽然变慢的，而有性能问题时快时慢的，不知道其余同行以为哪一种性能问题比较好处理，今天我在这里分享一个性能问题周期性问题时快时慢的案例，用于总结反思，若有错误请不吝指正。

       最近一位应用运维同事发邮件请求协助，反映有一套应用系统跑批期间周期性时快时慢，并且很规律。周一到周五晚上批量的计算耗时很长，要6-8小时；而周六和周日晚上批量计算耗时很快，只须要15分钟左右。看到邮件中描述的这一现象，有经验的老司机可能一会儿就想到了问题可能出如今哪里。但对于经验不足我来讲，解决这种问题仍是比较吃力的。

        因而拉了一个微信群，在群里详细询问了，跑批快和慢的具体时间。这里多提一句，在我接手这个case以前有一个同事也查了这个问题，他根据awr从dbtime到redo log生成量再到事务都作了一些分析，还作成了折线图，在群里发了一堆，但就是没有作一些详细的询问和分析。最终也没有一个结论。

        言规正传，从开发和应用运维那里获得一些详细信息以后，首先从awr下手。分别取到快的时间和慢的时间区间的awr报告。以个人能力，从各项指标没有看出数据库总体负载有什么问题。但在top SQL那部分发现了两个时间段的TOP SQL确实是不一样的。在慢的时间段有一条update语句73320次，耗时9869.7s，而在快的时间段的TOP SQL中却没有显示这条update语句。难道这就是问题所在吗？

        因而询问开发同事，update语句是否为批量期间执行的语句。获得确定的答复后，开始怀疑是否是工做日和周末跑批的逻辑不一样的，但awr中信息否认了个人猜想，原来这条update语句也在周末也跑了，只不是跑的很快，跑了75331次，耗时24.07s。从目前 的线索来看，之条update语句执行效率无疑是致使程序批量时快时慢的缘由。可是为何会出现这种现象如今还不得而知。

        问题sql定位了，剩下的问题就简单了，把sql优化掉，每次批量都在24s完成，那问题天然就解决了。如今开始寻找sql执行时快时慢的缘由。这里介绍一个很强大的工具awrsqrpt，这个工具能够获取awr中记录的sql语句的历史执行计划。使用awrsqrpt取到两个时间段sql的执行计划，分别以下两个图所示：

        从执行计划中能够看出，都走了表的主键，选择了不一样的方式，其中INDEX RANGE SCAN平均单次执行时间为384.3ms，而INDEX SKIP SCAN的平均单次时间是0.3ms，差了3000多倍，难怪批量执行时间差别如此之大。看到这个，脑子中反映出来的第一个解决方法是固定执行计划，强制走INDEX SKIP SCAN。但这种方法治标不治本。只能用在实在找不到问题缘由的状况下，或紧急的状况下。

        继续与开发沟通，得知，update语句中的表，天天批量后都会被truncate掉，这是一个很重要的信息。难道就是因为这一个truncate操做致使sql语句执行效率差别如此之大吗？咱们继续往下分析。

        咱们都知道，Oracle的执行计划都是经过CBO，根据表上的统计信息，而估算出来Oracle认为最作优的执行计划。也就是不论INDEX RANGE SCAN 仍是SKIP SCAN，Oracle都认为是最优的，难道是Oracle优化器出现了问题了吗？应该不是的，若是优化器这么容易出问题，那Oracle在商用数据库也不会称霸这么久了。因而想到了表上的统计信息，经过查询视图sys.wri$_optstat_tab_history获得表上的历史统计信息以下图：

        从上面的图上能够看到，表上的统计信息时而为0，时而为很大，看来就是统计信息致使CBO在选择执行计划时，没有选择它应该选的最优执行计划。

        从上面的分析来看，应该是找到了问题的根本缘由，批量表每次批量完成后都会作truncate操做，数据库默认天天都会自动收集表的统计信息，周一到周五22：00开始收集，周末6：00开始收集。从而致使数据库在不一样时间点收集到表的统计信息是不一样的，进而致使了优化器基于统计信息来选择了慢的执行计划。

        缘由找到了，就开始讨论解决方法，这里列出来几种方法应该均可以解决这个问题：

        一、在批量导入数据后，对批量表作一次统计信息收集

        二、锁定批量表在有数据时的统计信息

        三、truncate操做改成批前执行(开发提出)

        四、固定问题sql的执行计划(可能解决不了问题)

        反思：

        一、咱们在解决问题时，不能只从数据库总体层面来分析，有时多是一条自己性能不是不好的sql致使出的性能问题

        二、多沟通、细沟通，把尽量掌握多的信息点，有助于问题的解决

        三、从性能慢的sql中应该也能够猜测到问题缘由，Oracle评估的cost 为0

        以上为整个case的一个解决过程，欢迎指正。