我是迫不得已写下这个题目，今天奥运圣火离我只有几百米我都没有时间去顶礼膜拜，因为我实在太忙了。
我注定要错过这届最有意义的奥运会，在离北京奥运会还是十几天的时候我离开了北京，将要搬住的房子里也没有电视。这个夏天我要将精力放在oracle上面了，我想我不会为错过奥运而后悔，因为eygle说过的那句话一直记在我心里：一个人在一生中一定要在某件事上投入全部的精力，要不然就太失败了。
今天给客户解决问题，客户懂的居然都比我多，讽刺的定义一下子就出来了。还有前几天说到的那个只学了7个月oracle的女生，对我的刺激也挺大，因为今天经理给我的学习文档就是她写的，我，我，我。。。啥都不说了，谁给我块豆腐？
扯远了，一切还是与oracle有关。简单说一下今天遇到的问题：前台说系统慢，buffer busy waits和db file sequential reads居多，buffer busy waits的p3为130，说明是热点块，还是SQL的问题。抓到与buffer busy waits有关的语句，代入相应数值，执行了25分钟没出结果，随便输入个值，执行计划出来了，发现INDEX FULL SCAN ，INDEX居然有15G，天哪，这不慢才怪呢。这应该就是症结所在了。好了，再理一下思路：buffer busy waits的p3为130，说明是热点块，有众多会话要访问这个块，但这个块没有在buffer cache中，需要从磁盘中读入，这个读入的过程只有一个会话去做，其他会话就在buffer busy waits上等待了，去读block的会话需要IO，此时IO比较慢，就是我们前面说的索引全扫面耗费了大量时间和资源，所以该会话在db file sequential reads上等待，这样就解释了这两个等待事件，解决问题办法就在于优化那个取block的SQL。
OK，以上只是大概分析，里面还涉及到执行计划的分析，以后等我学会了再帖出来吧。
[@more@]来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/9533994/viewspace-1008078/ ，如需转载，请注明出处，否则将追究法律责任。
