ORACLE性能优化一例

    ORACLE性能优化是一个老生长谈的问题，有一种世界普遍存在的现象：数据库开发人员只注意写代码完成需求和现实功能，然而却很少有人关注如何在开发的过程中注意性能优化，认为调优应该是DBA的事，是开发结束以后的事；然而DBA往往对开发过程一无所知，在调优的过程中一般中敢轻易改动开发人员写好的代码，以免出现逻辑问题，这样的话就让优化的效果大打折扣了，于是就出现了这样一个奇怪的循环：开发人员不能调优，DBA不懂开发，结果开发人员交付项目的时候还没有什么性能问题，等过一段时间数据量上来了，性能就成为瓶颈，而DBA也只能小打小闹地调一调，这个时候往往开发人员都是跳槽走人了，更没有人敢从代码的角度来调优了。

    ORACLE公司进行过研究，发现有80%以上的性能问题是由于不好的SQL的问题，SQL写得不好，而开发人员往往不关心这一点，或者根本就不懂，所以现在开发的系统性能问题很严重，如果请ORACLE公司的专家来调优，那费用就大了去了，人家是按小时计算的，而且从出门开始算，一般公司对这样的花费望而生畏。如何尽可能地避免这样的问题呢？其实最好的就是开发人员要懂一些优化方法，而DBA尽可能地参与到开发过程中去，这样应该会好些。

    现举一优化的真实例子，有一个电信方面的项目，上线两年了，数据量累积到了一定的量以后性能出现了问题，每天几百个存储过程原本几个小时就能跑完，现在几乎一天都跑不完，而新的一天又开始了，搞得维护人员苦不堪言。DBA努力从SQL的角度来找问题，发现SQL写得问题不大，大都是从一些表里SELECT出数据，然后INSERT到一些表里去，单独拿出来SELECT语句跑几分钟十几分钟就结束了，可在存储过程中就要跑几个小时，这是怎么回事呢？而且这些操作中没有什么DELETE和UPDATE操作。SQL的执行计划和AWR报告都送给了ORACLE公司，结果也没看出个所以然来，专家们说SQL没有问题，可能是数据库的配置有问题，然后没有下文了，看来这些钱是白花了。

    于是找我来分析，我花了一些时间研究，发现SQL单独运行SELECT确实很快，可就是INSERT的时候很慢，所以我怀疑会不会是因为索引的问题，数据量上来以后，要维护唯一索引会花费太大的成本。于是把先是将索引重建，但并没有对性能有太大的提高，我想到了既然是插入的时候会变慢，是不是可以考虑采用并行插入呢？没想到效果奇好，原本需要运行5个小时的存储过程，居然6分钟就运行完了！一下子效果这么明显，实在是让人意外。接下来我将所有的存储过程进行了类似的处理，整个性能有了质的提高，比刚开发完交付的时候运行的速度还快。

    如果在开发的时候早早地预估当数据量增长到一定程度会出现性能问题，早做预案，就不会出现这样的问题，所以建议开发人员还是应该有一些责任心，至少应该本着提高自己技术水平的想法，尽可能把代码写得更完善一些。