Audit SQL Server à distance

Rudi Bruchez, trente ans d’expérience SQL Server, Microsoft MVP SQL Server puis Data Platform pendant huit années consécutives de 2018 à 2025. Plus de cent environnements audités ou administrés. Compte-rendu disponible en français ou en anglais.

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 : 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.

Ce que vous recevez

• Un compte-rendu PDF qui relie chaque mesure à sa conséquence et à une préconisation.
• Un fichier .sql avec les commandes citées, prêt à être relu par votre DBA.
• Trois à cinq actions à mener en premier, classées selon votre contexte.
• Une restitution d’une heure en visioconférence pour parcourir les constats et répondre aux questions.

Vous pouvez lire un exemple de compte-rendu réel et anonymisé avant de commander.

Quand cet audit est utile

• Les performances se dégradent, mais les mesures disponibles ne désignent pas une cause claire.
• Vous envisagez un achat de processeurs, de mémoire ou de stockage.
• Vous préparez une migration, une montée de version ou une mise en production.
• Vous avez un doute sur les sauvegardes, les restaurations ou le plan de reprise.
• Votre équipe reçoit des recommandations contradictoires et doit fixer un ordre d’action.
• Votre politique de sécurité interdit de donner un accès distant à la production.

Quand choisir une autre intervention

Cet audit ne remplace pas une intervention d’urgence sur un serveur arrêté. Il n’inclut pas non plus quatre heures de correction en direct ni une revue exhaustive du code applicatif. Il sert à documenter l’état de l’instance et à décider quels travaux lancer ensuite.

Trois décisions tirées d’audits réels

Les noms de clients, serveurs, bases et applications ont été retirés. Les mesures utiles au raisonnement sont conservées.

Sauvegardes et objectif de reprise

Deux instances effectuaient une sauvegarde complète et une sauvegarde du journal par jour, sur le même volume que les données. Les travaux réussissaient, mais la perte possible restait de vingt-quatre heures. La perte du volume pouvait aussi emporter les sauvegardes avec les bases.

La recommandation portait d’abord sur un stockage distinct et des sauvegardes de journal plus fréquentes. Réduire les journaux sans corriger cette organisation n’aurait traité que la conséquence.

Latence de tempdb

Les écritures des quatre fichiers de données de tempdb prenaient entre 1,69 et 1,86 seconde. Les lectures restaient à 1,5 ms et le journal, placé sur un autre volume, écrivait à 3,5 ms. Les mesures désignaient le chemin d’écriture du volume qui portait les fichiers de données.

La recommandation pouvait donc être transmise à l’équipe stockage avec un périmètre précis, sans demander le remplacement de toute l’infrastructure.

Cache de plans

Une instance conservait 2,85 Go de plans à usage unique. L’activation de optimize for ad hoc workloads semblait adaptée, mais elle n’aurait concerné qu’environ 90 Mo. Les 2,76 Go restants venaient de plans Prepared, produits sous des milliers de formes par le pilote applicatif.

La correction devait porter sur la génération et la réutilisation des requêtes côté application. Le réglage SQL Server pouvait rester utile, mais il ne répondait pas au volume observé.

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. Vous commandez l’audit avec le formulaire de commande : version, nombre d’instances, ce qui est intouchable chez vous. Je confirme le périmètre et je vous envoie la facture. Si vous préférez vérifier d’abord que l’audit répond à votre question, un échange de trente minutes est possible avant la commande. 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 est conçu pour être exécuté sur une instance de production ;
• neuf collecteurs portant sur des informations plus sensibles sont désactivés par défaut. Ils comprennent le texte des requêtes en cours, les plans du Query Store, les définitions d’objets et les graphes de verrous mortels. Une option explicite est nécessaire pour les activer.

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.

La base de connaissances garantit que chaque thème prévu est examiné. J’écris le compte-rendu et je classe les priorités après lecture des mesures et des réponses apportées pendant l’analyse.

Le compte-rendu en détail

Le compte-rendu publié en exemple est un document réel rendu anonyme. Ses mesures, ses constats et ses questions sont ceux du document remis 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.

Contrôles avant livraison

Un contrôle vérifie la cohérence de la rédaction avec les comptes-rendus de référence. Un second confronte les affirmations aux valeurs de l’archive. Par exemple, un rapport ne peut pas déclarer conforme un MAXDOP supérieur à 4 ou un cost threshold for parallelism inférieur à 80. Une affirmation que la collecte ne permet pas de soutenir est retirée ou transformée en question.

Ce que l’audit ne comprend pas

• 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 en 2008 et 2009, puis pendant huit années consécutives de 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.

Commander

Vous pouvez commander l’audit directement, sans rendez-vous préalable. Si vous préférez vérifier qu’il correspond bien à votre situation, un échange de trente minutes est proposé avant la commande. Cet échange reste facultatif.

rudi@pachadata.com · Me contacter · LinkedIn