La requête expire depuis l'application Web mais fonctionne correctement depuis le studio de gestion

Question

C'est une question que j'ai posée sur un autre forum qui a reçu des réponses décentes, mais je voulais voir si quelqu'un ici avait plus d'informations.

Le problème est que l'une de vos pages dans une application Web expire lorsqu'elle arrive à un appel de procédure stockée. Vous utilisez donc Sql Profiler ou les journaux de trace de votre application pour trouver la requête et vous la collez dans Management Studio pour comprendre. notre raison pour laquelle ça tourne lentement.Mais vous l'exécutez à partir de là et il continue, revenant en moins d'une seconde à chaque fois.

Mon cas particulier utilisait ASP.NET 2.0 et Sql Server 2005, mais je pense que le problème pourrait s'appliquer à n'importe quel système SGBDR.

Answer 1

C'est ce que j'ai appris jusqu'à présent grâce à mes recherches.

.NET envoie des paramètres de connexion qui ne sont pas les mêmes que ceux que vous obtenez lorsque vous vous connectez à Management Studio.Voici ce que vous voyez si vous reniflez la connexion avec Sql Profiler :

-- network protocol: TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
set concat_null_yields_null on  
set cursor_close_on_commit off  
set implicit_transactions off  
set language us_english  
set dateformat mdy  
set datefirst 7  
set transaction isolation level read committed  

Je colle maintenant ces paramètres au-dessus de chaque requête que j'exécute lorsque je suis connecté au serveur SQL, pour m'assurer que les paramètres sont les mêmes.

Dans ce cas, j'ai essayé chaque paramètre individuellement, après déconnexion et reconnexion, et j'ai constaté que le fait de changer arithabort de désactivé à activé réduisait la requête problématique de 90 secondes à 1 seconde.

L'explication la plus probable est liée au reniflage de paramètres, une technique utilisée par Sql Server pour sélectionner ce qu'il pense être le plan de requête le plus efficace.Lorsque vous modifiez l'un des paramètres de connexion, l'optimiseur de requêtes peut choisir un plan différent et, dans ce cas, il en a apparemment choisi un mauvais.

Mais je n'en suis pas totalement convaincu.J'ai essayé de comparer les plans de requête réels après avoir modifié ce paramètre et je n'ai pas encore vu le diff afficher des changements.

Y a-t-il autre chose dans le paramètre arithabort qui pourrait ralentir l'exécution d'une requête dans certains cas ?

La solution semblait simple :Mettez simplement set arithabort en haut de la procédure stockée.Mais cela pourrait conduire au problème inverse :modifiez les paramètres de la requête et tout à coup, elle s'exécute plus rapidement avec « off » qu'avec « on ».

Pour le moment, j'exécute la procédure « avec recompilation » pour m'assurer que le plan est régénéré à chaque fois.C'est correct pour ce rapport particulier, car la recompilation prend peut-être une seconde, et cela n'est pas trop visible sur un rapport qui prend 1 à 10 secondes pour revenir (c'est un monstre).

Mais ce n'est pas une option pour d'autres requêtes qui s'exécutent beaucoup plus fréquemment et doivent être renvoyées le plus rapidement possible, en quelques millisecondes seulement.

Answer 2

J'ai eu des problèmes similaires.Essayez de définir l'option with "WITH RECOMPILE" sur la création de procédure pour forcer le système à recalculer le plan d'exécution à chaque fois qu'il est appelé.Parfois, le processeur de requêtes est confus dans des procédures stockées complexes avec de nombreuses instructions de branchement ou de cas et obtient simplement un plan d'exécution vraiment sous-optimal.Si cela semble « résoudre » le problème, vous devrez probablement vérifier que les statistiques sont à jour et/ou décomposer le sproc.

Vous pouvez également le confirmer en profilant le sproc.Lorsque vous l'exécutez à partir de SQL Managment Studio, comment les E/S se comparent-elles à celles lorsque vous les profilez à partir de l'application ASP.NET.S'ils le font beaucoup, cela ne fait que renforcer le fait qu'il s'agit d'un mauvais plan d'exécution.

Answer 3

Avez-vous déjà activé le traçage ASP.NET ?J'ai eu un cas où ce n'était pas la procédure stockée SQL elle-même qui était le problème, c'était le fait que la procédure renvoyait 5 000 lignes et que l'application tentait de créer des ListItems liés aux données avec ces 5 000 éléments qui causaient le problème.

Vous pouvez également examiner les temps d'exécution entre les fonctions de l'application Web via la trace pour vous aider à suivre les choses.

Answer 4

testez d'abord cela sur une boîte de préparation, modifiez-le au niveau du serveur pour le serveur SQL

déclarer @option int

Définissez @Option = @@ Options | 64

Exec SP_CONFIGURE 'OPTIONS D'UTILISATION', @OPTION

RECONFIGURER

Answer 5

Même problème que j'ai eu avec les services de reporting SQL.Essayez de vérifier le type de variables, j'envoyais différents types de variables à SQL comme l'envoi VARCHAR en place où il devrait être entier, ou quelque chose comme ça.Après avoir synchronisé les types de variables dans Reporting Service et dans les procédures stockées sur SQL, j'ai résolu le problème.

Answer 6

Vous pouvez essayer d'utiliser la commande sp_who2 pour voir ce que fait le processus en question.Cela vous montrera s'il est bloqué par un autre processus ou s'il utilise une quantité excessive de temps CPU et/ou io.

Answer 7

Nous avons eu le même problème et voici ce que nous avons découvert.

la taille du journal de notre base de données était conservée par défaut (814 Mo) et la croissance automatique était de 10 %.Sur le serveur, la mémoire maximale du serveur a également été conservée au paramètre par défaut (2 147 483 647 Mo).

Lorsque notre journal était plein et devait croître, il utilisait toute la mémoire du serveur et il ne restait plus rien pour l'exécution du code, il a donc expiré.Ce que nous avons fini par faire a été de définir la taille initiale du fichier journal de la base de données sur 1 Mo et la mémoire maximale du serveur sur 2 048 Mo.Cela a instantanément résolu notre problème.Bien sûr, vous pouvez modifier ces deux propriétés en fonction de vos besoins, mais c'est une idée pour quelqu'un qui rencontre un problème de délai d'attente lors de l'exécution d'une procédure stockée via du code, mais elle s'exécute très rapidement dans SSMS et les solutions ci-dessus n'aident pas.

Answer 8

Essayez de modifier la valeur du délai d'expiration de SelectCommand :

DataAdapter.SelectCommand.CommandTimeout = 120;