DBCC SHRINKFILE (Transact-SQL)

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-InstanzSQL-Datenbank in Microsoft Fabric

Reduziert die Größe der angegebenen Daten oder Protokolldateien der aktuellen Datenbank. Damit können Sie Daten von einer Datei in andere Dateien derselben Dateigruppe verschieben. So wird die Datei geleert und die Entfernung der Datenbank ermöglicht. Sie können eine Datei auf weniger als die Größe bei der Erstellung verkleinern, um die minimale Dateigröße auf den neuen Wert zurücksetzen.

Verwenden DBCC SHRINKFILE Sie nur, wenn es notwendig ist, da Verkleinerung eine langjährige und ressourcenintensive Tätigkeit ist.

Transact-SQL-Syntaxkonventionen

Syntax

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

<wait_at_low_priority_option_list> ::=
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list> , <wait_at_low_priority_option>

<wait_at_low_priority_option> ::=
    ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Argumente

file_name

Der logische Name der Datei zu verkleinern.

file_id

Die Identifikationsnummer (ID) der Datei zu verkleinern. 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

Ein Integer stellt die neue Größe der Datei in Megabyte dar. Wenn man target_size auf 0 angibt oder nicht, DBCC SHRINKFILE reduziert sich die Datei auf ihre Erstellungsgröße.

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 angegeben, versucht DBCC SHRINKFILE, die Datei auf target_size zu verkleinern. Verwendete Seiten im Bereich der freizugebenden Datei werden auf freien Speicherplatz in den beibehalten Bereichen der Datei verschoben. Beispielsweise verschiebt ein DBCC SHRINKFILE-Vorgang mit einer 8 von  bei einer Datendatei mit 10 MB alle verwendeten Seiten in den letzten 8 MB der Datei in alle nicht zugeordneten Seiten in den ersten 8 MB der Datei. DBCC SHRINKFILE verkleinert eine Datei nicht über die erforderliche Speichergröße hinaus. Werden beispielsweise 7 MB einer 10 MB großen Datendatei verwendet, verkleinert eine DBCC SHRINKFILE-Anweisung mit einem target_size-Wert von 6 die Datei lediglich auf 7 MB statt auf 6 MB.

Wenn du target_size mit TRUNCATEONLYangibst, könnte es DBCC SHRINKFILE sein, dass am Ende der Datei kein freier Speicherplatz frei wird.

LEERE DATEI

Verlagert alle Daten aus der angegebenen Datei in andere Dateien in derselben Dateigruppe. EMPTYFILE migriert die Daten also aus der angegebenen Datei zu anderen Dateien in derselben Dateigruppe. EMPTYFILE stellt sicher, dass keine neuen Daten zur Datei hinzugefügt werden, obwohl diese Datei nicht schreibgeschützt ist. Du kannst die ALTER DATABASE Anweisung verwenden, um eine Datei zu entfernen. Wenn Sie die ALTER DATABASE Anweisung verwenden, um die Dateigröße zu ändern, wird das Nur-Lese-Flag zurückgesetzt und Daten können hinzugefügt 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. Informationen zum Entfernen eines FILESTREAM-Containers finden Sie im entsprechenden Abschnitt unter ALTER DATABASE Datei- und Dateigruppenoptionen

EMPTYFILEwird in Azure SQL-Datenbank, Azure SQL-Datenbank Hyperscale oder SQL Database in Microsoft Fabric nicht unterstützt.

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 kann nur auf Datendateien angewendet werden. Die Protokolldateien sind nicht betroffen.

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

ABSCHNEIDEN

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.

Wenn target_size mit TRUNCATEONLYdem freien Speicherplatz am Ende der Datei angegeben ist, wird möglicherweise nicht freigegeben.

Die TRUNCATEONLY Option bewegt keine Informationen im Log, entfernt aber inaktive virtuelle Logdateien (VLFs) am Ende der Logdatei. Diese Option wird in FILESTREAM-Dateigruppencontainern nicht unterstützt.

MIT NO_INFOMSGS

Alle Informationsmeldungen werden unterdrückt.

WAIT_AT_LOW_PRIORITY mit Verkleinerungsvorgängen

Gilt für: SQL Server 2022 (16.x) und spätere Versionen, Azure SQL-Datenbank, Azure SQL Managed Instance, SQL Database in Microsoft Fabric

Die Funktion "Warten bei niedriger Priorität" reduziert den Lock-Contention während der Verkleinerungsoperation. Weitere Informationen finden Sie unter Verständnis von Nebenzeitigkeitsproblemen mit DBCC SHRINKFILE.

Dieses Feature ähnelt WAIT_AT_LOW_PRIORITY bei Onlineindexvorgängen, weist aber einige Unterschiede auf.

• Du kannst die ABORT_AFTER_WAIT Option NONEnicht angeben.
• Du kannst die MAX_DURATION Option nicht festlegen. Die Low-Priority-Sperrzeit bei einer Schrumpfoperation beträgt immer eine Minute.

WAIT_AT_LOW_PRIORITY

Wenn ein Verkleinerungsbefehl im Modus WAIT_AT_LOW_PRIORITY ausgeführt wird, werden Abfragen, die Schema-Stabilität ()-Sperrungen aufSch-S den Index Allocation Map (IAM)-Seiten erfordern, durch die Verkleinerungsoperation nicht blockiert. Die Verkleinerungsoperation kann jedoch durch eine Sch-S Sperre auf einer IAM-Seite blockiert werden. Shrink führt nur dann weiter aus, wenn es in der Lage ist, ein Schema modify lock (Sch-M) Lock auf einer IAM-Seite zu erhalten, die es benötigt.

Wenn eine Verkleinerungsoperation im WAIT_AT_LOW_PRIORITY Modus diese Sperre aufgrund einer langlaufenden Abfrage mit einem Sch-S Lock nicht erhalten kann, läuft die Verkleinerungsoperation mit Fehler 49516 ab, zum Beispiel: Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5.

{ ABORT_AFTER_WAIT = [ SELBST | BLOCKER ] }

Gilt für: SQL Server (SQL Server 2022 (16.x und neuere Versionen), Azure SQL-Datenbank, SQL-Datenbank in Microsoft Fabric.

• SELF

  SELF ist die Standardoption. Beenden Sie die gerade ausgeführte Verkleinerungsdatei-Operation, ohne weitere Maßnahmen zu unternehmen.

• BLOCKERS

  Bricht alle Benutzertransaktionen ab, die den Vorgang zum Verkleinern der Datei blockieren, sodass der Vorgang fortgesetzt werden kann. Die BLOCKERS Option erfordert, dass der Login die ODER-Berechtigung ALTER ANY CONNECTIONKILL DATABASE CONNECTION hat.

Resultset

In der folgenden Tabelle sind die Resultsetspalten beschrieben.

Hinweise

DBCC SHRINKFILE gilt für die Dateien der aktuellen Datenbank. Weitere Informationen zur Änderung der aktuellen Datenbank finden Sie unter USE.

Sie können den DBCC SHRINKFILE-Vorgang jederzeit beenden, und alle abgeschlossenen Vorgänge bleiben erhalten. Wenn Sie den Parameter EMPTYFILE verwenden und den Vorgang abbrechen, wird die Datei nicht markiert, um zu verhindern, dass zusätzliche Daten hinzugefügt werden.

Andere Benutzer können während der Dateiverkleinerung in der Datenbank arbeiten – die Datenbank muss nicht im Einzelbenutzermodus sein. Um die Systemdatenbanken zu verkleinern, muss auch SQL Server nicht im Einzelbenutzermodus ausgeführt werden.

Bekannte Probleme

Gilt für: SQL Server, Azure SQL-Datenbank, SQL database in Microsoft Fabric, Azure SQL Managed Instance, Azure Synapse Analytics dedicated SQL pool

• In SQL Server-Versionen vor SQL Server 2025 (17.x) können die Seiten, die von Spaltentypen großer Objekte (LOB) (varbinary(max),varchar(max) und nvarchar(max)) in komprimierten Spaltenspeichern-Segmenten verwendet werden, nicht von DBCC SHRINKDATABASE und DBCC SHRINKFILEverschoben werden. Weitere Informationen finden Sie unter Neuigkeiten in Columnstore-Indizes.

Grundlegendes zu Parallelitätsproblemen mit DBCC SHRINKFILE

Die Befehle zur Verkleinerungsdatenbank und zur Verkleinerung der Dateien können zu Nebenläufigkeitsproblemen führen, insbesondere bei aktiver Wartung wie dem Neuaufbau von Indizes oder in stark frequentierten Online-Transaktionsverarbeitungsumgebungen (OLTP).

Beispielsweise könnte eine Benutzeranfrage eine Schema-Stabilitätssperre (Sch-S) auf einer Index Allocation Map (IAM)-Seite erhalten und diese bis zum Abschluss halten. Beim Versuch, während der regulären Nutzung Speicherplatz zurückzugewinnen, erfordern Verkleinerungs- und Dateiverkleinerungsoperationen eine Schema-Modifikationssperre (Sch-M) beim Verschieben oder Löschen von IAM-Seiten, wodurch die Sch-S für Benutzerabfragen benötigten Sperren blockiert werden. Daher können langlaufende Abfragen eine Verkleinerungsoperation blockieren. Das bedeutet auch, dass jede neue Abfrage, die eine Sch-S Sperre auf einer IAM-Seite erfordert, hinter der Verkleinerungsoperation in die Warteschlange gerückt werden kann, was dieses Nebenläufigkeitsproblem weiter verschärft.

Die in SQL Server 2022 (16.x) eingeführte Funktion "Warten bei niedriger Priorität" für Verkleinerungsoperationen behebt dieses Problem, indem die Schema-Modifikationssperre auf IAM-Seiten im Modus WAIT_AT_LOW_PRIORITY angewendet wird. Weitere Informationen finden Sie unter WAIT_AT_LOW_PRIORITY mit Verkleinerungsvorgängen.

Weitere Informationen zu Sch-S Sperren finden Sch-M Sie unter Transaktionssperrung und Zeilenversionierung.

Verkleinern einer Protokolldatei

Für Protokolldateien verwendet Datenbank-Enginetarget_size, um die Zielgröße des gesamten Protokolls zu berechnen. Daher ist target_size der freie Speicherplatz des Protokolls nach dem Verkleinern. Die Zielgröße des gesamten Protokolls wird dann in die Zielgröße der einzelnen Protokolldateien 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 das Datenbank-Engine 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 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. Datenbank-Engine wählt dynamisch die Größe des virtuellen Dateiprotokolls, 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 Datenbankdatei wiederholt verkleinern und feststellen, dass die Datenbankgröße wieder zunimmt, deutet das darauf hin, dass der freie Speicherplatz für normale Vorgänge benötigt wird. In diesen Fällen ist das wiederholte Verkleinern der Datenbankdatei kontraproduktiv. Das Dateiwachstum, das notwendig ist, um neuen Speicherplatz nach der Verkleinerung zuzuweisen, kann die Leistung beeinträchtigen.

• Eine Verkleinerungsoperation bewahrt den Fragmentierungszustand der Indizes in der Datenbank nicht und kann die Indexfragmentierung erhöhen, was den Lese-I/O-Durchsatz für Abfragen mit großen Scans verringern könnte.

• Wenn du die Datendateien einer großen Datenbank verkleinern musst, solltest du das PowerShell-Skript ShrinkDriver in Betracht ziehen. Das Skript automatisiert und vereinfacht den Verkleinerungsprozess, sodass er zu einer einzigen, beobachtbaren und wiederverpfändbaren Operation wird. Das Skript schrumpft mehrere Dateien parallel, versucht es bei Unterbrechungen erneut und liefert detaillierte Statusberichte, während es läuft.

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 sich die Dateigröße nach einer fehlerfreien Verkleinerungsoperation nicht ändert, versuchen Sie die folgenden Schritte, um sicherzustellen, dass die Datei genügend freien Speicherplatz hat:

• 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;
  

• Wenn Sie die Transaktionsprotokolldatei verkleinern möchten, verwenden Sie die sys.dm_db_log_space_usage Dynamic Management View (DMV), um den im Transaktionsprotokoll verwendeten Speicherplatz zu sehen.

Die Verkleinerungsoperation kann die Dateigröße nicht weiter verkleinern, wenn nicht genügend freier Speicherplatz vorhanden ist.

Ein häufiger Grund, warum eine Transaktionsprotokolldatei nicht schrumpft, ist das Fehlen regelmäßiger Transaktionsprotokoll-Backups. Wenn Sie das Protokoll kürzen möchten, sichern Sie das Transaktionsprotokoll, und führen Sie dann den DBCC SHRINKFILE-Vorgang erneut aus. Wenn keine Punkt-in-Zeit-Wiederherstellung erforderlich ist, sollten Sie die Wiederherstellungsmodelle (SQL Server) in Betracht ziehen, um Wachstum von Logdateien zu vermeiden.

Der Verkleinerungsvorgang ist blockiert

Eine Transaktion, die unter einer auf Zeilenversionsverwaltung basierenden Isolationsstufe ausgeführt wird, kann Verkleinerungsvorgänge blockieren. 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 weiter verkleinert werden. Wenn diese Blockierung auftritt, wird von den DBCC SHRINKFILE- und DBCC SHRINKDATABASE-Vorgängen eine Informationsmeldung (5202 für SHRINKDATABASE und 5203 für SHRINKFILE) an das SQL Server-Fehlerprotokoll ausgegeben. Diese Meldung wird in der ersten Stunde alle fünf Minuten und dann jede Stunde protokolliert. Zum Beispiel:

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.

Diese Meldung bedeutet, dass Momentaufnahmentransaktionen mit Zeitstempeln, die älter als 109 sind (die letzte Transaktion, die der Verkleinerungsvorgang abgeschlossen hat), den Verkleinerungsvorgang blockieren. 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 entweder die Ansichtsspalte transaction_sequence_num oder first_snapshot_sequence_num eine Zahl enthält, die kleiner ist als die zuletzt abgeschlossene Transaktion (109) eines Verkleinerungsvorgangs ist, wartet der Verkleinerungsvorgang darauf, dass diese Transaktionen abgeschlossen sind.

Um das Problem zu lösen, führen Sie einen der folgenden Schritte durch:

• 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

Die Codebeispiele in diesem Artikel verwenden die AdventureWorks2025- oder AdventureWorksDW2025 Beispieldatenbank, die Sie von der Microsoft SQL Server Samples and Community Projects Homepage herunterladen können.

Ein. 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 AdventureWorks2025-Datenbank auf 1 MB verkleinert. Damit der DBCC SHRINKFILE Befehl die Datei verkleinern kann, wird die Datei zunächst abgeschnitten, indem das Datenbankwiederherstellungsmodell auf SIMPLEgesetzt wird.

USE AdventureWorks2025;
GO

-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY SIMPLE;
GO

-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2025_Log, 1);
GO

-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY FULL;
GO

C. Abschneiden einer Datendatei

Im folgenden Beispiel wird die primäre Datendatei in der AdventureWorks2025-Datenbank abgeschnitten. Die sys.database_files-Katalogsicht wird abgefragt, um den file_id-Wert für die Datendatei zu erhalten.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (1, TRUNCATEONLY);

D: Leeren einer Datei

Das folgende Beispiel veranschaulicht das Leeren einer Datei, sodass sie aus der Datenbank entfernt werden kann. Für dieses Beispiel wird zunächst eine Datei mit Daten erstellt.

USE AdventureWorks2025;
GO

-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2025
    ADD FILE (NAME = Test1data, FILENAME = 'C:\t1data.ndf', SIZE = 5 MB);
GO

-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO

-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2025
     REMOVE FILE Test1data;
GO

E. Verkleinern einer Datenbankdatei mit WAIT_AT_LOW_PRIORITY

Im folgenden Beispiel wird versucht, eine Datendatei in der aktuellen Benutzerdatenbank auf 1 MB zu verkleinern. Die Katalogsicht sys.database_files wird abgefragt, um die Datei-ID (file_id) der Datendatei zu erhalten (in diesem Beispiel: file_id 5). Sollte innerhalb einer Minute keine Sperre abgerufen werden können, wird der Verkleinerungsvorgang abgebrochen.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Zugehöriger Inhalt

• Verkleinern einer Datenbank
• Verkleinern einer Datei
• DBCC SHRINKDATABASE (Transact-SQL)
• Überlegungen zu den Einstellungen für automatische Vergrößerung und Verkleinerung in SQL Server
• Datenbankdateien und Dateigruppen
• sys.database_files (Transact-SQL)
• sys.databases (Transact-SQL)
• FILE_ID (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Verwalten von Dateispeicherplatz für Datenbanken in Azure SQL-Datenbank