25 To ramenés à 6 To
Une base de plusieurs téraoctets changée de disque, la production arrêtée seulement le temps de la bascule.
15 h 59 ramenées à 19 s
Le temps processeur d’une requête de règlement, après la réécriture d’une borne de dates.
10 h 31 ramenées à 1 h 46
La sauvegarde complète d’un entrepôt de données de 1,3 To.
Les clients ne sont pas nommés. Chaque résultat ci-dessous vient d’une mesure faite sur le serveur du client et consignée pendant la mission : une durée, une taille, un compteur d’attente. Les gains seulement estimés ne figurent pas ici.
Un disque de 25 To ramené à 6 To
Un groupe industriel international, édition Standard de SQL Server, en 2026. Une base de plusieurs téraoctets occupe un disque de 25 To facturé au mois par l’hébergeur. Réduire un disque managé demande une migration ; l’agrandir se fait à chaud. Il fallait donc libérer l’espace dans la base, puis la déplacer sur un disque neuf, plus petit, sans arrêter la production plus que le temps d’une bascule.
- Libérer l’espace. J’ai supprimé les index devenus inutiles, puis compressé les plus gros index en ROW ou en PAGE, choisi index par index selon leur taux d’écriture. L’édition Standard ne reprend pas une reconstruction interrompue, et le chargement de données, qui écrit toutes les cinq minutes, bloquait les plus longues. J’ai donc obtenu une fenêtre de nuit avec le chargement en pause : 17 index sont passés de 3 046,9 Go à 1 186,5 Go en une nuit. Le fichier principal est ensuite passé de 7 070 Go à 2 531 Go.
- Préparer le disque neuf sans interruption. La base a été restaurée sous un autre nom sur un disque de 6 To, pendant que la production tournait. Une sauvegarde du journal toutes les 15 minutes, restaurée aussitôt, tenait la copie à jour : 73 restaurations sur 73 sans échec.
- Basculer. Pendant une coupure convenue avec l’équipe locale, j’ai appliqué le dernier journal, puis deux renommages ont fait de la copie la base de production. Les applications se sont reconnectées par le nom, sans changement de leur côté.
- Retirer l’ancien disque, une fois l’intégrité de la nouvelle base vérifiée et les dernières petites bases déplacées.
Au passage, la sauvegarde complète est passée de 5 h 09 à 2 h 25.
Un entrepôt décisionnel limité par ses lectures disque
Un industriel international, entrepôt de données sur une machine virtuelle de 1,6 To de mémoire, en 2026. Le serveur ralentissait sans cause connue. Le processeur était à 4 % en moyenne, mais l’instance lisait environ 400 Mo par seconde en continu, et un disque d’archive répondait en 504 ms par lecture.
J’ai appliqué le soir même quatre réglages en ligne, réversibles, chacun noté avec l’effet attendu : checkpoint indirect, mise à jour asynchrone des statistiques, seuil de coût du parallélisme, optimisation des requêtes ad hoc. Sur la journée suivante :
- les attentes du serveur sont passées de 14,3 à 11,3 heures par heure, soit 21 % de moins, et les attentes de lecture disque de 2,26 à 1,53 heures par heure ;
- l’attente de mise à jour synchrone des statistiques est passée de 0,28 à 0,05 heure par heure ;
- les messages de checkpoint qui parcouraient toute la mémoire, environ un toutes les trois minutes et 16 064 en onze jours, ont disparu.
Le Query Store, activé le même soir, a ensuite montré la cause de fond : des requêtes de reporting qui relisent des tables de faits entières depuis 2012. Une vérification de partitions réécrite est passée de 12 s à 5 ms, mesurée sur un clone de la base.
Performances
| Contexte | Ce que j’ai fait | Résultat |
|---|---|---|
| Enseigne de prêt-à-porter, entrepôt de 1,3 To (2014) | Compression par partition, sauvegardes compressées, nettoyage des index, réglages mémoire et parallélisme | Sauvegarde complète de 10 h 31 à 1 h 46, base ramenée à 800 Go |
| Plateforme de réservation touristique (2019) | Index manquants, réécriture des procédures les plus appelées | Temps de réponse sous charge de 60 s à 3 s, à 50 utilisateurs |
| Intégrateur ERP, reporting financier (2021) | Curseurs remplacés par une requête ensembliste | Calcul de plus de 30 minutes ramené à 4 secondes environ |
| Prestataire informatique, santé animale (2018) | Intervention de nuit, mise à jour des statistiques remise en route | Déclaration de ventes de 20 minutes à 10 secondes |
| Mutuelle d’épargne, chaîne décisionnelle (2025) | Seuil de parallélisme et affinité processeur corrigés | Traitements terminés avant 9 h au lieu de 15 h |
| Groupe industriel, requête de règlement (2026) | Réécriture d’une borne de dates, sans index ni changement de schéma | De 15 h 59 de processeur à 19 secondes environ |
| Même groupe, procédure de purge (2026) | Index composite compressé | De 159 s à 669 ms |
| Distribution automobile, ERP métier (2019) | Réécriture d’une recherche textuelle | De 28 secondes à 1 seconde |
| Éditeur de logiciels immobiliers (2025) | Analyse d’une requête Entity Framework, plan forcé | De 28 s à 122 ms, cause corrigée ensuite par l’éditeur |
| Éditeur de logiciel pour l’élevage (2018 à 2021) | Procédures optimisées, index inutiles supprimés | Procédure clé de 35 s à 690 ms, 4 Go d’index supprimés |
| Producteur agroalimentaire (2026) | Migration vers SQL Server 2025, refonte de l’import, partitionnement mensuel | 28 millions de lignes reprises sans perte, lectures de la requête d’extraction divisées par 240 |
Stockage, coûts et exploitation
| Contexte | Ce que j’ai fait | Résultat |
|---|---|---|
| Organisation multi-sites, huit instances (2024) | Audit de migration vers SQL Server 2022 et consolidation | 8 serveurs et 35 cœurs consolidés sur un serveur Standard de 24 cœurs, 66 bases |
| Plateforme de trading de cryptoactifs (2019 à 2026) | DBA externe pendant sept ans, groupe de disponibilité, archivage vers PostgreSQL et Parquet | Migration de production vers AWS RDS en 2024, 1,3 milliard de lignes archivées |
| Entreprise sans sauvegarde planifiée, SQL Server 2005 (2019) | Intervention d’urgence : gels d’entrées-sorties provoqués par les instantanés de la machine virtuelle, migration le jour même | Production remise sur pied, sauvegardes en place |
| Grand magasin, système d’encaissement (2022) | Désactivation de NTLMv1 sur les caisses | Sécurité renforcée sans incident d’encaissement |
Constats d’audit
Quelques constats tirés d’audits récents, avant correction :
- un entrepôt de 4,4 To où une mise à jour réécrivait 17,5 millions de lignes pour 1 946 utiles, et causait 18 % des 8 143 blocages d’une nuit ;
- un parc de huit instances sans aucune notification, où 11 530 échecs de sauvegarde en onze jours étaient passés inaperçus ;
- une application de production où 66 interblocages ont été analysés un par un, avec la cause et la correction de chacun.