Le profileur SQL affecte-t-il les performances du serveur?

Je suis confronté à un problème où le serveur SQL 2008 échoue pour une charge élevée. J'ai besoin de trouver ce cas de charge et d'optimiser le code afin qu'il puisse gérer la charge. J'ai trouvé sur Internet que le profileur SQL peut être utilisé pour suivre les interactions de la base de données qui peuvent ensuite être analysées pour trouver le point exact où le problème se produit. J'ai également trouvé comment démarrer le profileur SQL. Mais maintenant, ma question est qu'en démarrant le profileur SQL, vais-je affecter les performances du serveur?

SQL Server Profiler est une interface graphique qui utilise la trace SQL Server via le côté client. En raison de cette nature, oui, vous pouvez potentiellement voir un impact de performance léger à sévère selon l'environnement.

SQL Server Profiler convient principalement pour un aperçu rapide de ce qui se passe sur le serveur (à condition que le serveur de base de données puisse gérer la latence supplémentaire). Il n'est pas destiné à être exécuté pendant de longues périodes. Pour des traces plus longues, utilisez une trace côté serveur ou des événements étendus.

Si vous utilisez le suivi côté serveur , l'impact sur les performances peut être minimisé.

Tout ce que les affiches précédentes ont dit est correct. Profiler est une application qui, à un moment donné, a utilisé DMO et utilise désormais SMO pour capturer les événements de trace. Cela ajoute une énorme quantité de surcharge par rapport à la simple utilisation d'une trace côté serveur.

SMO est une API qui ajoute un "niveau" supplémentaire au processus de suivi avec une application cliente, Profiler. Une trace côté serveur lira les événements de trace directement à partir d'une file d'attente de transactions, dont la surcharge résultante est négligeable.

J'ai pu exécuter des traces côté serveur dans des environnements SQL Server qui traitent plus de 10 000 transactions par seconde. L'utilisation de Profiler dans ces mêmes environnements mettra l'instance de base de données à genoux. Dans tout environnement de production, si vous devez suivre l'activité de la base de données, utilisez toujours une trace côté serveur. Le profileur va tuer l'instance de base de données.

Oui, SQL Server Profiler affecte les performances.

Lorsque vous tracez à l'aide de l'interface graphique, tous les événements sont traités et filtrés de manière synchrone, donc des facteurs tels que la charge du serveur, la latence du réseau, les événements que vous collectez et même où les événements collectés sont stockés, contribuent tous à la surcharge.

Comme d'autres réponses l'ont suggéré, il est préférable d'utiliser une trace côté serveur au lieu de l'interface graphique. Cependant, cette méthode est obsolète et les événements étendus doivent être utilisés à la place. (Remarque: même en utilisant des événements étendus, qui sont plus légers qu'une trace, il est toujours possible d'ajouter une quantité indésirable de charge au serveur - voir la liste dans mon deuxième paragraphe pour réfléchir à la façon de minimiser la surcharge lors de la configuration d'un événement session.)

Dans le cas d'un serveur lourdement chargé, vous devez faire très attention aux informations collectées, car le processus de mesure lui-même peut affecter le problème étudié.

SQL Server Profiler fonctionne en deux étapes: vous lui dites d'abord de consigner toutes les requêtes. Ensuite, vous exécutez certaines transactions typiques (ou laissez-le simplement se connecter à la production). Cela crée une "charge de test". Ensuite, vous effectuez le profilage réel (analyse) à l'aide de la charge de test.

La journalisation n'est pas très coûteuse, surtout par rapport au coût des requêtes elles-mêmes.