Audit SQL Server à distance

Avant tout le reste

Aucun agent, aucun accès distant, aucun compte à me créer

Je ne me connecte jamais à vos serveurs. Vous exécutez un programme, vous obtenez une archive, vous me l’envoyez. Rien ne reste installé, rien ne tourne en continu, et il n’y a rien à désinstaller après.

Vos données de diagnostic ne sont hébergées nulle part

Elles vont de votre serveur à votre archive, et de votre archive à moi. Il n’y a pas de plateforme, pas de compte en ligne, pas de base chez un prestataire qui accumulerait la description de votre infrastructure et qu’il faudrait défendre indéfiniment.

Le collecteur est un logiciel libre

[github.com/rudi-bruchez/sql-auditor](https://github.com/rudi-bruchez/sql- auditor) : code lisible, requêtes en clair dans des fichiers .sql, licence libre. Votre équipe peut le relire avant de l’exécuter, le compiler elle-même, et vérifier exactement ce qu’il lit.

Le problème, tel qu’il se présente presque toujours

Une application est développée sur un serveur où seuls les développeurs se connectent, avec un jeu de données limité. Les tests passent, la démonstration est bonne, la mise en production se fait sans test de charge. Au début tout va bien. Puis les performances se dégradent à mesure que la volumétrie et la concurrence augmentent, et deviennent critiques au pire moment : les périodes de forte activité.

On cherche alors des solutions. On ajoute de la mémoire, on répartit les fichiers, on ajoute des processeurs, sans savoir d’où vient le problème et sans pouvoir prédire si cela va le résoudre. Les gains sont réels mais décevants, et la situation revient.

Après vingt ans d’audits :

• la plupart du temps, le problème n’est pas matériel. Il vient de l’usage : le code, la configuration, l’indexation, le modèle de données ;
• SQL Server contient déjà tout ce qu’il faut pour établir un diagnostic précis, rapidement, quand on sait où chercher ;
• peu de gens savent où chercher.

Un moteur relationnel ne s’optimise pas en lui dédiant une machine plus puissante. La vraie optimisation passe par les structures, le code et l’indexation.

Trois audits récents, avec leurs mesures, sont résumés sur la page cas d’étude.

L’audit qu’on ne fait jamais

Tout le monde sait qu’il faudrait le faire. Peu d’entreprises le font, et la raison est toujours la même : il faut faire venir quelqu’un, lui ouvrir des accès, lui laisser deux ou trois jours, et l’essentiel de ce temps part dans la partie la moins intéressante du travail. Ouvrir SSMS, lancer une requête, copier le résultat, recommencer quatre-vingts fois.

Cette partie-là est mécanique, donc automatisable, et c’est ce que j’ai fait. L’interprétation et les préconisations, elles, continuent de se faire à la main.

Comment ça se passe

1. Un premier échange, gratuit, trente minutes. Ce que vous constatez, sur quelle version, combien d’instances, ce qui est intouchable chez vous. C’est aussi là qu’on vérifie que l’audit répond à votre question. S’il n’y répond pas, je vous le dis.
2. Vous collectez. Je vous indique la version à télécharger : un exécutable unique, sans installation ni dépendance, avec le guide destiné à votre DBA. Vous le lancez vous-même, sur votre poste ou sur le serveur. La collecte dure quelques minutes et produit une archive .zip.
3. Vous m’envoyez l’archive, par le moyen que vous préférez. Rien ne sort de chez vous automatiquement : le collecteur écrit un fichier, et vous décidez de ce que vous en faites.
4. Je rends le compte-rendu sous cinq jours ouvrés à compter de la réception de l’archive, puis nous fixons la restitution.

Ce que le collecteur fait, et ce qu’il ne fait pas

C’est la question que pose tout DBA sérieux, et elle est légitime : on ne lance pas un binaire inconnu sur une instance de production.

• il n’émet que des SELECT sur les vues système et les vues de gestion dynamique (sys.configurations, sys.dm_os_wait_stats, sys.databases et leurs voisines) ;
• il ne lit pas le contenu de vos tables métier ;
• il n’écrit rien dans vos bases ;
• il ne modifie aucune configuration ;
• il s’exécute en lecture non bloquante, sans poser de verrous sur votre production ;
• neuf collecteurs plus indiscrets, le texte des requêtes en cours, les plans d’exécution du Query Store, la définition des objets, les graphes de verrous mortels, sont désactivés par défaut et ne s’activent qu’avec une option explicite.

Lecture seule ne veut pas dire gratuit. Un des collecteurs échantillonne les pages des plus grands heaps de chaque base pour compter les enregistrements transférés. Sur une très grosse instance, c’est de l’entrée-sortie réelle. La documentation dit ce que ça coûte et comment l’éviter.

Le collecteur ne juge pas. Il n’y a ni seuil, ni score, ni recommandation nulle part dans son code. Il ramasse les faits, il dit ce qu’il n’a pas pu ramasser et pourquoi, et il s’arrête là. Un outil qui vous rend 68 sur 100 ne dit pas comment il a calculé ce nombre, ni ce qu’il a décidé d’ignorer pour l’obtenir.

Vous pouvez le vérifier avant de l’autoriser

Vous pouvez lire le code, le compiler vous-même, ou, plus simple, lui demander d’écrire sur disque les requêtes qu’il embarque et les faire relire par votre DBA :

sql-auditor queries export --to .\requetes

Ce sont des fichiers .sql en clair. Il n’y a rien d’autre.

Avant la collecte, une commande de vérification dit exactement ce qui sera exécuté et quelle permission manque, avec la conséquence de chaque refus :

sql-auditor check

Si un droit manque, l’outil écrit le GRANT correspondant dans un fichier. Il ne l’exécute pas : c’est votre DBA qui le lit et qui décide. Et si vous refusez un droit ou une catégorie, le refus est consigné dans le compte-rendu plutôt que masqué. Vous savez exactement ce qui a été vu et ce qui ne l’a pas été.

Ce qui est regardé

Plus de quatre-vingts collecteurs, répartis en huit domaines, filtrés selon la version de votre instance.

L’archive contient aussi un manifeste qui dit ce qui a tourné, ce qui a été sauté, et pourquoi. Vous savez donc ce qui n’a pas été vu.

Ce qui se passe ensuite, et pourquoi ce n’est pas automatique

L’analyse s’appuie sur une base de connaissances que j’entretiens : 338 sujets répartis en 13 thèmes, distillés de quarante-six audits réels. Chaque sujet décrit un problème, pourquoi il compte, comment le détecter, quoi recommander, comment corriger, et, section qui manque partout ailleurs, quand ne pas le signaler.

Le chiffre intéressant est celui-ci : sur ces 338 sujets, 165 ne sont pas détectables par une requête. Un plan de sauvegarde qui supprime la sauvegarde précédente avant que la nouvelle ait réussi, des sauvegardes jamais testées en restauration, une base d’archive qui aurait dû passer en READ_ONLY, un runbook de reprise qui n’existe pas : rien de tout cela ne se lit dans une vue de gestion dynamique. Ça se voit en regardant, et ça se demande.

La moitié de ce qui compte n’est donc pas dans la collecte, et c’est la limite de l’audit automatique. L’outil fait gagner les jours passés à ramasser les faits. Il ne remplace pas l’expertise qui les lit.

De la même façon, les plans d’exécution présents dans l’archive viennent du Query Store : ils disent ce que l’optimiseur a décidé, pas où le temps est passé. Pour les quelques procédures qui pèsent vraiment, je demande un plan réel, post-exécution, et je le demande pendant l’analyse, en nommant les procédures, pas à la livraison.

C’est aussi ce qui explique le prix. Le corpus est le mien, et la machine l’applique intégralement à chaque serveur, sans en oublier un point. Vous achetez cette exhaustivité, et le jugement qui vient après.

Ce que vous recevez

Un compte-rendu d’audit, en PDF, en français ou en anglais, accompagné d’un fichier .sql qui rassemble les commandes citées, prêtes à être relues et exécutées. Ils sont à vous.

Vous pouvez lire un exemple de compte rendu avant de commander : c’est un document réel, rendu anonyme, avec ses mesures, ses constats et les questions qu’il pose au client.

Vous pouvez lire un exemple de compte rendu avant de commander : c’est un document réel, rendu anonyme, avec ses mesures, ses constats et les questions qu’il pose au client.

Sa forme est fixée par le dépouillement des trente-cinq comptes-rendus réels qui servent de référence.

• Chaque constat tient en trois à cinq phrases : la valeur mesurée face à la valeur attendue, la conséquence concrète sur la machine, la préconisation, et la commande T-SQL nue.
• L’ordre suit la démarche d’audit, pas une hiérarchie de gravité : configuration du serveur, configuration des bases, attentes, requêtes, index, tailles et compression, maintenance, sécurité.
• Pas de cours sur le moteur. Si un concept demande une explication générale, il y a un lien vers l’article qui la donne. Le compte-rendu n’est pas un support de formation.
• Pas de tableau « Sévérité / Criticité / Gravité ». Des tableaux de mesures, oui : latences par fichier, configuration mémoire, requêtes les plus coûteuses. Des tableaux de consultant, non.
• Ce qui n’est pas grave est dit comme tel, en une demi-phrase, pour que ce qui l’est ressorte.
• Des questions, sur ce que la machine ne peut pas dire : la rétention souhaitée, l’intention métier derrière une table de 2 Go nommée _temp, les autres processus qui tournent sur ce serveur.

S’y ajoute ce que la chaîne ne sait pas produire.

Les premières actions, priorisées. Trois à cinq choses à faire en premier, écrites, dans l’ordre où je les ferais si c’était mon serveur. Le tri ne suit pas la gravité des constats. Il tient compte de ce que vous m’aurez dit de vos contraintes, et je motive chaque choix.

Une restitution d’une heure en visioconférence. On parcourt les constats ensemble, dans l’ordre d’impact, et je réponds aux questions.

Deux contrôles tournent avant la livraison

Le premier mesure la prose contre la ligne de base des comptes-rendus réels et refuse ce qu’un modèle de langage écrit spontanément et que je n’écris pas. Le second confronte chaque affirmation du rapport à l’archive : il refuse un rapport qui déclarerait conforme un MAXDOP supérieur à 4 ou un cost threshold for parallelism inférieur à 80. Un compte-rendu qui affirme quelque chose que la collecte ne montre pas ne part pas.

Ce que l’audit ne comprend pas

Autant le dire ici plutôt qu’après.

• La mise en œuvre des corrections. Le compte-rendu vous dit quoi faire et pourquoi, il ne le fait pas à votre place.
• Le plan de remédiation complet : chiffrage en effort de chaque correction, scripts prêts à exécuter, arbitrage sur vos fenêtres de maintenance et vos échéances, collecte de contrôle après application. C’est un travail distinct.
• L’analyse du code applicatif au-delà de ce que les requêtes exécutées révèlent.
• Les instances supplémentaires, facturées à part.

Le prix

2 500 € HT pour une instance : compte-rendu, actions priorisées et restitution compris. Prix ferme, pas de facturation au temps passé, pas de dépassement.

1 000 € HT par instance supplémentaire collectée dans le même passage.

C’est délibérément peu cher pour un audit d’expertise, et la raison est simple

la collecte est outillée, et l’analyse s’appuie sur une base de constats construite à partir de vingt ans d’audits, appliquée systématiquement. Ce qui coûtait plusieurs jours de relevés manuels prend quelques minutes. Le temps que je facture est du temps de jugement.

Le règlement

Facture à la commande, réglée avant la collecte. Virement bancaire, en euros.

Pour un client hors zone SEPA, le virement se fait sur un compte local, en euros, en livres ou en dollars selon votre pays : vous payez un virement domestique, sans frais de correspondant et sans délai international. Un numéro de TVA intracommunautaire, ou son équivalent professionnel hors Union européenne, est demandé à la commande.

Et ensuite, si vous le souhaitez

Plan de remédiation. Les constats priorisés selon vos contraintes réelles, chiffrés en effort, avec les scripts de correction et une seconde collecte de contrôle après application. Vous obtenez un résultat mesurable, avec l’avant et l’après documentés.

Accompagnement et formation. Mise en œuvre avec vos équipes, et transfert de compétence pour que vos administrateurs sachent lire une collecte et refaire l’exercice seuls.

Suivi périodique. Une collecte régulière, un rapport d’écart, et un volume de jours défini par mois. Les dégradations se voient venir avant de devenir critiques.

Ces prestations sont chiffrées après l’audit, quand le périmètre est connu. Aucune n’est un préalable, et l’audit se suffit à lui-même. Parce que la collecte est reproductible, elle peut être relancée : six mois après les corrections, la même commande dit ce qui a bougé.

Qui rend le compte-rendu

Rudi Bruchez, consultant indépendant expert SQL Server. Trente ans d’expérience, vingt ans d’indépendance. Microsoft MVP SQL Server puis Data Platform, 2008-2009 puis 2018-2025.

Auteur d’Optimiser SQL Server (Dunod), des Bases de données NoSQL (Eyrolles, trois éditions), co-auteur de Pro T-SQL Programmer’s Guide (Apress) et de SQL (Pearson). Plus de 120 formations vidéo publiées chez LinkedIn Learning et Pluralsight. Formateur certifié Microsoft, 950 professionnels formés.

Plus de cent environnements SQL Server audités ou administrés, de la PME au grand compte : banque et assurance, industrie, énergie, distribution, éditeurs de logiciels, santé, secteur public.

Commencer

Le premier échange est gratuit et sans engagement. Écrivez-moi ce que vous constatez, avec la version de SQL Server et le nombre d’instances concernées.

rudi@pachadata.com · Me contacter · LinkedIn