2010-06-18 6 views
4

J'ai une requête SQL simple qui, lorsqu'elle est exécutée depuis C#, prend plus de 30 secondes, puis expire à chaque fois, tandis que lorsqu'elle est exécutée sur SQL Server Management Studio . Dans ce dernier cas, un plan d'exécution de requête ne révèle rien de troublant, et le temps d'exécution est bien réparti grâce à quelques opérations simples. J'ai exécuté 'EXEC sp_who2' alors que la requête est exécutée à partir de C#, et qu'elle est listée comme prenant 29 000 millisecondes de temps CPU, et n'est pas bloquée par quoi que ce soit.Temps d'exécution très différents de la requête SQL en C# et SQL Server Management Studio

Je ne sais pas comment résoudre ce problème. Quelqu'un a-t-il un aperçu?

La requête est:

SELECT 
    c.lngId, 
    ... 
FROM tblCase c 
    INNER JOIN tblCaseStatus s ON s.lngId = c.lngId 
    INNER JOIN tblCaseStatusType t ON t.lngId = s.lngId 
    INNER JOIN [Another Database]..tblCompany cm ON cm.lngId = cs.lngCompanyId 
WHERE t.lngId = 25 
    AND c.IsDeleted = 0 
    AND s.lngStatus = 1 
+1

Probablement un reniflage de paramètre ou une option SET différente. Est-ce une procédure stockée? Pour dépanner, utilisez SQL Profiler ou 'sys.dm_exec_query_plan' pour obtenir le plan d'exécution du C# et comparez-le avec celui de Management Studio. –

+1

S'agit-il d'une requête unique ou d'une procédure stockée? Utilisez l'outil Générateur de profils SQL pour exécuter une trace détaillée pendant l'exécution de la requête à partir de l'application pour vous assurer que les mêmes commandes de base de données sont exécutées et pour voir exactement la durée de la requête exécutée de cette manière. – NYSystemsAnalyst

+0

Ce n'est pas une procédure stockée pour le moment, il ne devrait donc pas y avoir de problèmes de compilation. Connaissez-vous d'éventuelles options SET qui pourraient être différentes, qui pourraient causer cela? Je pense que les options sont par défaut des deux côtés. – Paul

Répondre

5

Pour commencer, extraire le plan de requête de la requête lorsque est exécuté à partir C#:

select p.query_plan, * 
from sys.dm_exec_requests r 
cross apply sys.dm_exec_query_plan(r.plan_handle) p 
where r.session_id = <spid of C# connection> 

comparer ensuite avec le plan exécuté en vertu de la session SSMS (il suffit de cliquer sur Afficher le plan actuel dans la barre d'outils).

Et, en règle générale, essayez toujours d'appliquer une approche méthodique plutôt que de deviner. Wait and Queues est une très bonne méthodologie de dépannage des performances éprouvée pour SQL Server.

Questions connexes