悲剧的一个夜晚，做第三方技术支持总是一把辛酸一把泪

      一个DB2问题，几天前的一个下午。接到Y客户一个电话。反映一个存储过程怎么也跑不过去了。让去现场，当时我正在另外一个客户哪里。就先电话说让客户重新建立一下存储过程，然后用最块的速度赶到客户处。

     到了客户处，客户已经在 reorg数据库了。我查看了一下存储过程，初步感觉存储过程的结构还是比较简单的，建立一个临时表，把主表的数据过滤出来，放到临时表里去，然后从临时表做数据比对。进行数据的处理。业务逻辑比较简单。

      做了一个简单的检查，参数设置，底层设备均正常。当时推断2个可能，一个是由于表（约1亿行），长期没有做过reorg和runstats，执行计划有问题。另外一个是存储过程的执行过程，包括语句逻辑和索引结构出现了问题。

     由于客户已经开始做reorg了，就让客户先做完，之后再runstats一下，再rebind一下，但是，这时候，矛盾发生了。由于reorg和runstats比较慢，做完了进凌晨3点了。客户跑了一下存储过程，还是慢。马上就给他的领导打电话，说还是慢，没有办法解决了。请高人来吧。他们领导说，不是有工程师在吗，客户说:"他也没辙了”。我当时就有点不爱听了。客户根本自始至终没征求过我的意见，就按照他的意见来的。现在说我一点用都没有，实在有点难接受。这时，客户让我和他领导汇报。我就说：“当前只是工作的一个部分，这个部分完成后，无论速度是否变快，都是我们工作的一个阶段，至少，能证明问题不是出自这个方面，我们就可以从存储结构和索引结构入手，进行应用层面的故障排查，毕竟我们是运维方，能证明自己没问题也是必要的。”他们的领导表示认可，挂电话后，我和客户商量，我们再做一次rebind，如果行，最好，不行的话，就从调试存储过程开始，先尝试用常量替换变量，看看有问题没有。这时候，客户和我急了。简直就是在和我咆哮：“你说什么我不听，你让IBM的工程师给我打电话，他说这么做，我再做”。

    客户的咆哮让我很无奈，只好在凌晨3：30联络我们老大，是不是叫原厂。老大听了，直接打车过来。来了之后，他出面让客户用一个常量代替变量，测试了下存储过程，马上就抓到了一条缓慢的语句，这个语句的业务逻辑上有些问题，我们给出了改写建议。等到了第二天的上班时间后，客户的开发人员来了之后，进行了语句的改写，速度马上恢复正常。在速度回复正常后。在接下来的一个步骤，速度再次猝然变慢，通过分析索引命中和索引结构，很快定位出有一条索引无需建立。删除该索引后，问题解决。

    其实，这是一个很简单的性能故障，但是，由于客户的不信任，不配合，致使整个过程中，没有一个步骤是按照我的计划进行的。换来的是客户的更加不满，和我的满腔抑郁。我不知道整个过程中，到期错在了哪里。