成也AQO败也AQO
因为工作的原因,我们接触到的客户大部分是金融和运营商行业,这些客户有个最大的特点是追求稳定,对于使用数据库新特性持保守的态度,不会轻易尝试某些可能会导致生产系统不稳定的新特性。上线前通常都会将一些新特性禁用,避免上线后可能会由于这些新特性而导致性能出现抖动。
但是近期遇到的一个case,却颠覆了我对这些新特性的看法。
最近我们在帮客户分析一条SQL的性能问题,过程中发现由于数据库的Adaptive Plan参数是默认的开启状态,产生了比较多的子游标,当使用某个条件时就会出现性能下降的情况。作为本能的反应,我们建议客户关闭Adaptive Plan功能,给出的理由是“虽然未必是最优的,却是我们能接受的稳定性能”。修改完参数客户重新测试执行了相关的业务模块,之前有问题的SQL按照预期很顺利的执行完成,但是又出现了新的情况,有另一条在之前的测试中秒级执行的SQL这次却整整用了2000+秒才执行完成。这不由得让我们重新审视Adaptive Plan带给数据库的正面影响。
什么是 AQO (自适应查询优化)
为了SQL语句能够始终以最优的执行计划执行,Oracle在不断的探索和革新。从9i的绑定变量Peeking,到11g的ACS和Statistics Feedback,在12c中则引入了Adaptive Query Optimization。
Statistics Feedback在SQL第一次执行时,根据统计信息生成的执行计划执行SQL,执行过程中执行计划不能改变,如果统计信息不准确,在SQL第一次执行时可能就会引起灾难性的问题。而且,Statistics Feedback生成的数据只能保存在内存中而不能固化下来,如果过程中