This is tuning!
一个月一度的征期到了，在上次存储调整之后平稳度过了数月之后，这次客户又来紧急电话，从上周三下午开始数据库服务器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次左右。 虽然不知道相关表的数据量和执行计划，但是很明显这就是罪魁祸首，于是安心睡觉。 今天上午到客户处，直接告诉客户90%的原因是由于这条SQL语句，然后连上服务器，开始tuning。 两张表，A表1679679条记录，B表839889条记录。 SELECT DISTINCT a.PH FROM a WHERE not exists (select 1 from b…