MS SQL Server 2005 – 存储过程“自发中断”

它们具有运行易失性数据集的缓存转置的代码.编写存储过程以按需重新处理数据集,如果：
1.自上次重新处理以来,数据集已发生变化
2.数据集已保持5分钟不变

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

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

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

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

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

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

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

干杯,
民主党.

编辑：

pseduo代码如下：

>从table_x中读取“a”
>从table_x中读取“b”
>如果(a< b)返回
>开始交易
> DELETE table_y
> INSERT INTO table_y< 3选择联合在一起>
> UPDATE table_x
> COMMIT TRANSACTION

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

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

解决方法

WITH RECOMPILE可能是最快的修复 – 使用SET STATISTICS TIME ON来找出重新编译成本实际上是什么,然后解除它.

如果这仍然不是一个可接受的解决方案,最好的选择可能是尝试重构insert语句.

您没有说您是否在insert语句中使用UNION或UNION ALL.我已经看到INSION INTO与UNION产生了一些奇怪的查询计划,特别是在SP2之前版本的SQL 2005上.

> Raj的建议是放弃和
用.重新创建目标表
SELECT INTO是一种可行的方法.
>你也可以尝试选择每个
三个源查询到自己的
临时表,然后是UNION那些临时表
一起插入.
>或者,你可以尝试一下
这些建议的组合 –
将联盟的结果放入
SELECT INTO的临时表,
然后从那里插入到目标中
表.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!