Comment optimiser les performances SQL Server lorsque vous ne pouvez pas modifier le code

Les applications d’entreprise et orientées client, telles que les ERP, les CRM et autres plateformes préconfigurées, ralentissent rarement en raison de bogues dans leur propre code. Le plus souvent, les problèmes de performance proviennent de plus profondément dans le système, où SQL Server est confronté à des goulots d’étranglement cachés tels que les conflits TempDB, les statistiques obsolètes ou les plans d’exécution malveillants déclenchés après un correctif. Lorsque vous avez accès au code, vous pouvez réécrire les requêtes ou ajuster la logique, mais de nombreuses organisations s’appuient sur des progiciels scellés tels qu’Epicor, Microsoft Dynamics ou Acumatica, où le code est totalement inaccessible. Ceux-ci sont souvent considérés comme des « boîtes noires », les équipes informatiques estimant qu’elles ne peuvent pas intervenir. En réalité, vous pouvez toujours optimiser les performances de SQL Server en travaillant au niveau de la couche de base de données, sans intervention du fournisseur ni modification du code.

Pourquoi SQL Server mérite votre attention lorsque vous souhaitez optimiser les performances de SQL Server

Les ERP et CRM modernes offrent une grande flexibilité de configuration, des formulaires personnalisés aux intégrations basées sur des API. Mais chaque action de l’utilisateur exécute en fin de compte des instructions de base de données. Lorsque le niveau de la base de données rencontre des difficultés, l’ensemble de l’application ralentit. C’est pourquoi vous devez placer SQL Server au premier plan.

Vous contrôlez le système. Même si le code du fournisseur est inaccessible, vous maîtrisez sp_configure, la maintenance des index, les mises à jour statistiques et les paramètres de ressources. Une seule modification profite à tous. Les services financiers, la chaîne logistique, le service client et les ventes partagent tous le même moteur de bases de données. De sorte qu’une seule modification profite à l’ensemble de l’entreprise. La visibilité est intégrée. Le magasin de requêtes, les statistiques d’attente et les événements étendus vous indiquent exactement où le temps est passé. Et ce, sans licence supplémentaire ni profileur tiers.

Au cours des dernières années, les administrateurs de bases de données ont corrigé les mauvais plans à l’aide de guides de plans fragiles, de plans XML ou d’astuces liées à du texte T-SQL précis que toute modification du code pouvait compromettre. Query Store renverse la tendance en capturant chaque plan avec des métriques d’exécution en vous permettant d’imposer des plans connus pour être efficaces ou d’injecter des astuces en toute sécurité. Le tout, sans toucher à une seule ligne de code de l’application.

Utilisation de Query Store pour optimiser sans modifier le code de l’application

Avant SQL Server 2016, les guides de planification étaient notre seul moyen de remplacer les mauvais plans dans le code d’application scellé. Ils fonctionnaient, mais le moindre changement rompait la correspondance. De plus, il n’y avait aucune télémétrie sur le moment où ils se déclenchaient ou échouaient. Le Query Store a changé la donne.

Il capture chaque plan d’exécution ainsi que les métriques d’exécution afin que vous puissiez les comparer côte à côte. Vous pouvez forcer un plan connu pour être efficace et laisser SQL Server revenir automatiquement en arrière si ce plan échoue. Dans SQL Server 2022, les astuces de Query Store vous permettent d’injecter des astuces d’index ou MAXDOP dans du code tierce partie, sans aucun guide de planification ni modification du code.

Les guides de plan servent toujours dans des cas particuliers (bases de données système, TempDB). Mais pour le réglage quotidien, le Query Store est désormais la méthode fiable et transparente, 100 % sans code. Si votre objectif est d’optimiser les performances de SQL Server à tous les niveaux, c’est l’un des points de départ les plus sûrs et les plus efficaces.

Trois goulots d’étranglement SQL Server à résoudre lors de l’optimisation des performances

Les conflits TempDB sont l’un des problèmes les plus courants. Les routines de publication lourdes, les BAQ complexes ou les importations massives passent toutes par TempDB. Sans fichiers de données multiples, sans pré-dimensionnement et métadonnées optimisées pour la mémoire (SQL Server 2019+), les zones sensibles du bitmap d’allocation limitent les CPU à 20 %.

Les statistiques biaisées sont un autre tueur silencieux. Les tables de dimensions ou de transactions peuvent augmenter considérablement du jour au lendemain, tandis que les statistiques restent à la traîne. L’optimiseur fait alors de mauvaises suppositions, choisissant des jointures de hachage et débordant de mémoire. L’exécution nocturne de ( UPDATE STATISTICS WITH FULLSCAN ) sur vos dix plus grandes tables reste la solution la moins coûteuse pour optimiser de manière fiable les performances de SQL Server.

Enfin, les régressions de plan après un correctif ou un changement de version peuvent nuire aux performances. Une mise à jour cumulative ou une augmentation du niveau de compatibilité peut modifier l’estimateur de cardinalité et transformer un travail un travail par lots unique en tâche de fond Avec Query Store en mode capture, vous repérerez les alertes de régression de plan. Vous forcerez à nouveau le bon plan précédent à l’aide de ( sp_query_store_force_plan ), le tout sans modifier le code de l’application.

Check-list pour les responsables informatiques qui souhaitent optimiser les performances de SQL Server

Lorsque quelqu’un dit « le système est lent », vous pouvez souvent en découvrir la cause en moins de 15 minutes en posant les questions suivantes :

• Le CPU est-il anormalement élevé ou inactif ? Un CPU inactif avec des utilisateurs frustrés signifie souvent des blocages ou des attentes d’E/S.
• Quel type d’attente est le plus fréquent ( sys.dm_os_wait_stats ) ? WRITELOG ou PAGEIOLATCH indiquent un problème de stockage ; CXPACKET signale souvent un parallélisme mal réglé.
• Le Query Store est-il activé en mode READ_WRITE ? Sans cela, vous avancez à l’aveuglette.
• À quand remonte la dernière reconstruction des index sur les tables de plus de 1 Go ?
• Quelle est la taille actuelle de TempDB et combien de fichiers de données utilise-t-il ?

Répondre à ces questions ne permettra pas seulement d’améliorer la visibilité. Cela vous aidera également à optimiser les performances de SQL Server sans aucune intervention au niveau du code.

Preuve concrète que vous pouvez optimiser sans modifier le code

Le déploiement d’Epicor était perturbé par des pauses sporadiques de 20 secondes avec un « écran blanc ». Et ce, chaque fois que les responsables d’entrepôt exécutaient une requête BAQ principale. Le réseau et le processeur semblaient fonctionner normalement, nous avons donc activé Query Store et capturé une session Extended Events. Les données ont révélé que le BAQ basculait entre des plans de boucle imbriquée et de jointure de hachage en fonction du reniflage de paramètres. En imposant le plan optimal via une astuce Query Store, sans aucune modification de l’application, nous avons immédiatement stabilisé l’exécution. Les temps de réponse sont passés de 20 secondes à moins d’une seconde, et les plaintes des utilisateurs ont disparu du jour au lendemain.

Principaux domaines à examiner lors de l’optimisation des performances de SQL Server

Pour vous assurer que votre instance SQL Server est optimisée pour la performance, même si le code de l’application est verrouillé, commencez ici :

• Vérifiez que Query Store est activé et dimensionné de manière appropriée pour vos modèles de charge de travail.
• Vérifiez les paramètres MAXDOP et COST_THRESHOLD_FOR_PARALLELISM en fonction de votre CPU et de votre type de charge de travail.
• Inspectez la disposition de TempDB pour la distribution des fichiers et l’allocation du stockage.
• Surveillez la fragmentation des index et assurez-vous que les statistiques sont régulièrement actualisées.
• Analysez les requêtes les plus gourmandes dans le magasin de requêtes. Déterminez s’il faut forcer un plan connu pour être efficace ou créer des index de support.

Optimiser les performances SQL Server dans le nuage : mêmes principes, nouvel environnement

La migration vers Azure SQL Managed Instance ou AWS RDS modifie les responsabilités. Mais elle n’élimine pas pour autant le besoin d’optimiser les performances. Les plateformes d’infonuagique automatisent les correctifs et les sauvegardes. Toutefois, elles ne gèrent pas la précision des statistiques, les régressions de planification ou la croissance de TempDB. Les mêmes bonnes pratiques s’appliquent. Transférez votre routine d’hygiène du site vers le nuage, à l’aide d’une automatisation native ou de guides d’exécution. Vous pouvez toujours optimiser les performances de SQL Server à l’aide d’un nouvel ensemble d’outils.

Pourquoi un diagnostic de bases de données est le moyen le plus rapide d’optimiser les performances de SQL Server

Toutes les équipes n’ont pas le temps ou l’expertise interne nécessaires pour optimiser leurs performances en profondeur. Les audits de sécurité, les déploiements SaaS et les projets pilotes d’IA ont souvent la priorité. C’est là qu’intervient le diagnostic de bases de données. Il évalue votre environnement actuel. Il met en évidence les inefficacités cachées et identifie les mesures les plus efficaces pour améliorer les performances de SQL Server sans toucher à une seule ligne de code d’application. Chez Nova DBA, nous avons permis à des clients de tous les secteurs d’activité d’obtenir des résultats rapides. Et cela, simplement en commençant par la couche de base de données.

Conclusion finale : l’optimisation des performances de SQL Server est souvent la seule solution dont vous avez besoin.

Les problèmes de performances dans les applications d’entreprise provoquent rarement des pannes du système du jour au lendemain. Ils s’installent progressivement, jusqu’à ce qu’un rapport de deux heures devienne la nouvelle norme. Heureusement, la plupart de ces ralentissements proviennent de SQL Server. Ils peuvent être résolus à l’aide de quelques ajustements ciblés, sans modification du code. L’optimisation de TempDB, l’actualisation des statistiques et le verrouillage de plans stables avec Query Store peuvent permettre de regagner des heures de productivité sans avoir à faire appel au fournisseur. La prochaine fois que les demandes d’assistance s’accumulent, commencez votre triage là où cela compte le plus : au niveau de la couche de base de données. Vous y trouverez peut-être la solution, et les félicitations qui vont avec.

Vous ne savez pas par où commencer ? Contactez-nous pour commencer par un bilan de santé de votre base de données réalisé par Nova DBA. Et obtenir des informations exploitables pour optimiser les performances de SQL Server sans toucher à votre code.

Foire aux questions (FAQ)

Comment optimiser les performances de SQL Server sans modifier le code de l’application ?
En ajustant des éléments tels que TempDB, en mettant à jour les statistiques, en gérant les index et en utilisant Query Store pour stabiliser les plans d’exécution, vous pouvez améliorer considérablement les performances sans modifier la logique de l’application.

Le Query Store est-il disponible dans toutes les versions de SQL Server ?
Le Query Store a été introduit dans SQL Server 2016. Depuis lors, il a été amélioré avec des fonctionnalités telles que les Query Store Hints dans SQL Server 2022, offrant encore plus de flexibilité pour le contrôle des performances.

Ces techniques d’optimisation peuvent-elles être utilisées dans le nuage ?
Oui. Que vous utilisiez Azure SQL ou AWS RDS, le comportement de SQL Server reste le même. Vous continuerez à bénéficier de la gestion des statistiques, de l’optimisation de TempDB et de la stabilité des plans.

Que faire si nous ne disposons pas de ressources internes pour l’optimisation SQL ?
Un contrôle de l’état de la base de données offre un moyen rapide et ciblé d’évaluer les problèmes de performances et de hiérarchiser les améliorations, sous la houlette d’experts spécialisés dans SQL Server.