sql - MS SQL Server 2005 - 存储过程 "Spontaneously Breaks"

Question

客户端在执行存储过程时报告了重复发生的非常奇怪的行为。

他们的代码可以运行 volatile 数据集的缓存转置。编写存储过程以按需重新处理数据集，如果:
1.自上次重新处理以来数据集发生了变化
2.数据集5分钟内没有变化

(第二个条件在变化期间停止大量重复重新计算。)

这几周效果很好，SP 需要 1-2 秒才能完成重新处理，而且只在需要时才执行。然后...

• SP 突然“停止工作”(它只是继续运行，再也没有返回)
• 我们以微妙的方式更改了 SP，它再次发挥作用
• 几天后它再次停止工作
• 然后有人说“我们以前见过这个，只需重新编译 SP”
• 在没有更改代码的情况下，我们重新编译了 SP，并且它起作用了
• 几天后它再次停止工作

这种情况现在已经重复了很多很多次。 SP 突然“停止工作”，不再返回，客户端超时。 (我们尝试通过 Management Studio 运行它，并在 15 分钟后取消了查询。)

然而，每次我们重新编译 SP 时，它都会突然再次工作。

我还没有在适当的 EXEC 语句上尝试使用WITH RECOMPILE，但我并不想以任何方式这样做。它每小时被调用数百次，并且通常不执行任何操作(它每天只重新处理数据几次)。如果可能的话，我想避免重新编译相对复杂的 SP 的开销“只是为了避免发生“不应该”发生的事情......

• 以前有人经历过这种情况吗？
• 有人对如何克服这个问题有什么建议吗？

干杯，
民主党。

编辑:

伪代码如下:

• 从 table_x 读取“a”
• 从 table_x 读取“b”
• 如果 (a < b) 返回
• 开始交易
• 删除表_y
• INSERT INTO table_y <3 选择联合在一起>
• 更新表_x
• 提交交易

这些选择“不太漂亮”，但是当内联执行时，它们会立即执行。包括 SP 拒绝完成的情况。探查器显示 SP“停滞”是在 INSERT 处

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

Answer 1

这是参数嗅探的足迹。是的，第一步是尝试 RECOMPILE，尽管它在 2005 年并不总是按照您希望的方式工作。

更新:无论如何，我会尝试在 INSERT 上进行语句级重新编译，因为这可能是一个统计问题(哦，是的，检查自动统计更新是否已打开)。

如果这似乎不适合参数嗅探，则比较实际的查询计划从它正常工作时和从它永远运行时开始(如果无法获得实际的计划，请使用估计的计划，尽管实际的更好)。您正在查看计划是否改变。