DBCC SHRINKFILE (Transact-SQL)

Reduziert die Größe der angegebenen Daten- oder Protokolldatei für die aktuelle Datenbank oder leert eine Datei, indem die Daten aus der angegebenen Datei in andere Dateien in derselben Dateigruppe verschoben werden, sodass die Datei aus der Datenbank entfernt werden kann. Sie können eine Datei auf eine Größe reduzieren, die kleiner ist als die bei der Erstellung angegebene Größe. Dadurch wird die Mindestdateigröße auf einen neuen Wert zurückgesetzt.

Transact-SQL-Syntaxkonventionen

Syntax

DBCC SHRINKFILE 
(
    { file_name | file_id } 
    { [ , EMPTYFILE ] 
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH NO_INFOMSGS ]

Argumente

• file_name
  Der logische Name der Datei, die verkleinert werden soll.

• file_id
  Die Datei-ID der Datei, die verkleinert werden soll. Verwenden Sie zum Ermitteln einer Datei-ID die FILE_IDEX-Systemfunktion, oder fragen Sie die sys.database_files-Katalogsicht in der aktuellen Datenbank ab.

• target_size
  Die Größe für die Datei in MB (als ganze Zahl). Wenn nichts angegeben wird, wird die Größe von DBCC SHRINKFILE auf die standardmäßige Dateigröße reduziert. Die Standardgröße ist die Größe, die beim Erstellen der Datei angegeben wurde.

  Hinweis
  Sie können die Standardgröße einer leeren Datei mit DBCC SHRINKFILE target_size verringern. Wenn Sie z. B. eine 5 MB große Datei erstellen und die Dateigröße dann auf 3 MB herabsetzen, während die Datei noch leer ist, wird die Standarddateigröße auf 3 MB festgelegt. Dies gilt nur für leere Dateien, die nie Daten enthalten haben.

  Diese Option wird in FILESTREAM-Dateigruppencontainern nicht unterstützt.

  Wenn target_size angegeben wird, versucht DBCC SHRINKFILE, die Datei auf die gewünschte Größe zu verkleinern. Bereits verwendete Seiten in dem Teil der Datei, der freigegeben werden soll, werden auf freien Speicherplatz in dem Teil der Datei verschoben, der beibehalten werden soll. Ist z. B. eine Datendatei mit einer Größe von 10 MB vorhanden, wird durch einen DBCC SHRINKFILE-Vorgang mit einer target_size-Angabe von 8 veranlasst, dass alle verwendeten Seiten, die sich in den letzten 2 MB der Datei befinden, in nicht zugeordnete Seiten der ersten 8 MB dieser Datei verschoben werden. DBCC SHRINKFILE verkleinert die Datei nur so weit, dass der erforderliche Speicherplatz für die Daten unangetastet bleibt. Werden beispielsweise 7 MB einer 10 MB großen Datendatei verwendet, verkleinert eine DBCC SHRINKFILE-Anweisung mit einer target_size-Angabe von 6 die Datei lediglich auf 7 MB statt auf 6 MB.

• EMPTYFILE
  Verlagert alle Daten aus der angegebenen Datei in andere Dateien in derselben Dateigruppe. Da Datenbankmodul nicht mehr zulässt, dass Daten in der leeren Datei platziert werden, kann die Datei mithilfe der ALTER DATABASE-Anweisung entfernt werden.

  Die Datei kann aus FILESTREAM-Dateigruppencontainern erst dann mit ALTER DATABASE entfernt werden, nachdem der FILESTREAM-Garbage Collector ausgeführt und alle nicht benötigten Dateigruppen-Containerdateien gelöscht wurden, die von EMPTYFILE in einen anderen Container kopiert wurden. Weitere Informationen finden Sie unter sp_filestream_force_garbage_collection (Transact-SQL).

  Hinweis
  Informationen zum Entfernen eines FILESTREAM-Containers finden Sie im entsprechenden Abschnitt in ALTER DATABASE-Optionen Datei und Dateigruppe (Transact-SQL)

• NOTRUNCATE
  Verschiebt zugeordnete Seiten vom Ende einer Datendatei in nicht zugeordnete Seiten am Dateianfang, und zwar mit oder ohne Angabe von target_percent. 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 Datei bei Angabe von NOTRUNCATE nicht verkleinert zu werden.

  NOTRUNCATE gilt nur für Datendateien. Die Protokolldateien sind nicht betroffen.

  Diese Option wird in FILESTREAM-Dateigruppencontainern nicht unterstützt.

• 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_size-Parameter wird ignoriert, wenn er mit TRUNCATEONLY angegeben wird.

  Die Option TRUNCATEONLY verschiebt Informationen nicht in das Protokoll, entfernt jedoch inaktive VLFs am Ende der Protokolldatei. Diese Option wird in FILESTREAM-Dateigruppencontainern nicht unterstützt.

• WITH NO_INFOMSGS
  Unterdrückt alle Informationsmeldungen.

Resultsets

In der folgenden Tabelle werden die Spalten des Resultsets beschrieben.

Hinweise

DBCC SHRINKFILE gilt für die Dateien der aktuellen Datenbank. Weitere Informationen zum Ändern der aktuellen Datenbank finden Sie unter USE (Transact-SQL).

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

Wenn ein DBCC SHRINKFILE-Vorgang fehlschlägt, wird ein Fehler ausgelöst.

Die Datenbank, die verkleinert werden soll, muss sich nicht im Einzelbenutzermodus befinden. Andere Benutzer können während der Verkleinerung der Datei an der Datenbank arbeiten. Um die Systemdatenbanken zu verkleinern, muss auch SQL Server nicht im Einzelbenutzermodus ausgeführt werden.

Verkleinern einer Protokolldatei

Bei Protokolldateien wird target_size von Datenbankmodul dafür verwendet, die Zielgröße der gesamten Protokolldatei zu berechnen, sodass target_size die Größe des freien Speicherplatzes in der Protokolldatei nach dem Verkleinern angibt. Die Zielgröße des gesamten Protokolls wird dann in die Zielgröße für jede Protokolldatei umgewandelt. DBCC SHRINKFILE versucht, jede physische Protokolldatei sofort auf ihre Zielgröße zu verkleinern. Wenn sich dagegen ein Teil des logischen Protokolls in den virtuellen Protokollen befindet, die außerhalb der Zielgröße liegen, gibt 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 SHRINKFILE 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 Datenbankmodul ausgewählt, wenn Protokolldateien erstellt oder erweitert werden.

Bewährte Methoden

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

• Ein Verkleinerungsvorgang ist am effektivsten nach einem Vorgang, durch den umfangreicher nicht verwendeter Speicherplatz bereitgestellt 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 bis zu einem gewissen Grad verstärkt. Dies ist ein weiterer Grund dafür, die Datenbank nicht wiederholt zu verkleinern.

• Mehrere Dateien in derselben Datenbank sollten nacheinander und nicht gleichzeitig verkleinert werden. Konflikte in Systemtabellen können Blockierungsverzögerungen verursachen.

Problembehandlung

In diesem Abschnitt wird beschrieben, wie Probleme, die beim Ausführen des DBCC SHRINKFILE-Befehls auftreten können, diagnostiziert und behoben werden.

Die Datei wird nicht verkleinert

Wenn beim Verkleinerungsvorgang kein Fehler auftritt, die Dateigröße jedoch unverändert scheint, überprüfen Sie, ob die Datei über ausreichend freien zu entfernenden Speicherplatz verfügt. Führen Sie dazu eine der folgenden Aktionen aus:

• Führen Sie die folgende Abfrage aus.

  SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
  FROM sys.database_files;
  

• Führen Sie den DBCC SQLPERF-Befehl aus, um den vom Transaktionsprotokoll verwendeten Speicherplatz zurückzugeben.

Falls nicht ausreichend Speicherplatz verfügbar ist, kann die Dateigröße durch den Verkleinerungsvorgang nicht weiter reduziert werden.

In der Regel ist es die Protokolldatei, die scheinbar nicht verkleinert wurde. Gewöhnlich liegt es daran, dass die Protokolldatei nicht abgeschnitten wurde. Sie können das Protokoll abschneiden, indem Sie das Wiederherstellungsmodell der Datenbank auf SIMPLE festlegen oder indem Sie das Protokoll sichern und dann den DBCC SHRINKFILE-Vorgang erneut ausführen.

Der Verkleinerungsvorgang ist blockiert

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. In diesem Fall geben DBCC SHRINKFILE und DBCC SHRINKDATABASE eine Informationsmeldung (5202 für SHRINKDATABASE und 5203 für SHRINKFILE) an das SQL Server-Fehlerprotokoll aus, und zwar in der ersten Stunde alle fünf Minuten und danach einmal pro Stunde. Wenn das Fehlerprotokoll beispielsweise folgende Fehlermeldung enthält, tritt folgender Fehler auf:

DBCC SHRINKFILE for file ID 1 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 Verwaltungssicht sys.dm_tran_active_snapshot_database_transactions einen Wert von 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. Wenn der Verkleinerungsvorgang beendet wird, bleibt der bereits abgeschlossene Teil 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 Datendatei auf eine angegebene Zielgröße

Im folgenden Beispiel wird die Größe der Datendatei DataFile1 in der UserDB-Benutzerdatenbank auf 7 MB verkleinert.

USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO

B.Verkleinern einer Protokolldatei auf eine angegebene Zielgröße

Im folgenden Beispiel wird die Protokolldatei in der AdventureWorks-Datenbank auf 1 MB verkleinert. Damit die Datei mit dem DBCC SHRINKFILE-Befehl verkleinert werden kann, wird die Datei zunächst abgeschnitten, indem das Wiederherstellungsmodell für die Datenbank auf SIMPLE festgelegt wird.

USE AdventureWorks2012;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2012
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2012
SET RECOVERY FULL;
GO

C.Abschneiden einer Datendatei

Im folgenden Beispiel wird die primäre Datendatei in der AdventureWorks-Datenbank abgeschnitten. Die sys.database_files-Katalogsicht wird auf den file_id-Wert für die Datendatei abgefragt.

USE AdventureWorks2012;
GO
SELECT file_id, name
FROM sys.database_files;
GO
DBCC SHRINKFILE (1, TRUNCATEONLY);

D.Leeren einer Datei

Das folgende Beispiel veranschaulicht das Verfahren zum Leeren einer Datei, sodass sie aus der Datenbank entfernt werden kann. Für die Zwecke dieses Beispiels wird zunächst eine Datendatei erstellt, und es wird angenommen, dass die Datei Daten enthält.

USE AdventureWorks2012;
GO
-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2012 
ADD FILE (
    NAME = Test1data,
    FILENAME = 'C:\t1data.ndf',
    SIZE = 5MB
    );
GO
-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO
-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2012
REMOVE FILE Test1data;
GO

Siehe auch

Verweis

ALTER DATABASE (Transact-SQL)

DBCC (Transact-SQL)

DBCC SHRINKDATABASE (Transact-SQL)

FILE_ID (Transact-SQL)

sys.database_files (Transact-SQL)

Konzepte

Verkleinern einer Datei