Sur un serveur SQL de production, je vois d'énormes pics intermittents dans le trafic de données. Jusqu'à 200 Mbit / s, ce qui entraîne des attentes d'E / S RÉSEAU qui, à leur tour, provoquent des délais d'expiration des requêtes. Comment savoir quelles requêtes renvoient de grands ensembles de résultats?
Réponses:
Vous pouvez le trouver dans les DMV :
SELECT session_id, num_writes, st.text AS statement_text
FROM sys.dm_exec_connections AS ec
CROSS APPLY sys.dm_exec_sql_text(ec.most_recent_sql_handle) AS st
ORDER BY num_writes DESCContrairement au traçage, il devrait être parfaitement sûr de s'exécuter sur un serveur de production.
Je prendrais une trace des données de production à l'aide de SQL Profiler et je rassemblerais le code / les lots qui ont les plus grandes lectures et écritures. Filtrez la trace pour obtenir uniquement les procédures et les lots dont le nombre de lectures / écritures est élevé. Choisissez un échantillon qui vous convient: disons plus d'un million de lectures ou d'écritures.
Je prendrais un échantillon de ces appels vers une machine de développement / test et les exécuterais dans Management Studio avec l'option 'Inclure les statistiques du client' activée (dans le menu Requête - Inclure les statistiques du client). Ensuite, vous aurez une fenêtre séparée avec des informations sur les statistiques du client: octets envoyés depuis le client, octets reçus du serveur.
NE PAS ACTIVER LE TRAÇAGE SUR UNE BD DE PRODUCTION SANS FILTRER LES DONNÉES !!! Filtrez le plus possible (par db, nom d'hôte, ce que vous croyez) et commencez ensuite la trace. N'oubliez pas de fermer le profileur après :-).
PS: Je me suis souvenu d'une autre option intéressante: le long de la trace pendant une période, vous devez également enregistrer les données en utilisant Perfmon (choisi uniquement les paramètres IO). Profiler a une fonctionnalité intéressante pour importer ensemble un fichier de trace et un fichier de données perfmon. Et vous pouvez y voir quand vous avez les plus gros pics d'E / S.
PS2: Je conviens que l'option de Gaius est plus élégante. Mais je laisse ma réponse volumineuse à la postérité! :-)
Si vous ne l'avez pas encore regardé, vous voudrez peut-être consulter sp_WhoIsActive d'Adam Machanic. Il a récemment publié une série de billets de blog expliquant les différentes fonctionnalités intégrées à sp_WhoIsActive, dont @delta_interval.
Non seulement cela vous montrera ce qui prend le plus de CPU ou d'E / S dans l'ensemble, mais cela peut également vous montrer ce qui prend le plus de CPU ou d'E / S en ce moment.
Consultez la série de blogs suivante pour une explication complète de cette fonctionnalité:
http://whoisactive.com/docs/01_background/
Le billet de blog suivant explique comment trier la sortie de sp_WhoIsActive et sélectionner les colonnes à afficher:
http://whoisactive.com/docs/24_output/
C'est l'un des nombreux messages disponibles sur le lien de mises à jour suivant qu'il a configuré.
La version 11.0 est disponible au moment de cette réponse, donc si vous utilisez une ancienne version, il est peut-être temps de mettre à niveau: D