Si vous recevez un appel/une page concernant un problème de performance du serveur SQL, que faites-vous en premier ?
Commencer une trace ? Afficher Perfmon ? Ouvrir le moniteur d'activité ?
Chacun de ces outils est utile, mais quelle est votre "séquence" de dépannage ?
Ça dépend.
S'agit-il d'un problème soudain et inattendu de lenteur ou d'un cas à long terme de mauvaises performances générales ?
Si c'est le premier, je commencerai par les DMV liées à l'exécution (sys.dm_exec_requests). Y a-t-il des blocages ? Y a-t-il une requête qui s'exécute excessivement longtemps ou qui utilise des ressources massives ? En gros, je vais chercher quelque chose d'anormal (attention, pour pouvoir voir cela, je dois savoir ce qui est normal).
Si c'est le cas, j'utiliserai la méthode que j'ai décrite dans ces articles.
Première chose ? Parler à l'utilisateur.
Qu'est-ce qui a changé ?
Ces mauvaises performances sont-elles nouvelles ? Sont-elles apparues lentement ou se sont-elles accumulées ?
Que montrent vos rapports historiques (SQLH2) sur le dernier mois ?
Vérifiez l'espace disque, l'utilisation de la mémoire vive et l'utilisation du processeur sur le serveur (dans cet ordre). Le serveur a-t-il été configuré correctement en premier lieu (paramètres de la RAM) - Taskmgr.
Vérifiez vous-même les performances. Vous semble-t-il lent ?
L'utilisateur s'est-il habitué aux performances "instantanées" d'un nouveau système (sans données) et commence-t-il maintenant à s'essouffler ?
...Vous pourrez alors commencer à étudier les problèmes éventuels. Vous devez d'abord établir un point de référence, sinon vous ne saurez jamais quand vous aurez terminé.
Utilice SQLIO . Vous pouvez lire tout un tas de choses sur les commutateurs/incantations à utiliser, mais le simple fait de l'exécuter sur les lecteurs où sont stockés vos MDF/LDF (par exemple sqlio.exe /dCDE) vous donnera un grand titre de lecture "MBs/sec" pour les comparaisons. J'ai découvert que les mauvaises performances de notre application sur le site d'un client étaient dues à la contention des disques/LUN sur un système de disques Hitachi AMS (fibre channel). Le disque de mon ordinateur portable était 10 fois plus performant ! Dès que notre base de données a obtenu son propre LUN, notre application était à nouveau heureuse.
Avant même de faire toutes les suggestions ci-dessus, je ferais ceci :
SELECT
@@total_read AS 'Total Read',
@@total_write AS 'Total Write',
@@total_errors AS 'Total Error',
@@io_busy AS 'IO Processing Time (ms)',
@@cpu_busy AS 'CPU Processing Time (ms)',
@@idle AS 'Idle Time (ms)'[Je fais référence à mon article de blog : http://dbalink.wordpress.com/2009/04/28/monitoring-sql-server-performance-quickie-edition/ ]
Vérifiez les fichiers journaux, en particulier la journalisation des "longues requêtes" que vous pouvez avoir activée. Si elle n'est pas activée, activez-la.
Vérifiez la santé générale de la machine - ce n'est peut-être pas le serveur SQL, mais l'ensemble de la machine - vérifiez les processus qui s'emballent, l'utilisation globale du processeur, l'utilisation globale de la mémoire - vous faites des graphiques de ces choses avec cacti ou autre pour des comparaisons historiques, non ? Vérifiez donc les graphiques et voyez quand ce qui est lent a commencé à l'être.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
