Ressources · SQL Server

SQL Server — diagnostic, performance et restauration

Comment nous abordons une base SQL Server qui ralentit, qui bloque, ou dont la sauvegarde n’a jamais été testée.

Mesurer avant d’optimiser

« La base est lente » n’est pas un diagnostic. Avant de toucher un index, il faut établir ce qui est lent, pour qui, depuis quand, et sous quelle charge. Un traitement qui passe de 4 à 40 minutes en fin de mois n’a pas la même cause qu’une application dont chaque écran met deux secondes à s’afficher. La première question n’est jamais « quelle requête optimiser » mais « qu’est-ce que le serveur attend ».

Statistiques d’attente cumulées et par session, pour orienter la recherche vers le CPU, les E/S, la mémoire ou les verrous
Query Store lorsqu’il est activé : régression de plan, requêtes les plus coûteuses, historique avant/après
Vues de gestion dynamique pour les requêtes en cours, les demandes de mémoire et la latence des fichiers
Compteurs système : PLE, batch requests/sec, latence disque par fichier de données et de journal

Blocage, verrou, interblocage — trois problèmes différents

Un blocage est une session qui attend une ressource détenue par une autre : le système fonctionne comme prévu, mais une transaction dure trop longtemps. Un interblocage est une impasse que le moteur tranche en sacrifiant une session. Une escalade de verrous transforme des milliers de verrous de ligne en un verrou de table et bloque tout le monde. Les remèdes sont opposés, ce qui rend l’identification préalable indispensable.

Chaîne de blocage : identifier la session en tête, pas celles qui subissent
Durée des transactions applicatives, souvent la vraie cause
Niveau d’isolation utilisé, et pertinence de READ COMMITTED SNAPSHOT selon le contexte
Sessions ouvertes puis abandonnées par le client, qui conservent leurs verrous

Index et plans d’exécution

Les index manquants signalés par le moteur sont des suggestions, pas des recommandations : appliqués tels quels, ils produisent des tables sur-indexées où chaque écriture coûte plus cher que la lecture gagnée. Un plan d’exécution se lit en cherchant l’écart entre lignes estimées et lignes réelles ; c’est là que se trouvent les statistiques périmées, les conversions implicites et les prédicats non SARGables qui interdisent la recherche d’index.

Consolider les index redondants plutôt que d’en ajouter
Vérifier la fraîcheur des statistiques avant de conclure à un problème d’index
Traquer les conversions implicites entre types de colonnes et paramètres
Distinguer un plan mal choisi (parameter sniffing) d’un plan structurellement mauvais

Sauvegarde, restauration et journal des transactions

Une sauvegarde n’a de valeur qu’une fois restaurée. En mode de récupération complète, l’absence de sauvegarde du journal fait croître le fichier de journal jusqu’à saturation du disque — un incident de production courant, dont la réponse n’est pas de réduire le fichier mais de sauvegarder le journal et de corriger le plan de maintenance. Le point à vérifier est le délai réel de remise en service, pas la présence de fichiers de sauvegarde.