性能下降的不定时炸弹_过旧的sql_profile（r3笔记第9天)

最近这一周以来，生产环境像是得了重病的病人一样，小问题没有修好，大问题不断。IO的等待极为严重。数据库的负载达到了几十倍，上百倍。 weblogic和tuxedo在很大程度上都受到了影响，导致业务响应极为缓慢。 在排查了中间件部门，数据库，存储，网络，操作系统等各个层面，也发现了存储的一些小问题，问题比较大的就是数据库这边的一个sql语句，每执行一次需要7分多钟，按理说这种类型的语句执行7分钟左右可能不是太大的问题。但是了解到这个sql语句在所有的中间件层面都需要频繁的发送sql请求，比如有20个weblgoic,那么可能就同时会发送20个sql请求，这个问题一下子就变得有些严重了。 更有些让人纳闷的是，通过查看sql语句，发现里面添加了一些hint,这些Hint在认真的校验之后，都没有问题，根据产品线的反馈，这些都是反复验证的最优执行。里面有一个5千多万条数据的表，需要走全表扫描，在Hint里面加了一些指定的处理，都是很合理的处理。 我抓取到top sql以后，查看执行计划就有些纳闷，为什么执行计划和Hint里面的有很大出入，Hint中指定了使用全表扫描，并行，但是生产环境的执行计划却是用了索引，没有使用并行。 反复的验证之后，但是也没留意，自己主观的认为没有走并行可能是资源使用受限，没有多余的并行资源可用了，所以没有走并行，走索引扫描，可能是Oracle认为通过索引扫描的代价更低。 但是自己的认识确实是错了。我显示通过sql monitor得到了对于那个的执行报告，然后生成了一个sql tuning advisor的报告，里面给的两个建议，一个是添加对应的索引，让一些数据的过滤更加高效，这个也需要斟酌，毕竟添加额外的索引会对dml产生一定的影响，可能原有的一些执行计划会受到影响，得不偿失。 另外一个建议就是增加并行。这个地方我就有些纳闷了，本来已经增加了并行，但是似乎没有产生什么效果。 最后查看sql_profile的配置时，自己才恍然大悟。sql语句没有走hint指定的执行计划，很大程度上是因为已经配置了对应的sql_profile，这个sql_profile里面指定了数据的访问需要走索引，不走并行等等。按照问题排查的思路，我们这几个月对没有处理过这个sql语句。最后一查看创建的时间让人大跌眼镜，这个sql_profile是在去年的10月份创建的，那个时候里面的数据要少很多。按照当时的分析和数据量，访问索引可能效率更高，代价更低。但是过了快一年了，结果数据量增加了好几倍，系统的负载也上来了，原来的profiel就产生了负面的影响，本来影响还不明显，慢慢的随着数据量的不断增大，问题越来越严重，导致了隔了一年以后终于爆发了。 所以说过旧的profile真是一个不定式炸弹，在系统的升级过程中，有些执行计划确实要好好斟酌。oracle毕竟没有那么有远见的判断你数据的增长情况，它只是在当前的情况下能分析出最友，代价最低的一些建议。但是需要我们自己来判断。 当然了这个问题的处理也不是一句话就解决的事，我们需要做好充分的准备，首先需要备份原有的profile，万一性能更加糟糕了怎么办，至少我们可以让执行计划不会更加糟糕。恢复回去。 这个时候就可以使用dbms_sqltune里面的几个小功能。 这个功能是创建一个sqlprofiel备份的表，所有的profile的备份数据可以放在这个表中

SQL> exec  DBMS_SQLTUNE.CREATE_STGTAB_SQLPROF(table_name=>'STAGE',schema_name=>'N1');

PL/SQL procedure successfully completed. 使用如下的命令可以直接把当前的profile数据备份到表中

SQL> exec  dbms_sqltune.PACK_STGTAB_SQLPROF(PROFILE_NAME=>'SYS_SQLPROF_01419cd955b40000',STAGING_TABLE_NAME=>'STAGE',STAGING_SCHEMA_OWNER=>'N1');
PL/SQL procedure successfully  completed.

有了这些数据，就可以导入到别的库上或者直接恢复。 当然了在目前的库上我们先不需要这个profiel了，就需要直接删除它。 exec dbms_sqltune.drop_sql_profile('SYS_SQLPROF_01419cd955b40000'); 这样处理之后，就等性能能够有质的飞跃了。