Pourquoi auditer vos serveurs SQL Server ?
La plupart des instances SQL Server sont installées avec les réglages par défaut, puis ne sont plus jamais revues. Les bases grossissent, les applications évoluent, les équipes changent, et la dette technique s'accumule sans bruit jusqu'au jour où un traitement ne passe plus, où une restauration échoue ou où un auditeur pose une question gênante.
Un audit SQL Server est particulièrement utile :
- quand les utilisateurs se plaignent de lenteurs sans que personne ne sache pourquoi ;
- après le départ de votre DBA, pour savoir ce dont vous héritez ;
- avant une migration ou une montée de version, pour partir d'un état connu ;
- après un incident, pour éviter qu'il ne se reproduise ;
- avant un audit de sécurité, une certification ou une due diligence.
Ce que couvre l'audit
Configuration de l'instance
Mémoire maximale, parallélisme (MAXDOP et cost threshold for parallelism), configuration de tempdb, options des bases (auto-shrink, auto-close, page verify), niveaux de compatibilité, paramètres du système d'exploitation et du stockage. Ce sont des réglages simples, mais un seul mauvais choix peut coûter une part importante des performances.
Sauvegardes et capacité de restauration
Couverture réelle des sauvegardes complètes, différentielles et du journal au regard du mode de récupération de chaque base, perte de données maximale en cas d'incident (RPO), copies hors site, vérifications d'intégrité DBCC CHECKDB. Nous regardons ce qui se passerait vraiment si vous deviez restaurer demain.
Performances
Statistiques d'attente, requêtes les plus coûteuses en CPU, en lectures et en durée, état du Query Store, index manquants, inutilisés ou en doublon, statistiques obsolètes, blocages. L'objectif est d'identifier les quelques causes qui expliquent la majorité de la charge.
Sécurité
Membres du rôle sysadmin, état du compte sa, connexions SQL sans politique de mot de passe, fonctionnalités à risque activées (xp_cmdshell, OLE Automation), chiffrement des données et des sauvegardes, correctifs de sécurité manquants.
Cycle de vie et licences
Version et niveau de mise à jour cumulative au regard du calendrier de support Microsoft, exposition aux mises à jour de sécurité étendues (ESU), fonctionnalités Enterprise réellement utilisées et dimensionnement des cœurs. C'est souvent là que se trouvent les économies les plus rapides.
Haute disponibilité
Si vous utilisez des groupes de disponibilité Always On, du log shipping ou un cluster, nous vérifions la santé de la synchronisation, les jobs et connexions sur les réplicas secondaires, et la cohérence avec vos objectifs de reprise. Voir aussi la page haute disponibilité et PRA.
Comment se déroule l'audit
- Appel de cadrage gratuit (30 min). Contexte, symptômes, périmètre, contraintes d'accès. Vous recevez ensuite une proposition au forfait.
- Collecte. Un script T-SQL (Transact-SQL) en lecture seule, exécuté par vous ou par nous. Il ne lit que des métadonnées techniques, jamais le contenu de vos tables.
- Analyse. Notre moteur de diagnostic AutoDBA passe les résultats au crible de ses 41 règles, puis un DBA senior vérifie, contextualise et complète chaque constat à la main.
- Restitution. Une heure en visio avec vos équipes pour parcourir le rapport, répondre aux questions et valider les priorités.
Ce que vous recevez
- une synthèse d'une page pour la direction, avec un score de santé par instance ;
- des constats classés par gravité, chacun expliqué en français clair ;
- les scripts T-SQL de correction, commentés et prêts à relire ;
- une feuille de route sur 30, 60 et 90 jours ;
- les éléments de preuve (requêtes, mesures) pour que vos équipes puissent vérifier chaque point.
Et après l'audit ?
Vous restez libres. Certaines équipes appliquent les recommandations elles-mêmes à partir des scripts fournis. D'autres nous confient la mise en œuvre, ou une mission d'optimisation des performances. Et quand il n'y a pas de DBA en interne, l'audit sert de point de départ à un accompagnement de DBA externalisé.
