Robert machte mich auf einen interessanten Artikel zum Thema "verkleinern von Datenbanken" aufmerksam. Trotz der aktuellen Preise von Massenspeichern wünschen sich unsere Kunden immer wieder, dass deren Datenbanken regelmäßig verkleinert werden. Die Gründe sind immer gleich:
- Die Datenbank-Dateien sind so groß, dass der Plattenplatz knapp wird.
Gegenvorschlag: Plattenplatz zukaufen. - Die Datensicherung und -prüfung dauert wegen des Umfangs so lange, dass das dafür vorgesehene Zeitfenster nicht mehr reicht.
Gegenvorschlag: Datensicherung erst mal auf Platte mache und dann die kopierten Datenbanken an einen anderen SQL-Server hängen und prüfen. Danach erst die echte Sicherung auf dieser Kopie laufen lassen. Wie lange das dauert ist ja wurscht, weil parallel dazu auf dem Original weiter gearbeitet werden kann. - Umfangreiche Datenbestände wurden gelöscht. Dann wird die DB meist auch erst mal größer. Dann lohnt es sich häufig wirklich die Datenbank zu verkleinern.
Aber das hat freilich etliche negative Effekte:
- Sobald Daten geändert oder eingefügt werden, dann wird die Datenbank wieder vergrößert. Das kostet Zeit.
- Datenbank-Wachstum hat Gründe. Wenn die Datenbank wächst und dann nach einiger Zeit viele leere Seiten drin sind, dann hat das seinen Grund. In so einem Fall wird die Datenbank bald wieder wachsen.
- Regelmäßiges verkleinern und dann wieder vergrößern von Datenbanken fragmentiert die Datenbank-Dateien. Das wirkt sich negativ auf die Performance aus. Auch beim Einsatz von RAID-Systemen.
Wie stark es die Performance beeinflusst kann man hier nachlesen: Can you shrink your SQL Server database to death?