Comme le savent très bien tous ceux qui gèrent des bases de données, le réglage des performances de SQL Server est une fonction essentielle pour garantir des performances optimales. Les performances dépendant de divers facteurs tels que la mémoire, la configuration, la conception des requêtes et l'utilisation des ressources, isoler la cause première de la dégradation des performances n'est pas une mince affaire.
Plutôt que d'attendre que des problèmes de performances se produisent, le réglage proactif de SQL Server garantira que vos instructions SQL s'exécutent aussi efficacement que possible en aidant SQL à trouver l'itinéraire d'entrée et de sortie le plus rapide pour fournir les résultats de votre requête.
Si vous êtes aux prises avec des performances lentes ou si vous n'êtes pas du genre à attendre que des problèmes surviennent, voici trois domaines clés sur lesquels concentrer votre réglage des performances de SQL Server pour obtenir des performances optimales et des systèmes plus sains.
Conseil n°1 :Optimisez votre TempDB
TempDB mal configuré est un coupable courant lorsqu'il s'agit de dégradation des performances. Si vous remplissez fréquemment votre TempDB, il est temps de jeter un œil à ce qui doit changer.
Tout d'abord, vérifiez la taille de TempDB. Il n'y a pas de règle absolue quant à sa taille, mais une bonne règle empirique consiste à maintenir TempDB à 25 % de votre plus grande base de données ou à la même taille que votre plus grand index. Cela évite d'avoir à augmenter TempDB lors des reconstructions.
Avec TempDB, plus le lecteur est rapide, mieux c'est. Lorsque TempDB est placé sur un lecteur lent ou sur le même lecteur que le système d'exploitation, vous êtes sûr de voir des problèmes de performances de base de données. Si possible, conservez TempDB sur un SSD local dédié. Si ce n'est pas possible, votre meilleure option consiste à le conserver sur son propre volume dédié avec suffisamment d'espace disque pré-alloué.
Il est également important de séparer les données et les fichiers journaux et de définir une grande valeur fixe pour la croissance automatique de TempDB. Sinon, vous subirez une surcharge inutile à chaque fois que TempDB se remplira.
Le contrôle du nombre de fichiers de données TempDB contribue à l'optimisation de TempDB. Mais la grande question est de savoir de combien de fichiers de données TempDB avez-vous besoin ? Idéalement, vous aurez un fichier de données TempDB pour chaque CPU logique, mais pas plus de huit au total (à quelques exceptions près). Par exemple, si vous avez quatre processeurs logiques, vous avez besoin de quatre fichiers de données TempDB. Si vous avez 12 CPU logiques, vous pouvez avoir huit fichiers de données TempDB.
Conseil n° 2 :Prévenez les goulots d'étranglement des performances
Il existe trois principaux types de goulots d'étranglement des performances de SQL Server qui contribuent à de mauvaises performances :le processeur, la mémoire et les E/S. Les causes, les symptômes et les diagnostics diffèrent selon le type de goulot d'étranglement. Voici donc un guide rapide des éléments à surveiller :
Goulets d'étranglement du processeur
Cause : Ressources matérielles insuffisantes
Symptômes : Utilisation constante du processeur
Métriques à surveiller : % de temps processeur, Requêtes par lot/s, Compilations SQL/s et Recompilations SQL/s
Goulets d'étranglement de la mémoire
Cause : Limitations de la mémoire disponible et pression sur la mémoire causées par SQL Server, le système ou d'autres activités d'application
Symptômes : Réactivité lente des applications, ralentissement général du système et plantages des applications
Métriques à surveiller : Mémoire disponible (Ko), mémoire totale du serveur (Ko), mémoire du serveur cible (Ko), pages/s, pages de point de contrôle/s, écritures différées/s et taux d'accès au cache de la mémoire tampon
Goulots d'étranglement d'E/S
Cause : Lecture et écriture excessives de pages de base de données depuis et sur le disque
Symptômes : Temps de réponse longs, ralentissements des applications et délais d'attente des tâches
Métriques à surveiller : Longueur moyenne de la file d'attente du disque, Moyenne des secondes de disque/lecture, Moyenne des secondes de disque/écriture, % de temps de disque, Moyenne des lectures de disque/seconde et Moyenne des écritures de disque/seconde
Conseil n° 3 :Assurez-vous que les index sont correctement conçus
Les index sont un excellent moyen d'accélérer certaines opérations SQL Server, mais uniquement s'ils sont bien conçus. Des index mal conçus ont l'effet inverse et sont un moyen sûr de tuer vos performances SQL Server.
La configuration correcte de ces quatre domaines peut aider à garantir que les index sont correctement conçus et à aider plutôt qu'à nuire aux performances de SQL Server.
Taille du tableau
Toutes les tables ne sont pas de bonnes candidates pour l'indexation. En fait, si une table est trop petite, il est beaucoup plus efficace pour SQL Server de rechercher dans toute la table plutôt que d'avoir à rechercher dans les index. Bien sûr, l'inverse est vrai pour les grandes tables, vous devez donc peser les frais généraux potentiels lorsque vous décidez quelles tables bénéficieraient des index.
Types d'index
Techniquement, chaque table de base de données peut avoir un index cluster et un nombre infini d'index non cluster, mais vous savez ce qu'ils disent à propos de "Juste parce que vous pouvez faire quelque chose"…
Trop d'index non clusterisés peuvent ralentir considérablement les opérations d'insertion et de mise à jour, donc s'en tenir à un index clusterisé et au nombre minimum d'index non clusterisés absolument essentiels est un bien meilleur choix de conception.
Stockage d'index
Au cours de la phase de conception, la sélection des critères de stockage appropriés pour les index est cruciale pour les performances d'E/S. Les index clusterisés partitionnés et les index non clusterisés peuvent être stockés sur le même groupe de fichiers que la table principale, ou ils peuvent être stockés sur un groupe de fichiers différent. Le stockage d'un index non clusterisé dans un groupe de fichiers situé sur un autre lecteur de disque peut améliorer les performances des requêtes qui l'utilisent, car il n'est pas affecté par la lecture simultanée des données et des pages d'index SQL se produisant sur différents lecteurs de disque.
FACTEUR DE REMPLISSAGE
FILLFACTOR spécifie le pourcentage d'espace qui sera rempli sur chaque page de données lors de la création d'un index. Les valeurs FILLFACTOR peuvent aller de 0 % (aucune page de données n'est remplie) à 100 % (la page de données est entièrement remplie). Lors de la conception de votre index, sélectionnez une valeur FILLFACTOR qui optimisera l'utilisation de la page tout en minimisant le risque de fragmentation excessive de l'index.
Intégrer le réglage des performances de SQL Server à votre routine standard est un excellent moyen de vous assurer que vos bases de données fonctionnent à des performances optimales. L'intégration de ces trois étapes simples dans vos plans de maintenance réguliers de SQL Server améliorera sensiblement la vitesse et les performances de vos utilisateurs.
