它们具有运行易失性数据集的缓存转置的代码.编写存储过程以按需重新处理数据集,如果：
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
解决方法
WITH RECOMPILE可能是最快的修复 – 使用SET STATISTICS TIME ON来找出重新编译成本实际上是什么,然后解除它.
如果这仍然不是一个可接受的解决方案,最好的选择可能是尝试重构insert语句.
您没有说您是否在insert语句中使用UNION或UNION ALL.我已经看到INSION INTO与UNION产生了一些奇怪的查询计划,特别是在SP2之前版本的sql 2005上.
> Raj的建议是放弃和
用.重新创建目标表
SELECT INTO是一种可行的方法.
>你也可以尝试选择每个
三个源查询到自己的
临时表,然后是UNION那些临时表
一起插入.
>或者,你可以尝试一下
这些建议的组合 –
将联盟的结果放入
SELECT INTO的临时表,
然后从那里插入到目标中
表.
