Einem Irrglauben nach werden durch ein Backup der DB zugleich die Datenbank Dateien verkleinert. Allerdings zeigt sich der SQL Server sehr resistent gegenüber solchen Schrumpfungsversuchen. Anders gesagt: Durch eine Sicherung der Datenbank - egal in welcher Form - läßt sich die Größe der Datenbank Dateien nicht verändern. (siehe dazu Zitat: "... Transaktionsprotokoll sichern. Dabei verkleinert es sich, da ein Teil des Protokolls nun in der Sicherungsdatei steht" (MS Office Forum) )

Anhand eines Beipiels möchte ich den Weg zur Verkleinerung darstellen:

Für den Versuch steht eine nagelneue DB "TestDB" zur Verfügung. Das Wiederherstellungsmodell ist auf den Modus "Vollständig" gesetzt. Im Gegensatz zum Modell "Einfach" werden hier alle Transaktionen nach dem Commit nicht sofort aus dem Transaktionsprotokoll gelöscht.

Für die weiteren Beobachtungen verwenden wir den Bericht "Datenträgerverwendung" im SQL Server Management Studio.
Der Rohzustand unserer TestDB sieht also folgendermaßen aus:

Zur Veranschaulichung lese ich einige Daten in die TestDB...(10000 Zeilen Import, alle Zeilen per delete löschen, und wieder 100000 Zeilen importieren).

select top 100000 * into testtab from adventureworks.person.countryregion,
       adventureworks.person.addr
go 
delete from testtab 
go 
drop table testtab 
go 
select top 100000 * into testtab from adventureworks.person.countryregion,
     adventureworks.person.addr 
go

Das Ergebnis für die Datenbankdateien sieht nun so aus:

Versuch Nummer 1: Vollständiges Backup

Was nun die Größe der Datenbank Dateien betrifft, ist das Ergebnis niederschmetternd. Keine Veränderung.Allerdings wird der geneigte Leser feststellen, dass die Speicherverwendung sich geändert hat. Das Transaktionsprotokoll wurde um die Einträge, die Commited sind erleichtert.

Versuch Nummer 2 Sicherung des Transaktionsprotokolls

Das Ergebnis scheinbar Null, was aber vorhersehbar war. Nachdem bereits abgeschlossene Transaktionen aus dem Transaktionsprotokoll entfernt wurden, gibts seither nichts merh was gelöscht werden könnte. Eine Verkleinerung der Datenbankdateien findet ebenfalls nicht statt.

Wie im Artikel "Datenbank Dateien verkleinern Teil 1" beschrieben, ist es nicht mit einem kleinen Klick getan und schon sind Datenbank Dateien verkleinert. Warum und wieso die Verkleinerung nicht einfach von statten geht, erklärt sich den Hintergrundaktivitäten...

Verkleinern der Datenbank

Im Prinzip kann jede Datei im SQL Server verkleinert werden. Allerdings gibt es gravierende Unterschiede zwischen Datendateien und Transktionsprotokolldatei. Die Dateien werden hierbei am Ende abgeschnitten Sofern sich am Ende der Datei nich Seiten befinden (ca. 8 kb), so werden diese vom Ende an den Teil verschoben, der nicht abgeschnitten wird. Die gewünschte Zielgröße kann dabei angegeben werden. Allerdings unterliegt diese eingen Einschränkungen:

1. Die DB kann nicht kleiner als der Ausgangswert der DB werden - sprich die Mindestgrößenangaben. Das entspricht häufig der model DB.
2. Die DB kann logischer nicht kleiner werden, als von Daten Platz belegt wird.

3. EIne einzelne Datei kann unter die Mindestgröße verkleinert werden. Dies ist jedoch nur per dbcc shrinkfile möglich.

Verkleinern des Transaktionsprotokolls

Das Verkleinern des Transaktionsprotokolls ist anderen Umständen unterworfen. Im Prinzip besteht das Transaktionsprotokoll aus virtuellen Dateien. Die virtuellen Dateien haben keine feste Größe und keine feste Anzahl. Sie werden beim Erstellen dynamisch angelegt. Sie können administrtaiv zumindest beinflusst werden durch etwas Angabe der Mindestgröße der Protokolldatei und der Vergrößerungsraten. Aus Performancegründen sollte diese bereits zu Beginn sehr "realistisch" eingeschätzt werden. Sprich: Wie groß wird das Protokoll werden...schwierige Entscheidung ;-)

Die Einträge in das Protokoll funktionieren so ähnlich wie meinen Belege für die Steuer.  In einer Art Schuhkarton System, die alle aufeinandergestapelt die jeweiligen Protokolleinträge enthalten, werden volle Kartons geleert. Das Leeren kann entweder durch ein Backup oder durch eine TRUNCATE passieren. Nur durch das entfernen inaktiver Einträge ist es möglich, dass das Protkoll nicht permanent wächst. Dies passiert letztenendlich, wenn das Ende des logischen Protokolls auf den Anfang des logischen Protokolls trifft. Neue Protokolleinträge werden dabei jeweils auf den vorherigen draufgelegt.  Die komplette zeitlich aufeinander folgenden Einträge nennt man logisches Protokoll. 

(Bilder zu Aritkel stammen aus der Microsoft Onlinedokumentation zu SQL Server 2005.)

Aus diesen Fakten erklärt sich auch der Umstand, dass Transaktionsprotokolle nicht auf eine beliebige Größe verkleinert werden können, sondern um die Größe der geleerten , inaktiven virtuellen Dateien. Daher sollte man vor jeder Verkleinerung nochmals eine Sicherung des Transaktionsprotokolls anwenden, um einen größtmöglichen Anteil an inaktiven Einträgen zu entfernen.

Achtung: Das Verkleinern eines  Transaktionsprotokolls kann im Falle von Sperren blockiert werden. Daher ist immer günstig die Verkleinerung per dbcc zu arrangieren, da hier mehr Information zurückgegeben werden.

Bspw:

dbcc shrinkdatabase (Adventureworks,10)

dbcc Result:
DBCC SHRINKDATABASE: Die Datei mit der ID 1 in der Datenbank mit der ID 8 wurde ausgelassen, da die Datei nicht genug freien Speicherplatz enthält, der wieder verfügbar gemacht werden kann.
Die DBCC-Ausführung wurde abgeschlossen. Falls DBCC Fehlermeldungen ausgegeben hat, wenden Sie sich an den Systemadministrator.

oder etwa: