Compression des données SQL Server : coût et bénéfice

La compression row et page réduit stockage et E/S, mais ajoute du CPU et n'aide pas toutes les tables de la même façon. La décision dépend des données et de la charge.

Ce qu'il faut mesurer

Estimez les gains par table et index, puis mesurez scans, seeks, CPU, buffer, taille des sauvegardes, maintenance et écritures sous charge représentative.

Approche pratique

Évaluez d'abord les gros objets très lus, testez row et page séparément, appliquez par partition ou index et prévoyez reconstruction, journal et espace de retour arrière.

Ce qu'il faut éviter

Ne compressez pas tous les objets, ne jugez pas uniquement l'espace disque et n'ignorez pas les charges limitées par le CPU ni la maintenance.

Résultat opérationnel

La compression est utile lorsque la baisse des E/S et du cache dépasse le coût CPU et opérationnel.

Checklist de production

Établissez une référence et définissez l'amélioration attendue. Testez avec des données et une concurrence représentatives. Conservez la configuration ou le plan d'origine, préparez un retour arrière et surveillez le prochain pic normal de charge.

Pour appliquer cette méthode à un environnement SQL Server précis, utilisez le formulaire ci-dessous et indiquez la version, la taille de la base, le profil de charge et les éléments déjà collectés.