DBCC SHRINKDATABASE (Transact-.SQL)

• 17.07.2017
• 8 Minuten zu lesen
• • p
  • M
  • j
  • i
  • K
  • +12

Gilt für: SQL Server (alle unterstützten Versionen) Azure SQL Database Azure Synapse Analytics

Die Größe der Daten- und Protokolldateien in der angegebenen Datenbank wird reduziert.

Transact-SQL-Syntaxkonventionen

Syntax

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 

-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

Argumente

Datenbankname | Datenbank_id | 0
Ist der Name oder die ID der Datenbank, die verkleinert werden soll. 0 gibt an, dass die aktuelle Datenbank verwendet wird.

Zielprozent
Ist der Prozentsatz an freiem Speicherplatz, der in der Datenbankdatei verbleiben soll, nachdem die Datenbank geschrumpft wurde.

NOTRUNCATE
Verschiebt zugewiesene Seiten vom Ende der Datei auf nicht zugewiesene Seiten am Anfang der Datei. Diese Aktion komprimiert die Daten in der Datei. target_percent ist optional. Azure Synapse Analytics unterstützt diese Option nicht.

Der freie Platz am Ende der Datei wird nicht an das Betriebssystem zurückgegeben, und die physische Größe der Datei ändert sich nicht. Daher scheint die Datenbank nicht zu schrumpfen, wenn Sie NOTRUNCATE angeben.

NOTRUNCATE ist nur auf Datendateien anwendbar. NOTRUNCATE hat keine Auswirkungen auf die Protokolldatei.

TRUNCATEONLY
Gibt den gesamten freien Speicherplatz am Ende der Datei an das Betriebssystem ab. Es werden keine Seiten innerhalb der Datei verschoben. Die Datendatei wird nur auf den zuletzt zugewiesenen Umfang verkleinert. Ignoriert target_percent, wenn mit TRUNCATEONLY angegeben. Azure Synapse Analytics unterstützt diese Option nicht.

TRUNCATEONLY wirkt sich auf die Protokolldatei aus. Um nur die Datendatei zu kürzen, verwenden Sie DBCC SHRINKFILE.

WITH NO_INFOMSGS
Unterdrückt alle Informationsmeldungen mit Schweregraden von 0 bis 10.

Ergebnismengen

Die folgende Tabelle beschreibt die Spalten in der Ergebnismenge.

Spaltenname	Beschreibung
DbId	Datenbank-Identifikationsnummer der Datei, die das Datenbankmodul zu verkleinern versucht hat.
FileId	Datei-Identifikationsnummer der Datei, die das Datenbankmodul zu verkleinern versucht.
CurrentSize	Anzahl der 8-KB-Seiten, die die Datei derzeit belegt.
MinimumSize	Anzahl der 8-KB-Seiten, die die Datei mindestens belegen könnte. Dieser Wert entspricht der Mindestgröße oder der ursprünglich erstellten Größe einer Datei.
BenutzteSeiten	Anzahl der 8-KB-Seiten, die derzeit von der Datei verwendet werden.
GeschätzteSeiten	Anzahl der 8-KB-Seiten, auf die die Datei nach Schätzungen des Datenbankmoduls verkleinert werden könnte.

Bemerkungen

Um alle Daten- und Protokolldateien für eine bestimmte Datenbank zu verkleinern, führen Sie den Befehl DBCC SHRINKDATABASE aus. Um jeweils eine Daten- oder Protokolldatei für eine bestimmte Datenbank zu verkleinern, führen Sie den Befehl DBCC SHRINKFILE aus.

Um die aktuelle Menge an freiem (nicht zugewiesenem) Speicherplatz in der Datenbank anzuzeigen, führen Sie sp_spaceused aus.

DBCC SHRINKDATABASE-Vorgänge können an jedem Punkt des Prozesses gestoppt werden, und jede abgeschlossene Arbeit wird beibehalten.

Die Datenbank kann nicht kleiner als die konfigurierte Mindestgröße der Datenbank sein. Sie geben die Mindestgröße bei der ursprünglichen Erstellung der Datenbank an. Die Mindestgröße kann auch die letzte Größe sein, die explizit durch eine Operation zur Änderung der Dateigröße festgelegt wurde. Operationen wie DBCC SHRINKFILE oder ALTER DATABASE sind Beispiele für Operationen zur Änderung der Dateigröße.

Angenommen, eine Datenbank wird ursprünglich mit einer Größe von 10 MB erstellt. Dann wächst sie auf 100 MB an. Die kleinste Größe, auf die die Datenbank reduziert werden kann, ist 10 MB, auch wenn alle Daten in der Datenbank gelöscht wurden.

Spezifizieren Sie entweder die Option NOTRUNCATE oder die Option TRUNCATEONLY, wenn Sie DBCC SHRINKDATABASE ausführen. Wenn Sie dies nicht tun, ist das Ergebnis dasselbe, wie wenn Sie eine DBCC SHRINKDATABASE-Operation mit NOTRUNCATE und anschließend eine DBCC SHRINKDATABASE-Operation mit TRUNCATEONLY ausführen.

Die geschrumpfte Datenbank muss sich nicht im Einzelbenutzermodus befinden. Andere Benutzer können in der Datenbank arbeiten, wenn sie verkleinert wird, einschließlich Systemdatenbanken.

Sie können eine Datenbank nicht verkleinern, während die Datenbank gesichert wird. Umgekehrt können Sie keine Datenbank sichern, während ein Verkleinerungsvorgang für die Datenbank läuft.

Wie DBCC SHRINKDATABASE funktioniert

DBCC SHRINKDATABASE verkleinert Datendateien auf Dateibasis, verkleinert aber Protokolldateien, als ob alle Protokolldateien in einem zusammenhängenden Protokollpool vorhanden wären. Dateien werden immer vom Ende her geschrumpft.

Angenommen, Sie haben einige Protokolldateien, eine Datendatei und eine Datenbank namens mydb. Die Daten- und Protokolldateien sind jeweils 10 MB groß und die Datendatei enthält 6 MB an Daten. Die Datenbank-Engine berechnet für jede Datei eine Zielgröße. Dieser Wert ist die Größe, auf die die Datei verkleinert werden soll. Wenn DBCC SHRINKDATABASE mit target_percent angegeben wird, berechnet die Datenbank-Engine die Zielgröße als die Menge an freiem Speicherplatz in der Datei nach der Verkleinerung.

Wenn Sie zum Beispiel target_percent von 25 für die Verkleinerung von mydb angeben, berechnet die Datenbank-Engine die Zielgröße für die Datendatei auf 8 MB (6 MB Daten plus 2 MB freier Speicherplatz). Daher verschiebt die Datenbank-Engine alle Daten aus den letzten 2 MB der Datendatei in den freien Speicherplatz in den ersten 8 MB der Datendatei und verkleinert dann die Datei.

Angenommen, die Datendatei von mydb enthält 7 MB an Daten. Durch die Angabe eines target_percent von 30 kann diese Datendatei auf den freien Prozentsatz von 30 verkleinert werden. Wenn Sie jedoch einen target_percent von 40 angeben, wird die Datendatei nicht verkleinert, da die Datenbank-Engine eine Datei nicht auf eine kleinere Größe verkleinert, als die Daten derzeit belegen.

Sie können sich dieses Problem auch anders vorstellen: 40 Prozent gewünschter freier Speicherplatz + 70 Prozent volle Datendatei (7 MB von 10 MB) sind mehr als 100 Prozent. Jede target_size größer als 30 wird die Datendatei nicht verkleinern. Sie wird nicht verkleinert, weil der gewünschte freie Prozentsatz plus der aktuelle Prozentsatz, den die Datendatei belegt, über 100 Prozent liegt.

Für Protokolldateien verwendet die Datenbankmaschine target_percent, um die Zielgröße für das gesamte Protokoll zu berechnen. Deshalb ist target_percent die Menge an freiem Platz im Protokoll nach der Verkleinerungsoperation. Die Zielgröße für das gesamte Protokoll wird dann in eine Zielgröße für jede Protokolldatei umgerechnet.

DBCC SHRINKDATABASE versucht, jede physische Protokolldatei sofort auf ihre Zielgröße zu verkleinern. Angenommen, kein Teil des logischen Protokolls verbleibt in den virtuellen Protokollen über die Zielgröße der Protokolldatei hinaus. In diesem Fall wird die Datei erfolgreich abgeschnitten und DBCC SHRINKDATABASE wird ohne Meldungen beendet. Wenn jedoch ein Teil des logischen Protokolls in den virtuellen Protokollen über die Zielgröße hinaus verbleibt, gibt die Datenbank-Engine so viel Platz wie möglich frei und gibt dann eine Informationsmeldung aus. In dieser Meldung wird beschrieben, welche Aktionen erforderlich sind, um das logische Protokoll am Ende der Datei aus den virtuellen Protokollen zu entfernen. Nachdem die Aktionen ausgeführt wurden, kann DBCC SHRINKDATABASE verwendet werden, um den verbleibenden Platz freizugeben.

Eine Protokolldatei kann nur bis zu einer virtuellen Protokolldateigrenze verkleinert werden. Deshalb ist es unter Umständen nicht möglich, eine Protokolldatei auf eine Größe zu verkleinern, die kleiner ist als die Größe einer virtuellen Protokolldatei. Dies ist möglicherweise auch dann nicht möglich, wenn die Datei nicht verwendet wird. Die Größe der virtuellen Protokolldatei wird von der Datenbank-Engine dynamisch ausgewählt, wenn Protokolldateien erstellt oder erweitert werden.

Best Practices

Beachten Sie die folgenden Informationen, wenn Sie planen, eine Datenbank zu verkleinern:

• Eine Verkleinerungsoperation ist am effektivsten nach einer Operation, die ungenutzten Speicherplatz erzeugt, wie z. B. eine Truncate-Tabelle oder eine Drop-Table-Operation.
• Die meisten Datenbanken benötigen etwas freien Speicherplatz, um für regelmäßige tägliche Operationen verfügbar zu sein. Sie können eine Datenbank wiederholt verkleinern und feststellen, dass die Datenbankgröße wieder zunimmt. Dieses Wachstum deutet darauf hin, dass der verkleinerte Speicherplatz für reguläre Operationen benötigt wird. In diesen Fällen ist das wiederholte Verkleinern der Datenbank eine Verschwendung.
• Ein Verkleinerungsvorgang behält den Fragmentierungsstatus der Indizes in der Datenbank nicht bei und erhöht im Allgemeinen die Fragmentierung bis zu einem gewissen Grad. Dieses Ergebnis ist ein weiterer Grund, die Datenbank nicht wiederholt zu verkleinern.
• Setzen Sie die Datenbankoption AUTO_SHRINK nicht auf ON, es sei denn, Sie haben eine spezielle Anforderung.

Fehlerbehebung

Es ist möglich, Verkleinerungsvorgänge durch eine Transaktion zu blockieren, die unter einer auf Zeilenversionierung basierenden Isolierungsebene ausgeführt wird. Beispielsweise ist eine große Löschoperation, die unter einem auf Zeilenversionierung basierenden Isolation-Level läuft, im Gange, wenn eine DBCC SHRINK DATABASE-Operation ausgeführt wird. In diesem Fall wartet der Verkleinerungsvorgang auf den Abschluss des Löschvorgangs, bevor er die Dateien verkleinert. Wenn der Verkleinerungsvorgang wartet, geben die Operationen DBCC SHRINKFILE und DBCC SHRINKDATABASE eine Informationsmeldung aus (5202 für SHRINKDATABASE und 5203 für SHRINKFILE). Diese Meldung wird in der ersten Stunde alle fünf Minuten und danach jede weitere Stunde in das SQL Server-Fehlerprotokoll gedruckt. Wenn das Fehlerprotokoll beispielsweise die folgende Fehlermeldung enthält:

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. 

Dieser Fehler bedeutet, dass Snapshot-Transaktionen, deren Zeitstempel älter als 109 ist, den Shrink-Vorgang blockieren. Diese Transaktion ist die letzte Transaktion, die der Shrink-Vorgang abgeschlossen hat. Er zeigt auch an, dass die Spalten transaction_sequence_num oder first_snapshot_sequence_num in der dynamischen Verwaltungsansicht sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) einen Wert von 15 enthalten. Die Spalte transaction_sequence_num oder first_snapshot_sequence_num in der Ansicht kann eine Zahl enthalten, die kleiner ist als die letzte durch einen Schrumpfungsvorgang abgeschlossene Transaktion (109). Wenn dies der Fall ist, wartet der Verkleinerungsvorgang auf den Abschluss dieser Transaktionen.

Um das Problem zu beheben, können Sie eine der folgenden Aufgaben ausführen:

• Beenden Sie die Transaktion, die den Verkleinerungsvorgang blockiert.
• Beenden Sie den Verkleinerungsvorgang. Jede abgeschlossene Arbeit wird beibehalten.
• Tun Sie nichts und lassen Sie den Verkleinerungsvorgang warten, bis die blockierende Transaktion abgeschlossen ist.

Berechtigungen

Erfordert die Mitgliedschaft in der festen Serverrolle sysadmin oder der festen Datenbankrolle db_owner.

Beispiele

A. Verkleinern einer Datenbank und Angeben eines Prozentsatzes an freiem Speicherplatz

Das folgende Beispiel reduziert die Größe der Daten- und Protokolldateien in der Benutzerdatenbank UserDB, um 10 Prozent freien Speicherplatz in der Datenbank zu ermöglichen.

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. Kürzen einer Datenbank

Das folgende Beispiel schrumpft die Daten- und Protokolldateien in der AdventureWorks-Beispieldatenbank auf den zuletzt zugewiesenen Umfang.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Verkleinern einer Azure Synapse Analytics-Datenbank

DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10); 

Siehe auch

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Datenbank verkleinern