实体框架4存储过程调用时间输出

Question

我有一个导入EF4的存储过程,当我在30秒后用某些参数调用它时会抛出超时错误.在SQL Server探查器中,我可以看到存储过程调用使用适当的参数只需要超过30秒,这是我的应用程序的超时.

但是,当我执行在查询分析器中发送到探查器的相同SQL时,它会执行亚秒级.什么可能导致从EF调用和从SQL Server Management Studio调用之间的这种差异？

下面是.NET错误的完整堆栈跟踪.

[SqlException(0x80131904):超时已过期.操作完成之前经过的超时时间或服务器没有响应.]
System.Data.SqlClient.SqlConnection.OnError(SqlException exception,Boolean breakConnection)+2073486
System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception,Boolean breakConnection)+5064444
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()+234
System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior,SqlCommand cmdHandler,SqlDataReader dataStream,BulkCopySimpleResultSet bulkCopyHandler,TdsParserStateObject stateObj)+2275
System.Data.SqlClient. SqlDataReader.ConsumeMetaData()+ 33
System.Data.SqlClient.SqlDataReader.get_MetaData()+86
System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds,RunBehavior runBehavior,String resetOptionsString)+311
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBehavior,RunBehavior runBehavior,Boolean returnStream,Boolean async)+987
System.Data.SqlClient.SqlCommand.RunExecuteReade r(CommandBehavior cmdBehavior,RunBehavior runBehavior,Boolean returnStream,String方法,DbAsyncResult结果)+162
System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior,RunBehavior runBehavior,Boolean returnStream,String method)+32
System.Data.SqlClient.SqlCommand .ExecuteReader(CommandBehavior behavior,String method)+141
System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)+12
System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior)+10 System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands (EntityCommand entityCommand,CommandBehavior behavior)+443

[EntityCommandExecutionException:执行命令定义时发生错误.详情请参阅内部异常.]
System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand,行为的CommandBehavior)479
System.Data.Objects.ObjectContext.CreateFunctionObjectResult(EntityCommand entityCommand,EntitySet的EntitySet的,EdmType edmType,MergeOption mergeOption)+ 182
System.Data.Objects.ObjectContext.ExecuteFunction(字符串functionName,而MergeOption mergeOption,ObjectParameter []参数)218
System.Data.Objects.ObjectContext.ExecuteFunction(字符串functionName,而ObjectParameter []参数)53个
MetaView.DAL.MFCMData.MFCMDATAEntities .GetTradingOpenPositionCounterParty(可空1 positionDT, Nullable1个tradingAccountID)在C:\项目\ CASH \网络\ MetaView\MetaView.DAL.MFCMData\MFCMData.Designer.cs:7064个MetaView.BusinessLayer.Shared.Accounts.CounterParties.GetCounterParties(的Int32 tradingAccountID)在C: \项目\ CASH \网络\ MetaView\MetaView.BusinessLayer \共享\帐户\ CounterParties.cs:161

Answer 1

所以几个星期前我遇到了一个类似的问题,我们的一位DBA就这样解释过了(当然我已经解释并愚蠢了):

当SQL Server存储过程被调用时,服务器创建并缓存在每个存储过程的执行计划每object_id.有时,SQL Server可以创建一个错误的执行计划,具体取决于传入的参数值(在我们的例子中,对于可为空的参数,它是null).发生这种情况时,快速修复是sp_recompile 'Schema.Procedure'在SQL Server Management Studio(或您可能正在使用的任何数据库管理工具)中运行.所有这一切都清楚了该存储过程的计划缓存.如果proc的下一个被调用者再次传递"bad"参数值,那么你将陷入相同的情况,所以真正的解决方法是使用OPTIMIZE FOR语法为查询提供一个提示(请参阅http://msdn.microsoft.com /en-gb/library/ms181714.aspx).

简而言之,如果你OPTION (OPTIMIZE FOR (@myParameter = 'Some value that gives you a GOOD execution plan'))在你的WHERE和/或ORDER BY条款之后添加它应该解决问题.

此外,如果您想知道为什么在SSMS中执行相同的 SQL时总是得到快速结果,因为SSMS默认设置为ON,这个选项名为ARITHABORT(SET ARITHABORT ON),默认情况下所有其他应用程序都设置为OFF,但是如何作品及其影响超出了我的经验,我没有费心去阅读它.有人告诉我,我不应该使用它.我确信真正的DBA可以更好地解释原因.