一次优化的教训

       某系统月底做帐，慢到了客户难以容忍的地步。强烈要求开发人员优化。

隐约听到客户这么问开发人员：

为什么别的公司比我们的数据量大很多，人家的系统都很快。为什么我们的系统这么慢，同是你们开发的系统，怎么差距这么大呢？

开发人员说:
我调查过,也咨询的其它项目组的同事，现在业务表历史数据太多了，需要优化。我们调整一下，争取下个月做帐的时候解决这个问题。

 

开发人员说到做到，简单咨询过其他项目组的同事。便开始在测试环境上做测试，结果发现清理掉历史数据后，果然快了很多。临近月

底，开发人员提出一套数据变更，要在生产上建大约20个左右的临时表，备份业务表中的历史数据(其实是某种业务类型的数据)。当我

收到这个数据变更后很是惊讶，只是简单的create table as  (select  * from  table where  type = .......)，也没有给所谓的临时表建索引。

且这些表的数据量都比较大。由于不明白这么做的原因，所以提出了几个问题：

1.临时表中的数据是否需要查询，是否需要建索引？
 
2.这些临时表要保存多长时间，是否需要删除，什么时候删除？
 
3.尽量不要在业务高峰期，执行这些SQL.

     其实本来还想问一句，删除这些数据会不会对其它业务造成影响。但一想人家也是工作好几年的了，肯定不会犯这种低级错误。并且邮件也

抄送给了其它业务系统的负责人。我想我没必要问这个问题了。即便有问题，不是有备份吗，很快也能恢复回来。我只关心对数据库的影响就

好了。没想到我的这个疏忽，导致了严重的后果。。。。。。

     中午上班，发现那些数据变更中的临时表已经建好了。检查了一下表空间，发现存放业务数据的那个表空间已经不足10%了。检查了一下，

正是那些新建的临时表占用了很大的表空间。此时又收到一封邮件要在业务表中删除那些刚才已经备份过的数据。由于数据量较大，赶紧找执

行数据变更的人员，让他下班后在执行。没想到我去晚了，他已经开始删除数据了。由于删除业务数据是根据临时表与业务表做关联进行删除的，

临时表上没有索引。删除语句都是全表扫描。由于这时正是业务高峰期，生产库的cpu马上升高了很多。赶紧让他停止了执行那些数据变更。

 

       当我跟开发人员说这个问题时，他才意识到要在临时表上建索引。由于业务系统的表空间已经不足了，只能把索引建在其它的表空间了。他很快

写好了建索引的SQL,看了一下没什么问题。叮嘱了一下他，一定要在下班后执行建索引和删除数据的操作。

         第二天上班客户反映业务数据有问题不能出单了。找那个系统的负责人，听同事们说，昨天他们弄的很晚才走，可能要晚来会。赶紧电话联系那

位同事，说昨天的数据有问题，可能删错数据了。她也急匆匆的干来解决问题。发现昨天的数据处理可能是有点问题。一会越来越多的系统都出问题了，

原因都是昨天删除数据造成的。于是赶紧跟各系统负责人解释。由于忙于跟各系统负责人解释原因。真正的生产问题并没有解决，客户一次次来崔，

最后IT部老总直接找过来了。。。

 

      由于删除的数据影响范围比较广，昨天删除的数据还要从临时表中在inset到业务表中。业务表空间昨天已经不到10%，今天只能在扩了。好在客户

比较好说话，跟领导请示后，痛快的扩了表空间。于是在下班后在把昨天删除的数据还原回去。

 

       折腾了一六十三招，优化不仅没做好，性能没有提升。反而影响了正常的业务系统，而且给客户造成了不好的印象。这时正值下半年合同的签订时期，

出现这个问题可不是个好兆头。

 

      优化貌似简单，如果方法不正确，不了解优化的基本原理与思想。不但达不到预期的效果，有时候可能还会适得其反。上述就是一个例子。开发人员简

单的认为，删除一部分历史数据就可以提高系统的性能。但真的是这样的吗？看来得找个机会，给开发人员普及一些oracle优化的基本思想了。

 

       生产环境，稳定压倒一切。切不可为了追求效率，在生产上进行一些没有经过严格测试的操作。另一方面项目组的管理也要加强，开发人员发出的数据

变更评审，每个评审是要负责的。不是只是走形式，走流程。要切实的起到评审的作用，保证生产环境的稳定。