La maintenance d'instances SQL Server hautes performances représente une grande partie des responsabilités professionnelles d'un administrateur de bases de données. Le fait de ne pas détecter et corriger une activité inhabituelle peut affecter les opérations internes et nuire aux résultats de l'entreprise.
Si vous remarquez des changements d'activité de pointe ou des anomalies dans une instance SQL Server, voici trois endroits pour commencer votre recherche de réponses.
Espérance de vie des pages
L'espérance de vie des pages (PLE) d'une instance doit conserver une plage de valeurs assez cohérente. Si cette valeur chute et reste faible, c'est un signe que le pool de mémoire tampon connaît une demande accrue.
Avant d'épuiser et d'augmenter la mémoire, examinez l'activité de la charge de travail. Si la charge de travail a augmenté, cela expliquerait la pression supplémentaire sur le pool de mémoire tampon. Mais si la charge de travail n'a pas changé, vous devrez regarder de plus près pour identifier ce qui utilise la mémoire supplémentaire.
Les raisons possibles d'une baisse de PLE incluent l'exécution active de tâches de maintenance, de reconstructions d'index ou de mises à jour de statistiques, d'opérations DBCC et de modifications du plan de requête.
Si vous remarquez une baisse du PLE qui n'est pas associée à une augmentation de la charge de travail, vous pouvez essayer plusieurs choses pour améliorer le PLE d'une instance :
- Supprimer les index inutilisés
- Fusionner les index en double
- Attention aux requêtes volumineuses
- Défragmenter
- Purger les données
Temps d'attente WRITELOG
Lorsque le temps d'attente WRITELOG représente une trop grande proportion du temps d'attente total, vous avez probablement un goulot d'étranglement sur votre instance SQL Server. Le goulot d'étranglement est probablement causé soit par un problème sur le disque sur lequel le journal des transactions est stocké, soit par une validation inefficace des données.
Pour déterminer à quel type de goulot d'étranglement vous avez affaire, commencez par analyser le nombre d'instructions SQL en attente de l'événement WRITELOG. S'il y a beaucoup d'instructions en attente, vous avez un goulot d'étranglement de disque. S'il n'y a que quelques instructions en attente, les données sont probablement validées trop souvent.
Il existe plusieurs façons de résoudre le temps d'attente élevé de WRITELOG une fois que vous avez déterminé si votre goulot d'étranglement est lié au disque ou à la validation :
- Ajouter de la bande passante d'E/S au disque sur lequel le journal des transactions est stocké
- Déplacer les E/S du journal non transactionnel du disque
- Déplacer le journal des transactions vers un disque moins occupé
- Réduire la taille du journal des transactions
- Assurez-vous que l'instruction COMMIT est placée dans le code afin que les données ne soient pas validées trop fréquemment
TempDB
TempDB est un espace de travail temporaire dans SQL Server qui contient des objets temporaires. Étant donné que les objets contenus dans TempDB sont transitoires, une instance SQL Server recrée TempDB à chaque redémarrage. Cela rend l'optimisation de TempDB essentielle pour maintenir les performances et éviter les goulots d'étranglement opérationnels.
La contention TempDB est l'un des principaux responsables de la dégradation des performances. Un conflit se produit lorsque plusieurs ressources ont besoin d'accéder à TempDB alors qu'il n'y a qu'un seul fichier de données TempDB. Cela provoque un goulot d'étranglement car les processus ne peuvent pas accéder à TempDB assez rapidement, ce qui entraîne l'expiration des connexions et la désallocation des processus.
Heureusement, les goulots d'étranglement TempDB peuvent être résolus assez facilement en ajustant le nombre et la taille des fichiers TempDB. Lors de l'installation, la valeur par défaut de SQL Server est un fichier de données TempDB. Si vous remarquez qu'un conflit se produit, il est recommandé d'ajouter huit nouveaux fichiers de données et de déterminer si cela résout le problème. Si le problème n'est pas résolu, essayez d'ajouter des fichiers de données supplémentaires par multiples de quatre jusqu'à ce que les performances soient restaurées.
Bien qu'il soit bon de savoir par où commencer lorsque vous rencontrez des problèmes de performances, chacun des problèmes ci-dessus et les goulots d'étranglement qui en résultent peuvent être atténués ou évités en mettant en œuvre une règle stricte et rapide :la surveillance des mesures de performances n'est pas facultative. Voici quelques exemples de statistiques clés à suivre :
Espérance de vie de la page :suivez PLE avec une surveillance continue et soyez proactif lorsqu'il tombe et reste en dessous de la valeur typique pour une instance SQL Server particulière.
Temps d'attente WRITELOG :surveillez les métriques telles que la croissance des journaux, la réduction des journaux, le pourcentage d'utilisation des journaux et les attentes de vidage des journaux/s.
Inefficacité de TempDB :surveillez ce qui est alloué aux objets utilisateur, au magasin de versions ou aux objets internes. Suivez leur évolution au fil du temps, puis déterminez quelles sessions consomment TempDB et combien.
Il existe sur le marché d'excellents outils de surveillance des performances SQL Server abordables et riches en fonctionnalités qui peuvent vous aider à faire face aux problèmes de dégradation des performances. Faites de vous le MVP DBA de l'entreprise en recherchant de manière proactive des solutions qui maintiennent à la fois les opérations orientées vers l'intérieur et les services commerciaux orientés vers l'extérieur à des performances optimales.
