Utilisation de SQL Profiler sur une base de données en production

En tant que développeur, j'utilise assez souvent SQL Profiler. C'est un bon outil de débogage, à la fois pour suivre ce que fait mon code et pour analyser les problèmes de performances.

Mais je l'ai toujours utilisé sur mon environnement de développement , et de manière très contrôlée.

• Démarrer mon application et la mettre dans un état spécifique
• Démarrer une trace sur le profileur
• Effectuer une séquence d'actions spécifique sur mon application
• Arrêtez la trace et examinez les résultats.

Le SQL Profiler peut-il être utilisé pratiquement dans un environnement en production?

Ma première préoccupation est que cela dégraderait les performances.

Ma deuxième préoccupation est que, parce qu'il est en production, vous ne déclenchez pas les actions intéressantes elles-mêmes. Vous devrez laisser le profileur en marche pendant une longue période, puis analyser les résultats. Le jeu de résultats deviendrait-il trop lourd? (Prendre trop d'espace disque et être trop difficile à interroger).

Quelqu'un utilise-t-il le SQL Profiler en production?

L'utilisation de Sql Server Profiler (outil GUI) pour tracer un serveur de production n'est pas une bonne idée. Mais cela dépend de la charge. Utilisez le suivi SQL côté serveur (voir les procédures sp_trace_XXX ) à la place. J'ai aussi trouvé des articles:

Impact sur les performances: suivi du profileur par rapport au suivi SQL côté serveur ,

Automatisation du suivi côté serveur dans SQL Server

Évitez de provoquer des problèmes avec Profiler

il sera peut-être intéressé et utile.

Livre en ligne dit:

• Exécutez Profiler à distance au lieu de directement sur le serveur
• Évitez d'inclure des événements qui se produisent fréquemment (par exemple, verrouillage: acquis), sauf en cas de nécessité absolue
• Inclure uniquement les classes d'événements nécessaires
• Spécifiez des filtres de limitation pour réduire le nombre d'événements
• Évitez les données redondantes (par exemple SQL: BatchStarting et SQL: BatchCompleted)
• Évitez d'exécuter de grandes traces avec Profiler; considérez plutôt une trace SQL côté serveur
• Limitez la taille du fichier de trace côté serveur et gérez l'utilisation de l'espace

J'utilise SQL Profiler contre la production tout le temps. Lorsqu'il est effectué correctement (filtrage afin de récupérer une très petite quantité de données) contre un serveur, le risque est minime. Retracer tout serait inutile.

1. Oui, l'acte de surveillance nécessitera des ressources. L'exécuter sur un serveur surchargé pourrait le tuer.

2. Vous surveillerez en fait la charge réelle: vos actions pourraient se perdre dans le bruit de cette charge.

Nous l'exécutons parfois en production. Principalement avec un filtre de texte pour du code spécifique, ou avec des filtres CPU / durée pour intercepter les requêtes plus longues. Et nous n'essayons pas de capturer des plans d'exécution XML ou une telle absurdité

L'essentiel est de savoir ce que vous cherchez: nous n'avons pas tendance à le laisser fonctionner et à tout piéger.

Dans ce cas, si vous voulez voir les résultats de certaines actions, pouvez-vous le faire en dehors des heures?

Le profileur introduira toujours un impact sur les performances.

Si vous utilisez SQL Server 2008R2 +, vous pouvez utiliser des événements étendus. Cela fournit une grande partie des informations que vous voyez dans le profileur avec une fraction de la performance atteinte.

Introduction aux livres en ligne http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Cette fonctionnalité a reçu une grosse mise à jour dans SQL Server 2012 qui inclut désormais une interface graphique dans SSMS.