MS SQL Server 2005 - 存储过程"自发中断"

Question

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

它们具有运行易失性数据集的缓存转置的代码.如果出现以下情况,则会编写存储过程以按需重新处理数据集:
1.数据集自上次重新处理后已更改
2. 数据集已更改5分钟

(第二个条件是在更改期间停止大量重复重新计算.)

这工作好几个星期,SP花了1-2秒完成重新处理,它只在需要时才这样做.然后...

• SP突然"停止工作"(它只是继续运行而且从未返回)
• 我们以微妙的方式改变了SP,它再次起作用
• 几天后它又停止了工作
• 然后有人说"我们以前见过这个,只是重新编译SP"
• 在没有更改代码的情况下,我们重新编译了SP,并且它工作正常
• 几天后它又停止了工作

这已经重复了很多次.SP突然"停止工作",永不返回,客户端超时.(我们尝试通过管理工作室运行它,并在15分钟后取消查询.)

然而,每次我们重新编译SP时,它都会突然再次运行.

我还没有在适当的EXEC声明中尝试过WITH RECOMPILE,但我并不特别想这样做.它每小时被调用一百次,通常什么都不做(它只会每天重新处理数据几次).如果可能的话,我想避免重新编译什么是相对复杂的SP的开销"只是为了避免"不应该"发生的事情......

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

干杯,
Dems.

编辑:

pseduo代码如下:

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

选择是"不漂亮",但是当在线执行时,它们立即执行.包括SP何时拒绝完成.分析器显示它是SP"停止"的INSERT

SP没有参数,sp_lock没有显示阻止进程的任何内容.

Answer 1

正如其他人所说，数据或源表统计信息的变化方式导致缓存的查询计划变得陈旧。

WITH RECOMPILE可能是最快的修复方法 -SET STATISTICS TIME ON在立即消除它之前先找出重新编译的实际成本是多少。

如果这仍然不是可接受的解决方案，最好的选择可能是尝试重构插入语句。

您没有说明您是否在插入语句中使用UNION或。UNION ALL我见过INSERT INTO产生UNION一些奇怪的查询计划，特别是在 SQL 2005 SP2 之前的版本上。

• Raj 建议删除并重新创建目标表 SELECT INTO是一种方法。

• 您还可以尝试将三个源查询中的每一个选择到它们自己的临时表中，然后将UNION这些临时表一起插入。

• 或者，您可以尝试结合使用这些建议 - 将并集的结果放入临时表中SELECT INTO，然后将其插入到目标表中。

我已经看到所有这些方法都解决了类似场景中的性能问题；测试将揭示哪种方式可以根据您拥有的数据提供最佳结果。