SQL-Server-Datenkomprimierung: Kosten und Nutzen

Row- und Page-Compression reduzieren Speicher und I/O, benötigen aber CPU und helfen nicht jeder Tabelle gleich. Die Entscheidung hängt von Datenform und Last ab.

Was gemessen werden sollte

Schätzen Sie Einsparungen je Tabelle und Index und messen Sie Scans, Seeks, CPU, Buffer-Nutzung, Sicherungsgröße, Wartungsdauer und schreibintensive Vorgänge unter realistischer Last.

Praktisches Vorgehen

Bewerten Sie große leseintensive Objekte zuerst, testen Sie Row und Page getrennt, wenden Sie Komprimierung gezielt je Partition oder Index an und planen Sie Rebuild-Zeit, Logvolumen und Rollback-Platz.

Was vermieden werden sollte

Komprimieren Sie nicht jedes Objekt, beurteilen Sie nicht nur Plattenplatz und ignorieren Sie CPU-limitierte Lasten sowie Wartungskosten nicht.

Betriebliches Ergebnis

Komprimierung lohnt sich, wenn weniger I/O und Cachebedarf die zusätzliche CPU und Betriebskosten überwiegen.

Checkliste für die Produktion

Erfassen Sie eine Ausgangsbasis und definieren Sie die erwartete Verbesserung. Testen Sie mit repräsentativen Daten und realistischer Parallelität. Sichern Sie die ursprüngliche Einstellung oder den Plan, bereiten Sie einen Rollback vor und überwachen Sie die nächste normale Lastspitze.

Wenn Sie diese Methode auf eine konkrete SQL-Server-Umgebung anwenden möchten, nutzen Sie das Frageformular unten und nennen Sie SQL-Server-Version, Datenbankgröße, Lastprofil und bereits erfasste Nachweise.