Entity Framework 4 Procédure stockée Délai d'attente d'appel
J'ai une procédure stockée importés dans EF4, et quand je l'appelle avec certains paramètres après 30 secondes, il lève une erreur de délai. Dans SQL Server profiler, je peux voir l'appel de procédure stockée avec des paramètres appropriés, en prenant un peu plus de 30 secondes, ce qui est le délai d'attente sur ma demande.
CEPENDANT lorsque j'exécute les mêmes SQL envoyé à la profiler dans l'Analyseur de Requêtes, il s'exécute sous-seconde. Quelle est la cause de cette contradiction entre le fait d'être appelé à partir d'EF et d'être appelé à partir de SQL Server Management Studio?
Full stack trace .NET d'erreur ci-dessous.
[SqlException (0x80131904): Délai d'attente expiré. Le délai d'attente
écoulé avant la fin de l'opération ou le serveur n'est pas
répondre.]
Système.Les données.SqlClient.SqlConnection.OnError(exception SqlException,
Valeur de type Boolean breakConnection) +2073486
Système.Les données.SqlClient.SqlInternalConnection.OnError(SqlException
exception, d'une valeur de type Boolean breakConnection) +5064444
Système.Les données.SqlClient.TdsParser.ThrowExceptionAndWarning() +234
Système.Les données.SqlClient.TdsParser.Exécuter(RunBehavior runBehavior,
SqlCommand cmdHandler, SqlDataReader dataStream,
BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject
stateObj) +2275
Système.Les données.SqlClient.SqlDataReader.ConsumeMetaData() +33
Système.Les données.SqlClient.SqlDataReader.get_MetaData() +86
Système.Les données.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds,
RunBehavior runBehavior, Chaîne resetOptionsString) +311
Système.Les données.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean
async) +987
Système.Les données.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Chaîne
méthode, DbAsyncResult résultat) +162
Système.Les données.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Chaîne
la méthode) +32
Système.Les données.SqlClient.SqlCommand.ExecuteReader(CommandBehavior
le comportement, la méthode de Chaîne) +141
Système.Les données.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior
le comportement) +12
Système.Les données.Commun.DbCommand.ExecuteReader(CommandBehavior comportement)
+10 Système.Les données.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand
entityCommand CommandBehavior comportement) +443[EntityCommandExecutionException: Une erreur s'est produite lors de l'exécution
la définition de commande. Voir l'exception interne pour plus de détails.]
Système.Les données.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand
entityCommand CommandBehavior comportement) +479
Système.Les données.Objets.ObjectContext.CreateFunctionObjectResult(EntityCommand
entityCommand EntitySet entitySet, EdmType edmType, MergeOption
mergeOption) +182
Système.Les données.Objets.ObjectContext.ExecuteFunction(String functionName,
MergeOption mergeOption, ObjectParameter[] paramètres) +218
Système.Les données.Objets.ObjectContext.ExecuteFunction(String functionName,
ObjectParameter[] paramètres) +53
MetaView.DAL.MFCMData.MFCMDATAEntities.GetTradingOpenPositionCounterParty(Nullable11 tradingAccountID)
positionDT, Nullable
C:\Projets\TRÉSORERIE\web\MetaView\MetaView.DAL.MFCMData\MFCMData.Le concepteur.cs:7064
MetaView.BusinessLayer.Partagé.Comptes.Les contreparties.GetCounterParties(Int32
tradingAccountID)
C:\Projets\TRÉSORERIE\web\MetaView\MetaView.BusinessLayer\Shared\Comptes\Contreparties.cs:161
source d'informationauteur Jason Lind
Vous devez vous connecter pour publier un commentaire.
Donc j'ai eu un problème similaire il y a quelques semaines, qui m'a expliqué par l'un de nos Administrateurs de bases de données ainsi (reformulation et de bêtise à mon niveau bien sûr):
Lorsqu'une procédure stockée SQL Server est appelé, le serveur crée et met en cache un plan d'exécution par la procédure stockée par
object_id. Parfois, une mauvaise exécution d'un plan peut être créé par SQL Server en fonction de la valeur du paramètre qui est passé (dans notre cas, il était nul pour un nullable paramètre). Lorsque cela se produit, la solution consiste à exécutersp_recompile 'Schema.Procedure'dans SQL Server Management Studio (ou quelle que soit la DB outil de gestion que vous utilisez peut-être). Tout cela n'est d'effacer le cache de plan pour cette procédure stockée. Si le prochain appel de la proc passe dans le "mauvais" valeur du paramètre de nouveau, vous serez coincé dans la même situation de sorte que la vraie solution est de donner à la requête d'un indice à l'aide de laOPTIMIZE FORsyntaxe (voir http://msdn.microsoft.com/en-gb/library/ms181714.aspx).En bref si vous ajoutez
OPTION (OPTIMIZE FOR (@myParameter = 'Some value that gives you a GOOD execution plan'))après votreWHEREet/ouORDER BYclauses elle devrait résoudre le problème.Aussi, si vous vous demandez pourquoi lors de l'exécution de la même SQL dans SSMS vous obtenez toujours des résultats rapides, c'est parce que SSMS a un paramètre par défaut pour l'option ARITHABORT (
SET ARITHABORT ON) de laquelle toutes les autres applications ont DÉSACTIVÉ par défaut, mais la façon dont il fonctionne et ses conséquences sont au-delà de mon expérience et je n'ai pas pris la peine de la lire. J'ai dit que je ne dois pas l'utiliser. Je suis sûr qu'un réel DBA peut faire un meilleur travail en expliquant pourquoi.