DBCC SHRINKDATABASE (Transact-SQL)

DBCC SHRINKDATABASE verkleinert Datendateien pro Datei, Protokolldateien jedoch so, als lägen alle Protokolldateien in einem zusammenhängenden Protokollpool vor. Dateien werden immer am Ende verkleinert.

Ausgangspunkt sei eine Datenbank namens mydb mit einer Datendatei und zwei Protokolldateien. Die Datendatei und die Protokolldateien sind jeweils 10 MB groß, die Datendatei enthält 6 MB an Daten.

Database Engine (Datenbankmodul) berechnet für jede Datei eine Zielgröße. Auf diese Größe soll die Datei verkleinert werden. Wird DBCC SHRINKDATABASE mit target_percent angegeben, berechnet Database Engine (Datenbankmodul) die Zielgröße als target_percent-Umfang an freiem Speicherplatz in der Datei nach der Verkleinerung. Wenn Sie beispielsweise für target_percent den Wert 25 für die Verkleinerung von mydb angeben, berechnet Database Engine (Datenbankmodul) eine Zielgröße von 8 MB für die Datendatei (6 MB Daten plus 2 MB freier Speicherplatz). Daher werden von Database Engine (Datenbankmodul) sämtliche Daten aus den letzten 2 MB der Datendatei in freie Bereiche innerhalb der ersten 8 MB der Datendatei verschoben, und anschließend wird die Datei verkleinert.

Angenommen, die Datendatei von mydb enthält 7 MB Daten. Durch die Angabe eines target_percent-Werts von 30 kann diese Datei auf einen freien Prozentsatz von 30 verkleinert werden. Die Angabe eines target_percent-Wertes von 40 verkleinert jedoch nicht die Datendatei, da der Database Engine (Datenbankmodul) keine Datei zu einer Größe verkleinert, die geringer ist, als die die die Daten derzeit belegen. Sie können dieses Problem auch von einem anderen Winkel aus betrachten: 40 Prozent erwünschter freier Speicherplatz plus 70 Prozent volle Datendatei (7 MB von 10 MB) ergeben mehr als 100 Prozent. Da der gewünschte freie Prozentsatz zuzüglich des Prozentsatzes, den die Datendatei gegenwärtig belegt, den Wert 100 Prozent um 10 Prozent übersteigt, wird die Datendatei bei target_size größer als 30 nicht verkleinert.

Bei Protokolldateien wird target_percent von Database Engine (Datenbankmodul) dafür verwendet, die Zielgröße der gesamten Protokolldatei zu berechnen, sodass target_percent die Größe des freien Speicherplatzes in der Protokolldatei nach dem Verkleinern angibt. Die Zielgröße für das gesamte Protokoll wird dann in eine Zielgröße für jede Protokolldatei umgewandelt.

DBCC SHRINKDATABASE versucht, jede physische Protokolldatei sofort auf ihre Zielgröße zu verkleinern. Wenn sich kein Teil des logischen Protokolls in den virtuellen Protokollen befindet, die außerhalb der Zielgröße der Protokolldatei liegen, wird die Datei erfolgreich abgeschnitten, und DBCC SHRINKDATABASE wird ohne Meldungen beendet. Wenn sich dagegen ein Teil des logischen Protokolls in den virtuellen Protokollen befindet, die außerhalb der Zielgröße liegen, gibt Database Engine (Datenbankmodul) so viel Speicherplatz frei wie möglich und gibt dann eine Informationsmeldung aus. Diese Meldung beschreibt, welche Aktionen erforderlich sind, um das logische Protokoll aus den virtuellen Protokollen am Ende der Datei heraus zu verschieben. Nachdem diese Aktionen ausgeführt wurden, kann der verbleibende Speicherplatz mit DBCC SHRINKDATABASE freigegeben werden. Weitere Informationen finden Sie unter Verkleinern des Transaktionsprotokolls.

Da eine Protokolldatei nur auf eine Grenze einer virtuellen Protokolldatei verkleinert werden kann, ist eine Verkleinerung der Protokolldatei auf eine geringere Größe als die einer virtuellen Protokolldatei u. U. nicht möglich, selbst wenn die Protokolldatei nicht verwendet wird. Die Größe der virtuellen Protokolldatei wird dynamisch von Database Engine (Datenbankmodul) ausgewählt, wenn Protokolldateien erstellt oder erweitert werden. Weitere Informationen zu virtuellen Protokolldateien finden Sie unter Physische Architektur des Transaktionsprotokolls.

Berücksichtigen Sie die folgenden Informationen, wenn Sie eine Datenbank verkleinern möchten:

• Ein Verkleinerungsvorgang ist am effektivsten nach einem Vorgang, durch den umfangreicher nicht verwendeter Speicherplatz zur Verfügung gestellt wird, z. B. das Abschneiden oder Löschen einer Tabelle.

• Die meisten Datenbanken erfordern verfügbaren freien Speicherplatz für die normalen alltäglichen Vorgänge. Wenn Sie eine Datenbank wiederholt verkleinern und feststellen, dass die Datenbankgröße wieder zunimmt, deutet dies darauf hin, dass der verkleinerte Speicherplatz für regelmäßige Vorgänge benötigt wird. In diesem Fall ist das Verkleinern der Datenbank vergeblich.

• Bei einem Verkleinerungsvorgang bleibt der Fragmentierungszustand der Indizes in der Datenbank nicht erhalten. Im Allgemeinen wird die Fragmentierung zu einem gewissen Grad verstärkt. Dies ist ein weiterer Grund, die Datenbank nicht wiederholt zu verkleinern.

• Legen Sie die Datenbankoption AUTO_SHRINK nicht auf ON fest, es sei denn, besondere Anforderungen machen dies erforderlich.

Es kann vorkommen, dass Verkleinerungsvorgänge durch eine Transaktion blockiert werden, die auf einer auf Zeilenversionsverwaltung basierenden Isolationsstufe ausgeführt wird. Erfolgt z. B. während eines DBCC SHRINKDATABASE-Vorgangs gleichzeitig ein umfangreicher Löschvorgang, der auf einer auf Zeilenversionsverwaltung basierenden Isolationsstufe ausgeführt wird, wird auf den Abschluss des Löschvorgangs gewartet, bevor die Dateien verkleinert werden. Ist dies der Fall, drucken DBCC SHRINKFILE- und DBCC SHRINKDATABASE-Vorgänge in der ersten Stunde alle fünf Minuten, danach jede Stunde eine Informationsmeldung in das SQL Server-Fehlerprotokoll (5202 für SHRINKDATABASE und 5203 für SHRINKFILE) aus. Das Fehlerprotokoll kann beispielsweise eine Fehlermeldung wie die folgende enthalten:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot 
transaction with timestamp 15 and other snapshot transactions linked to 
timestamp 15 or with timestamps older than 109 to finish.

Dies bedeutet, dass der Verkleinerungsvorgang durch Momentaufnahmetransaktionen mit Timestamps älter als 109 blockiert ist, was der letzten vom Verkleinerungsvorgang abgeschlossenen Transaktion entspricht. Außerdem zeigt es an, dass die transaction_sequence_num-Spalte oder die first_snapshot_sequence_num-Spalte in der dynamischen sys.dm_tran_active_snapshot_database_transactions (Transact-SQL)-Verwaltungssicht den Wert 15 enthält. Wenn eine der Spalten transaction_sequence_num oder first_snapshot_sequence_num in der Sicht eine Zahl enthält, die kleiner ist als die letzte durch einen Verkleinerungsvorgang abgeschlossene Transaktion (109), wird mit dem Verkleinerungsvorgang bis zum Abschluss dieser Transaktionen gewartet.

Führen Sie eine der folgenden Aufgaben aus, um das Problem zu beheben:

• Beenden Sie die Transaktion, die den Verkleinerungsvorgang blockiert.

• Beenden Sie den Verkleinerungsvorgang. Der bereits abgeschlossene Teil bleibt erhalten.

• Führen Sie keine besonderen Aktionen aus, und lassen Sie zu, dass mit dem Verkleinerungsvorgang gewartet wird, bis die blockierende Transaktion abgeschlossen ist.

Weitere Informationen zum SQL Server-Fehlerprotokoll finden Sie unter Anzeigen des SQL Server-Fehlerprotokolls.

Im folgenden Beispiel wird die Größe der Daten- und Protokolldateien in der UserDB-Benutzerdatenbank so verringert, dass die Datenbank 10 Prozent freien Speicherplatz enthält.

DBCC SHRINKDATABASE (UserDB, 10);
GO

Im folgenden Beispiel werden die Datendateien in der AdventureWorks2008R2-Beispieldatenbank auf den letzten zugeordneten Block verkleinert.

DBCC SHRINKDATABASE (AdventureWorks2008R2, TRUNCATEONLY);