2007年4月1日，我在忙碌了一夜之后，出账包括后续的工作总算做完了，同事启动了tuxedo中间件服务之后，很快接到营业厅的投诉：缴费返销做不了。

(1)登陆中间件主机telnet

(2)运行tuxedo中间件管理客户端：tmadmin

(3)查看服务队列：pq

发现“返销”的服务的队列已经到3000多了，这是从来都没有过的。

(4)使用惯用的方法，down掉服务，重新启动。

杀完之后，发现队列还是很高，同事说需要多次down，于是再来一遍，第三遍down时，tuxedo提示错误：

查看服务队列，队列里还有这个服务，奇怪。

接着，查看bea的错误文档，对这个错误是这样解释的：

到dev2dev.bea.com.cn上查看了相关的帖子，建议将所有的服务重起；

给局方负责营业的主管打电话，不同意重起服务；看样子只能想其他办法了。这时还有其他的投诉反映过来，我的头脑有点乱了。是不是还有其他的没发现的业务问题？

仔细查看每一个投诉，分析原因，基本上都是服务慢的问题，停了帐务后台“信用控制”进程，保证工单不要堆积，这样可以减少开停机的投诉。

这时局方的技术主管也来了，解释了出账不会有问题，现有的投诉都是服务慢造成的。接着同样给局方的部门经理汇报了问题的情况。

就在这时，局方的技术主管说他找到了，问题：是他们负责帐务的人昨天清理销账记录表时将一个索引删除了，但是忘记重建了，好呀，终于找到问题了。

于是建索引，重起服务，中间件服务处理速度上去了。

问题解决。通过这件事情，我想总结一下几点：

(1)从一开始就应该，考虑这不是单独的中间件服务的问题，因为服务的队列高的异常，这时应该想到是不是数据库有一些问题；

(2)遇到服务慢等问题最好多人来解决，这样大家可以分工协作，有人专门负责处理应急业务投诉，这样你就有精力去从系统的角度分析问题；

(3)要对以前的事故仔细分析并且记录下来，其实关于索引的事故我们以前有过，只是今天没有考虑到，这是和以前没有认真分析记录问题相关的。

(4)对于业务支撑这样的大型系统，由于参与维护的人员比较多，所以对于每个人所做的系统维护都需要记录日志，这样到出现事故，我们就可以首先去查看操作日志，今天这个事故就是一个很好的例子。