1 : Redémarrer le serveur… sans avoir identifier la cause
C’est la première chose que bien des équipes essaient. « On va redémarrer SQL Server, ça va repartir. » Parfois, ça marche… temporairement. Et c’est bien là le problème.
Pourquoi c’est une erreur
Le redémarrage fait disparaître les symptômes sans régler le problème. Vous perdez le contenu du cache, les plans compilés et les traces utiles à l’analyse. C’est comme redémarrer une voiture qui fait un bruit étrange… sans ouvrir le capot.
Ce qu’il faut faire
Avant de redémarrer, prenez le temps de capturer l’état du serveur : requêtes actives, blocages, temps de réponse. SQL Server offre plusieurs outils simples pour ça (Activity Monitor, DMVs, Query Store, Extended Events…). Avec les bonnes infos, on peut poser un vrai diagnostic de l’état du serveur, pas juste espérer que le redémarrage règle tout par miracle.
2 : Cibler le code source… sans preuve
Autre classique : « C’est sûrement la requête de Marc qui fait tout planter. » Et voilà que le développeur doit passer des heures à revoir un code qui n’a peut-être rien à se reprocher.
Pourquoi c’est une erreur
Sans métrique, on accuse au hasard. Le problème peut venir d’un changement de données, d’un plan d’exécution modifié ou d’un manque d’index… et non du code lui-même. Sans données précises, toute optimisation est aveugle.
Ce qu’il faut faire
Commencez par identifier quelle requête cause la lenteur, grâce à des outils comme sys.dm_exec_query_stats, Query Store, ou les plans d’exécution récents. Une fois le problème ciblé, le développeur saura où mettre ses efforts et vous gagnerez du temps des deux côtés.
3 : Ajouter un index… juste pour essayer !
C’est tentant : « Et si on mettait un index ici… juste pour voir ? »
Mais attention : un index mal placé ou inutile peut dégrader les performances ailleurs.
Pourquoi c’est une erreur
Un index de plus, c’est aussi plus de données à maintenir lors des insertions ou des mises à jour. Et plus il y en a, plus l’optimiseur peut se tromper. En accumulant les index « test », on crée des conflits silencieux.
Ce qu’il faut faire
Analysez le plan d’exécution pour identifier la table problématique et l’opération coûteuse. Si un index s’impose, il doit cibler une requête précise et, idéalement, couvrir les bonnes colonnes. Mieux vaut apprendre à lire un plan d’exécution de base que d’empiler les index au hasard. Vous gagnerez du temps… et des performances.
4 : Accuser à tort les tâches planifiées
Un traitement planifié ralentit l’application ? « C’est sûrement la job de nettoyage de 2h du matin. » Et voilà qu’on annule un processus critique… sans certitude.
Pourquoi c’est une erreur
Certaines jobs sont là pour une bonne raison : mettre à jour les statistiques, nettoyer des historiques, réindexer. Couper ces tâches peut aggraver la situation sur le long terme.
Ce qu’il faut faire
Vérifiez l’horaire exact des jobs, leur durée, et leur impact réel sur les ressources (CPU, I/O, verrous). Parfois, il suffit de replanifier intelligemment, ou de réduire la charge (ex : échantillonnage des stats au lieu de full scan). Ne tirez pas sur le messager !
5 : Attendre que ça passe…
C’est l’erreur la plus silencieuse. Personne n’agit, on s’adapte, on patiente... et au fil du temps, les lenteurs deviennent la norme.
Pourquoi c’est une erreur
La dégradation est progressive, donc insidieuse, mais les coûts sont bien réels : perte de productivité, frustration des équipes, baisse de la confiance envers les TI. Une lente dégradation nuit à la productivité et à la stabilité.
Ce qu’il faut faire
Agir dès les premiers signaux. Avoir un minimum de monitoring (temps de réponse, requêtes lentes, croissance des index, taille des fichiers TempDB…). Même sans budget ni outils sophistiqués, quelques scripts bien placés peuvent faire une énorme différence.
Le vrai problème c’est le flou.
Ce qui nuit le plus à la performance… c’est de ne pas savoir d’où vient la lenteur. Quand tout devient lent, ce n’est pas toujours SQL, ce n’est pas toujours l’application, et ce n’est jamais une bonne idée d’essayer de deviner. La bonne nouvelle : il existe une approche simple et structurée pour poser le bon diagnostic, même sans être un expert avec 20 ans d’expérience. Approcher le problème avec structure, capter les bonnes mesures et utiliser les bons outils : voilà ce qui fait vraiment la différence.
D’ailleurs, j’aborderai ce sujet en détails dans le webinaire à venir « SQL Server ou l’application : le vrai coupable de la performance ».
Besoin d’aller au-delà des bases et d’explorer les vraies optimisations ?
