Freigeben über

DBCC SHRINKDATABASE (Transact-SQL)

  • Artikel

Reduziert die Größe der Daten- und Protokolldateien in der angegebenen Datenbank.

Gilt für: SQL Server (SQL Server 2008 bis aktuelle Version).

Themenlink (Symbol) Transact-SQL-Syntaxkonventionen

Syntax

DBCC SHRINKDATABASE 
( database_name | database_id | 0 
     [ , target_percent ] 
     [ , { NOTRUNCATE | TRUNCATEONLY } ] 
)
[ WITH NO_INFOMSGS ]

Argumente

  • database_name | database_id | 0
    Der Name oder die ID der Datenbank, die verkleinert werden soll. Wird 0 angegeben, wird die aktuelle Datenbank verwendet.

  • target_percent
    Der gewünschte Prozentsatz an freiem Speicherplatz, der in der Datenbankdatei übrig bleiben soll, nachdem die Datenbank verkleinert wurde.

  • NOTRUNCATE
    Komprimiert die Daten in Datendateien durch Verschieben von zugeordneten Seiten vom Ende einer Datei in nicht zugeordnete Seiten am Dateianfang. target_percent ist optional.

    Der freie Speicherplatz am Dateiende wird nicht an das Betriebssystem zurückgegeben, und die physische Größe der Datei bleibt unverändert. Daher scheint die Datenbank bei Angabe von NOTRUNCATE nicht verkleinert zu werden.

    NOTRUNCATE gilt nur für Datendateien. Die Protokolldatei ist nicht betroffen.

  • TRUNCATEONLY
    Gibt den gesamten freien Speicherplatz am Dateiende an das Betriebssystem frei, es werden jedoch keine Seiten innerhalb der Datei verschoben. Die Datendatei wird nur bis zum letzten zugeordneten Block verkleinert. Der target_percent-Parameter wird ignoriert, wenn er mit TRUNCATEONLY angegeben wird.

    TRUNCATEONLY wirkt sich auf die Protokolldatei aus. Um nur die Datendatei abzuschneiden, verwenden Sie DBCC SHRINKFILE.

  • WITH NO_INFOMSGS
    Unterdrückt alle Informationsmeldungen, die einen Schweregrad von 0 bis 10 aufweisen.

Resultsets

In der folgenden Tabelle werden die Spalten des Resultsets beschrieben:

Spaltenname

Beschreibung

DbId

Die Datenbank-ID der Datei, die das Database Engine (Datenbankmodul) zu verkleinern versuchte.

FileId

Datei-ID der Datei, die das Database Engine (Datenbankmodul) zu verkleinern versuchte.

CurrentSize

Die Anzahl von 8-KB-Seiten, die die Datei derzeit belegt.

MinimumSize

Die Anzahl von 8-KB-Seiten, die die Datei minimal belegen könnte. Dies entspricht der Mindestgröße bzw. der ursprünglich erzeugten Dateigröße.

UsedPages

Die Anzahl von 8-KB-Seiten, die derzeit von der Datei verwendet werden.

EstimatedPages

Die Anzahl an 8-KB-Seiten, auf die die Datei wahrscheinlich vom Database Engine (Datenbankmodul) verkleinert werden kann.

Hinweis

Das Database Engine (Datenbankmodul) zeigt keine Zeilen für Dateien an, die nicht verkleinert wurden.

Hinweise

Zum Verkleinern aller Daten- und Protokolldateien einer bestimmten Datenbank führen Sie den DBCC SHRINKDATABASE-Befehl aus. Zum Verkleinern einer einzelnen Daten- oder Protokolldatei einer bestimmten Datenbank führen Sie den DBCC SHRINKFILE-Befehl aus.

Zum Anzeigen des aktuellen freien (nicht zugeordneten) Speicherplatzes in der Datenbank führen Sie sp_spaceused aus.

DBCC SHRINKDATABASE-Vorgänge können an jeder Stelle des Vorgangs beendet werden, wobei der bereits abgeschlossene Anteil erhalten bleibt.

Die Datenbank kann nicht unter die Mindestgröße der Datenbank verkleinert werden. Die Mindestgröße ist die Größe, die beim Erstellen der Datei angegeben wurde, bzw. die letzte Größe, die bei einer Dateigrößenänderung, z. B. mit DBCC SHRINKFILE oder ALTER DATABASE, explizit festgelegt wurde. Wenn eine Datenbank z. B. mit einer Größe von 10 MB erstellt und auf 100 MB vergrößert wurde, kann die Datenbank höchstens auf 10 MB verkleinert werden, auch wenn alle Daten in der Datenbank gelöscht wurden.

Das Ausführen von DBCC SHRINKDATABASE ohne eine der Optionen NOTRUNCATE oder TRUNCATEONLY entspricht einem DBCC SHRINKDATABASE-Vorgang mit NOTRUNCATE und einem anschließenden DBCC SHRINKDATABASE-Vorgang mit TRUNCATEONLY.

Die Datenbank, die verkleinert werden soll, muss sich nicht im Einzelbenutzermodus befinden. Andere Benutzer können während der Verkleinerung darin arbeiten. Das gilt auch für Systemdatenbanken.

Während einer Datenbanksicherung können Sie die Datenbank nicht verkleinern. Umgekehrt können Sie eine Datenbank nicht sichern, während ein Verkleinerungsvorgang für die Datenbank ausgeführt wird.

Funktionsweise von DBCC SHRINKDATABASE

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.

Das 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 das 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 das Database Engine (Datenbankmodul) eine Zielgröße von 8 MB für die Datendatei (6 MB Daten plus 2 MB freier Speicherplatz). Daher werden vom 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 Datendatei auf einen freien Prozentsatz von 30 verkleinert werden. Durch die Angabe eines target_percent-Werts von 40 wird die Datendatei jedoch nicht verkleinert, da das Database Engine (Datenbankmodul) keine Datei auf eine Größe verkleinert, die unter der von den Daten belegten Größe liegt. 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 vom 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 das Database Engine (Datenbankmodul) so viel Speicherplatz frei wie möglich und gibt dann eine Informationsmeldung aus. Die Meldung beschreibt, welche Aktionen erforderlich sind, um das logische Protokoll aus den virtuellen Protokollen am Ende der Datei zu verschieben. Nachdem diese Aktionen ausgeführt wurden, kann der verbleibende Speicherplatz mit DBCC SHRINKDATABASE freigegeben werden.

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 vom Database Engine (Datenbankmodul) ausgewählt, wenn Protokolldateien erstellt oder erweitert werden.

Bewährte Methoden

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 tägliche Routinevorgä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 wird der Fragmentierungszustand der Indizes in der Datenbank nicht beibehalten. 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.

Problembehandlung

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, geben 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 Zeitstempeln ä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.

Berechtigungen

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

Beispiele

A.Verkleinern einer Datenbank und Angeben des freien Speicherplatzes in Prozent

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

B.Abschneiden einer Datenbank

Im folgenden Beispiel werden die Daten- und Protokolldateien in der AdventureWorks-Beispieldatenbank auf den letzten zugeordneten Block verkleinert.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);

Siehe auch

Verweis

ALTER DATABASE (Transact-SQL)

DBCC (Transact-SQL)

DBCC SHRINKFILE (Transact-SQL)

Konzepte

Verkleinern einer Datenbank