【IT168技术分析】
    一个月一度的征期到了，在上次存储调整之后平稳度过了数月之后，这次客户又来紧急电话，从上周三下午开始数据库服务器I/O负载忽然陡升到100%，申报要40分钟，各大厅纳税人开始骂娘。。。

    每个月的征期有一周，而纳税人通常都憋到最后几天才开始出动，也就是这一周的最后两天将是系统负载的最高峰，而上周三仅仅是刚进入征期而已。

    在被变幻莫测的雷雨天气延误了3个小时之后，飞机从首都机场起飞了，即将到达目的地的时候，忽然遇到暴雨天气，飞机在剧烈颤动了良久之后，忽然间好似过山车一样急降，这个急降大概持续了3秒左右，心都被扔到了嗓子眼，全机舱忽然之间鸦雀无声，等急降结束了好一阵儿逐渐平稳以后，才听到周遭各式各样的大吐气。

    降落目的地，客户来接机，然后请吃饭，这么隆重的待遇是因为总局，省局，市局，分局的各级领导都到了，如果征期挺不过去，领导会很生气，后果会很严重。

    回到酒店，打开刚拿到的周三下午的statspack report，心里面一块石头落地了，非常幸运，太明显的性能问题了。cache buffer chains latch free占据90%以上的等待时间，buffer gets top SQL中一条select distinct的语句在一张报表中占据了60%以上，另外一张居然占据了143.2%，每次执行这个SQL都会有8,725,441.7的buffer gets，在半个小时里面一共执行了150次左右。

    虽然不知道相关表的数据量和执行计划，但是很明显这就是罪魁祸首，于是安心睡觉。