客户端报告了执行存储过程时重复出现的非常奇怪行为的实例。

他们具有运行易失数据集的缓存转置的代码。如果满足以下条件，则写入存储的proc以按需重新处理数据集：
1.自上次重新处理以来数据集已更改
2.数据集5分钟未更改。

（第二个条件在更改期间停止了重复的大规模重新计算。）

这可以正常工作几个星期，SP花费1-2秒来完成重新处理，并且仅在需要时才执行。然后…

• SP突然“停止工作”（它一直运行并且从未返回）
• 我们以一种微妙的方式更改了SP，然后再次起作用
• 几天后，它又停止工作了
• 有人然后说：“我们之前已经看过了，只是重新编译SP”。
• 无需更改代码，我们重新编译了SP，并且可以正常工作
• 几天后，它又停止工作了

现在已经重复了很多很多次。SP突然“停止工作”，再也没有返回，并且客户端超时。（我们尝试通过Management
Studio运行它，并在15分钟后取消了查询。）

但是，每次我们重新编译SP时，它突然又可以工作了。

我尚未在适当的EXEC语句上尝试使用RECOMPILE，但是我尤其不希望以任何方式这样做。它每小时被调用数百次，通常什么也不做（它每天只对数据进行几次重新处理）。如果可能的话，我想避免重新编译相对复杂的SP的开销，“只是为了避免“不应”发生的事情…

• 有谁之前经历过这个吗？
• 有人对如何克服它有任何建议吗？

干杯，
Dems。

编辑：

伪代码如下：

• read “a” from table_x
• read “b” from table_x
• If (a < b) return
• BEGIN TRANSACTION
• DELETE table_y
• INSERT INTO table_y <3 selects unioned together>
• UPDATE table_x
• COMMIT TRANSACTION

这些选择“不是很漂亮”，但是当它们在线执行时，它们会立即执行。包括SP拒绝完成的时间。探查器显示它是SP在“插入”处的INSERT。

SP没有参数，并且sp_lock没有显示任何阻塞进程的信息。