我们的测试和开发环境中存在一个问题,其功能在从.Net应用程序调用时运行得非常慢。当我们直接从管理工作室调用此函数时,它工作正常。
以下是分析时的差异:
来自申请:
CPU:906
阅读:61853
写道:0
持续时间:926年
来自SSMS:
CPU:15
阅读:11243
写道:0
持续时间:31周
现在我们已经确定,当我们重新编译该函数时,性能将返回到我们期望的状态,并且从应用程序运行时的性能配置文件与从SSMS运行时获得的性能配置文件相匹配。它将以随机间隔开始再次减速。
我们还没有看到这一点,但它们可能部分是因为每周都会重新编译所有内容。
那么可能会导致这种行为?
编辑 -
我们终于能够解决这个问题并重组变量来处理参数嗅探似乎已经完成了这个诀窍......我们在这里做了一个片段:感谢您的帮助。
-- create set of local variables for input parameters - this is to help performance - vis a vis "parameter sniffing"
declare @dtDate_Local datetime
,@vcPriceType_Local varchar(10)
,@iTradingStrategyID_Local int
,@iAccountID_Local int
,@vcSymbol_Local varchar(10)
,@vcTradeSymbol_Local varchar(10)
,@iDerivativeSymbolID_Local int
,@bExcludeZeroPriceTrades_Local bit
declare @dtMaxAggregatedDate smalldatetime
,@iSymbolID int
,@iDerivativePriceTypeID int
select @dtDate_Local = @dtDate
,@vcPriceType_Local = @vcPriceType
,@iTradingStrategyID_Local = @iTradingStrategyID
,@iAccountID_Local = @iAccountID
,@vcSymbol_Local = @vcSymbol
,@vcTradeSymbol_Local = @vcTradeSymbol
,@iDerivativeSymbolID_Local = @iDerivativeSymbolID
,@bExcludeZeroPriceTrades_Local = @bExcludeZeroPriceTrades
答案 0 :(得分:5)
我对存储过程有类似的问题,对我而言,结果是'参数嗅探'。谷歌,并看看它是否解决了你的问题,对我来说,一旦我修复它,它是戏剧性的加速。
在我的例子中,我通过为传入的每个参数声明一个局部变量来修复它,然后将局部变量分配给该参数值,并且proc的其余部分使用局部变量进行处理... for无论什么原因,这都打败了参数嗅探。
答案 1 :(得分:4)
这通常是因为您在SSMS连接中获得了不同的执行计划。通常与参数嗅探问题相关,其中计划生成时具有对于其他参数值次优的特定值。这也解释了为什么重新编译会解决问题。这个主题似乎有一个很好的解释Parameter Sniffing (or Spoofing) in SQL Server
答案 2 :(得分:4)
可能的原因是过时的统计信息和/或参数嗅探导致重新使用的缓存查询计划不是最佳的。
SSMS会发出您看不到的pre-amble语句,这会导致每次都重新编译提交的查询,从而消除了使用不正确的缓存计划的可能性。
这将更新所有统计信息并刷新视图和存储过程(但要小心在生产计算机上运行):
EXEC sp_updatestats
EXEC sp_refreshview
EXEC sp_msForEachTable 'EXEC sp_recompile ''?'''