等待时间 single-task message

         昨天在快要下班的时候，我的同事突然碰到一个问题，说一个只需要执行几十秒钟的procedure，居然跑了半个小时都还没有完。我不相信，然后我也去跑了一下，果然是这样，由于当时马上下班啦，我就跟我同事说，我明天来帮你看。

最开始我以为是锁表的原因，跑这个procedure，查看v$locked_objects为空，没有一条记录，，然后再查看当前session如下：

 

发现有条sql始终卡在那里，并且等待时间为single-task message，通过查询资料了解到这个事件在10g中通常是dblink导致的。然后马上去重建一下synonym，因为这个存储过程中所需表是通过dblink来同义词，发现建一个同义词都需要2分钟，并且这张表的记录只有几百条，坑爹啊。

 

重建一下dblink，结果还是如此，再去查看一下最新的tns，结果发现tns的server已经发生改变，我估计多半是连接到backup的server上啦。

最后再次重建dblink，问题解决，结果该procedure几秒钟完成。

 

总结一下：在10g中，碰到single-task message事件，基本上是有dblink造成的，更甚会进一步产生Mutex等待。