昨天在快要下班的时候,我的同事突然碰到一个问题,说一个只需要执行几十秒钟的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等待。