web-dev-qa-db-fra.com

Suivi des erreurs de délai d'expiration d'application dans SQL Server

SQL Server 2008 SP3

Comment localiser ces erreurs de dépassement de délai?

enter image description here

Les erreurs sont affichées sur un tableau de bord intranet utilisé spécifiquement pour le rapport d'erreurs dans IIS. Je soupçonne qu'il y a un délai d'attente par défaut de 30 secondes dans l'application Web et si une requête prend plus de trente secondes, une exception est levée. Comme de nombreuses requêtes prennent plus de 30 secondes sur ces serveurs SQL, je ne peux pas simplement filtrer dans le profileur en fonction de la durée.

Deux serveurs IIS récupèrent les données de sept instances SQL Server) desservant le site Web surveillé par ce tableau de bord.

Puis-je utiliser "Événement de message d'erreur utilisateur" et "Événement d'erreur OLEDB" pour suivre ces erreurs dans SQL Server Profiler?

sql-serverquery-timeoutconnectivity
8
Craig Efrein

Aaron Bertrand m'a mis sur la bonne voie avec son commentaire

Et je pense que vous devriez pouvoir filtrer la durée et l'erreur <> 0.

Création d'une trace côté serveur à l'aide du modèle de profil tsql_duration

  1. Ajout de l'événement de message d'erreur utilisateur

  2. Ajout des filtres suivants

    erreur <> 0

    erreur <> 1

    gravité <> 10

Cela a évité de capturer les commandes SE DATABASE

Le message d'erreur capturé par le profileur était 2 - Abandonner et la classe d'événements était 10 RPC: terminé.

5
Craig Efrein

Vous pouvez utiliser l'événement Attention dans le profileur avec les événements pour capturer les instructions T-SQL. Il ne précise pas nécessairement ce qu'est l'événement d'attention lorsque je l'ai testé, donc je suppose que le fait qu'il suit la séquence d'événements vous permet d'estimer les requêtes qui ont un problème. Je n'ai pas eu l'occasion de le tester complètement avec du code et tout.

J'ai cependant rencontré un exemple exact avec des événements étendus qui peuvent être utilisés pour trouver des requêtes de délai d'expiration, et cet exemple est avec SQL Server 2008. Il est de Jonathan Kehayias: n XEvent par jour (9 sur 31) - Cibles Semaine - pair_matching

Les erreurs de délai d'attente sont côté client et l'erreur provient du fournisseur (ou client) utilisé avec la connexion à la base de données. SQL Server ne suit pas nécessairement ni n'offre aucune méthode intuitive pour les retrouver.

À l'aide d'une trace, les délais d'expiration côté SQL Server sont essentiellement des requêtes qui ont un début mais pas de fin. Je suis tombé sur une très bonne vidéo qui passe par un exemple de Sean McCown Trouver les délais d'expiration des requêtes avec Profiler . Maintenant, ce n'est pas une preuve solide comme le note Sean dans la vidéo, il y a d'autres choses qui pourraient empêcher une transaction de se terminer.

Un résumé des étapes:

  • Créer une trace dans Profiler qui capture les événements de début et de fin pour les procédures stockées et TSQL
  • Chargez ces données dans une table
  • Recherchez ces données pour rechercher les événements de début, puis les événements de fin.

Comme l'exemple va dans la vidéo pour SP:Starting (44) et SP:Completed (43) une fois vos données de trace dans une table:

SELECT *
INTO #TraceStart
FROM MyTraceData
WHERE EventClass = 44

SELECT *
INTO #TraceEnd
FROM MyTraceData
WHERE EventClass = 45

SELECT TextData
FROM #TraceStart
EXCEPT
SELECT TextData
FROM #TraceEnd

Je m'attendrais à ce que cela soit plus facile à faire avec les événements étendus, mais je n'ai jamais essayé de transférer cette méthode vers les événements étendus. Je ne sais pas si la version SQL Server 2008 des événements étendus a ouvert l'accès aux erreurs au niveau du client comme 2012 et les versions ultérieures. Ce qui précède n'est qu'une méthode rapide et sale qui fonctionne toujours.

2
user507

Vérifiez-vous également le blocage?

Le blocage pourrait certainement contribuer à des délais d'attente et peut être assez facilement suivi. Un délai d'attente qui n'est pas lié à un bloc présente un autre problème. Le délai d'expiration de 30 secondes est un paramètre client commun , mais il peut être contrôlé par l'objet de commande. Si vous le définissez sur 0, la connexion n'expirera pas.

Pour configurer la surveillance du blocage à l'aide des notifications d'événements et du Service Broker, lisez le message de Tony Rogerson:

http://sqlblogcasts.com/blogs/tonyrogerson/archive/2007/04/06/event-notifications-monitoring-blocked-processes-and-other-events-end-to-end-how-to- set-it-up-and-make-it-work.aspx

Dans son exemple, il surveille les blocs de 10 secondes ou plus (et pour chaque incrément de période, 20, 30, 40 secondes, etc.) Je surveille toutes les 25 secondes, ce qui me donne un aperçu du délai d'expiration de ce qui est en cours d'exécution . Les processus bloqués et bloquants apparaîtront dans la description XML du bloc.

La conservation des informations dans un tableau fournit également un historique que vous pouvez consulter au fil du temps.

1
RLF