Server 2012 -挂起

Question

我有一份几个月没出问题的工作。它运行在我们的测试/开发服务器和生产服务器上。在这两种环境中，数据库和作业是相同的。

几天前，这份工作在生产环境中停止了工作。它在test/dev环境中仍然工作得很好。

该作业针对存储过程运行。当有人通知我他们的查询不起作用时，我第一次注意到了这个问题。我发现这份工作通常需要12分钟左右，已经运行了3.5小时。它一直挂在第三个SP上。它每3小时运行一次，并按照以前的计划时间运行。

我杀了这份工作，因为，我甚至不能做第一个SP。第一个SP有四个步骤: 1.将数据从链接服务器检索到临时表(工作正常)。2.删除与从链接服务器检索的日期范围匹配的常规表中的数据。3.将检索到的数据插入经常表。4.重建指标。

从链接服务器检索数据可以找到，我可以在临时表中看到数据，查询它等等。但是，当它进入删除步骤时，似乎什么都没有发生。它使用CPU，但通常需要3-5秒的进程(基于历史)将永远持续。在取消这个过程之前我已经放了45分钟了。

dbcc checkdb没有显示错误。我重新启动了Server，然后重新启动了物理服务器，检查了硬盘空间，重建了所有索引，检查了内存等等。我不知道下一步该去哪里。

在重新启动物理服务器之后，我立即重新尝试了第一个SP，否则任何人或任何其他进程都可能导致争用问题，并且仍然有相同的结果。

有什么建议吗？

谢谢。

Answer 1

看看我的博客无法解释的Server超时和间歇阻塞

这部分可能会给你提供你需要的线索。

如果存储的proc getUserPrivileges对您没有足够的问题，那么让我补充一下:它可能会在每次调用中重新编译。因此，Server在每个调用上都获得一个编译锁。它被重新编译的原因是因为临时表被创建，然后很多行被从它中删除.这将导致在下面的SELECT上重新编译存储的proc (是的，在运行存储proc的过程中)。在其他过程中，我注意到了一个DECLARE语句，它的SELECT语句引用一个临时表-这也会强制重新编译。 有关重新编译的更多信息，请参见：http://support.microsoft.com/kb/243586/en-us

因此，对我来说，它可能在某些环境中工作，而不是在其他环境中工作，这取决于删除工作进行了多少，即使是在一个永久的表中。

您能将存储的过程分解为2吗?第一个程序将得到删除日期范围并执行删除操作。然后，第二个将处理新插入。我认为这将使它不会在运行过程中启动重新编译。