Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Métriques de performances SQL Server pour garder une longueur d'avance

"Doc, je m'inquiète pour les performances de mon serveur SQL."

Ce n'était pas le genre de choses que vous entendez de la plupart des patients. Mais ensuite, en tant que professionnel rémunéré, j'ai été formé pour tout gérer, même les moments difficiles d'être un administrateur de base de données.

"Vraiment? Explorons cela, voulez-vous ?"

« Bien sûr, docteur. Je veux dire, parfois c'est tellement écrasant. Je pensais que tout fonctionnerait tout seul une fois que je m'y serais engagé. Mais avant de m'en rendre compte, j'ai commencé à avoir des problèmes de performances dans SQL Server 2012, puis 2014, puis 2017. Je ne veux même pas penser à SQL Server 2019. »

"Je vois. Eh bien, une bonne relation avec SQL Server ne se fait pas toute seule. Vous devez y travailler. Dites-moi, avez-vous travaillé sur vos techniques d'optimisation des performances de SQL Server ?"

"Euh, non, Doc. Je ne connais vraiment aucune de ces techniques."

"Ne vous inquiétez pas. Nous pouvons les travailler. Votre SQL Server se sent probablement négligé. Vous devez garder un œil dessus pour vous assurer que vous restez en tête du match. Cela nécessite une surveillance SQL Server."

"Surveillance? Comment fais-tu ça ?"

« Vous devez montrer à SQL Server que vous vous souciez d'eux. Il faut faire attention à certaines métriques. Nous pouvons travailler là-dessus aussi."

"D'accord, docteur. Peu importe ce que tu dis. Je suis prêt à tout essayer à ce stade. Les choses ne pourraient pas être bien pires qu'elles ne le sont maintenant."

"Bien alors. Commençons."

Métriques de performances SQL Server – Beaucoup de pièces mobiles

Le patient avait raison :surveiller les performances de votre serveur SQL peut sembler écrasant. Vous ne pouvez pas arrêter d'y prêter attention une fois qu'il est opérationnel. Vous devez continuer à lui montrer que vous vous souciez de lui.

SQL Server comporte de nombreuses pièces mobiles qui génèrent constamment des métriques. Savoir lesquels regarder et prendre le temps de les surveiller peut représenter beaucoup de travail pour un administrateur de base de données.

J'ai donc parcouru certains des principaux domaines des mesures de performances de SQL Server avec le patient.

Index

L'un des premiers endroits à regarder lorsque vous rencontrez des problèmes de performances avec SQL Server est les index. Vos données ne cessent de croître, donc vos index ne cessent de croître également. Mais ils sont soumis à des conditions telles que la fragmentation et les fractionnements de page qui peuvent ralentir la réponse aux requêtes.

Que se passe-t-il dans une base de données jour après jour ? Les utilisateurs créent, modifient et suppriment des enregistrements. Les index suivent l'emplacement de tous les éléments des enregistrements, mais au fil du temps, la fragmentation des index entrave les performances.

Ensuite, il y a le facteur de remplissage d'index, un paramètre que vous pouvez configurer dans SQL Server pour contrôler le nombre de fractionnements de page et augmenter l'efficacité des requêtes. Mais l'équilibre entre plus et moins de fractionnements de page affecte les performances d'autres manières.

Surveillance des statistiques dans le facteur de remplissage , E/S et fragmentation est un bon moyen de garder vos doigts sur le pouls de la santé de l'index SQL Server.

Cache tampon

Faisons simple :disque, lent; cache tampon, rapide. Le cache de tampon est une copie en mémoire des pages de base de données récemment utilisées. Si SQL Server n'y trouve pas ce qu'il recherche, il doit aller sur le disque, ce qui ralentit les performances.

SQL Server vous permet de spécifier la quantité de mémoire système à allouer au cache de tampon, mais vous faites un compromis sur la mémoire restante pour d'autres tâches. Votre objectif est d'allouer autant que possible sans entraver les performances de SQL Server dans d'autres domaines.

L'espérance de vie des pages est également importante, c'est-à-dire le temps qu'une page d'informations de la base de données passe dans la mémoire tampon sans être consultée à nouveau. SQL Server évince continuellement des pages du cache de tampons pour faire de la place pour celles qui ont été utilisées plus récemment. Mais moins il y trouve de pages utiles, plus il doit lire sur le disque, ce qui ralentit les performances.

Des statistiques telles que l'espérance de vie des pages et taux d'accès réussis dans le cache tampon vous aider à prendre des décisions concernant l'éviction moins fréquente de pages ou l'augmentation de la taille du cache.

T-SQL

SQL Server utilise un langage de requête appelé T-SQL. Plutôt que d'exécuter des instructions SQL ad hoc, SQL Server essaie d'améliorer les performances en les regroupant, en les compilant en tant que plan d'exécution et en les mettant en cache. Il essaie également de minimiser la fréquence de compilation et de réutiliser les plans d'exécution aussi souvent que possible. S'il ne peut pas réutiliser le plan d'exécution, par exemple parce que la base de données a trop changé, il recompilera le plan. Il est préférable de maintenir le nombre de recompilations d'instructions SQL aussi bas que possible, car le processus peut consommer de grandes quantités de CPU et dégrader les performances.

La nécessité de compiler et de recompiler est fonction des bonnes pratiques de codage, comme l'utilisation de procédures stockées et le paramétrage des requêtes. DBA qui surveillent des métriques telles que le taux de compilations SQL et recompilations SQL peut modifier les indicateurs de requête SQL Server pour améliorer les performances.

Verrouille, attend et bloque les processus

Il est frustrant de découvrir que quelqu'un d'autre modifie quelque chose en même temps que vous. Ainsi, les bases de données verrouillent automatiquement des éléments tels que des lignes et des tables pour empêcher plusieurs cuisiniers d'entrer dans la cuisine. Le compromis pour cette protection, bien sûr, est que tous les autres utilisateurs doivent attendre que la ressource soit déverrouillée. Et il est difficile de s'assurer que le verrouillage s'effectue uniquement au niveau nécessaire.

Avec des métriques qui montrent à quelle fréquence et dans quelle mesure les verrous affectent d'autres opérations, les administrateurs de base de données peuvent déterminer le besoin de davantage de ressources système physiques pour traiter les transactions plus rapidement. Il se peut également que SQL Server se verrouille à un niveau inutilement bas. La fréquence des attentes de verrouillage et, plus largement, le nombre de processus bloqués peut aider à localiser les goulots d'étranglement.

Éliminer les goulots d'étranglement grâce au réglage des performances SQL

"Mon Dieu, Doc, vous avez raison à propos de toutes les pièces mobiles. Maintenant, je vois comment je ne peux pas simplement installer SQL Server, le configurer et l'oublier. J'ai besoin de nourrir la relation. Mais tout cela semble toujours écrasant. Comment vais-je pouvoir garder tant de choses différentes en ordre et garder une longueur d'avance ?"

"C'est la meilleure partie. Il existe des outils qui peuvent vous aider à améliorer vos performances SQL Server. Vous n'êtes pas obligé d'y aller seul."

"Ouf! C'est rassurant. Je ne le savais pas."

"C'est exact. Les outils surveillent les performances de votre serveur SQL et rapportent toutes ces métriques afin que vous puissiez appliquer vos techniques de réglage et éliminer les goulots d'étranglement."

« Vraiment ? »

"Bien sûr. Et nous pouvons travailler là-dessus - oh, mon Dieu, nous n'avons plus de temps pour cette semaine. Veuillez prendre rendez-vous avec ma réceptionniste et nous viendrons vous chercher la semaine prochaine."

« Garçon, ces quatre heures sont passées vite, Doc ! Le temps passe vite lorsque vous résolvez des problèmes de performances liés à la fragmentation, à l'utilisation des ressources et taux d'accès au cache tampon , n'est-ce pas ?"

"Oui, et je suis sûr qu'une fois que vous aurez communiqué ouvertement sur ces problèmes avec votre serveur SQL, tous vos problèmes de performances feront partie de l'histoire."

Rassuré par notre séance, le patient est parti. La prochaine fois, nous travaillerons sur la surveillance des goulots d'étranglement des performances de SQL Server. Je vais bloguer à ce sujet, alors gardez un œil ouvert.

En attendant, fais-moi confiance. Je suis un professionnel rémunéré et je vous encourage à essayer ces choses dans votre propre relation avec votre base de données. Faites en sorte que votre serveur SQL se sente désiré. Faites attention à ses mesures de performance.

Il n'est jamais trop tard pour essayer.