DBCC SHRINKFILE (Transact-SQL)
van toepassing op:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Hiermee verkleint u de opgegeven gegevens of logboekbestanden van de huidige database. U kunt het gebruiken om gegevens van het ene bestand naar andere bestanden in dezelfde bestandsgroep te verplaatsen, waardoor het bestand wordt geleegd en de database kan worden verwijderd. U kunt een bestand verkleinen tot kleiner dan de grootte van het bestand bij het maken en de minimale bestandsgrootte opnieuw instellen op de nieuwe waarde. Gebruik DBCC SHRINKFILE alleen wanneer dat nodig is.
Notitie
Verkleiningsbewerkingen mogen niet worden beschouwd als een normale onderhoudsbewerking. Voor gegevens- en logboekbestanden die groeien als gevolg van regelmatige, terugkerende bedrijfsbewerkingen zijn geen verkleiningsbewerkingen vereist.
Transact-SQL syntaxisconventies
Syntaxis
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 }
Argumenten
file_name
De logische naam van het bestand dat verkleind moet worden.
file_id
Het ID-nummer van het bestand dat verkleind moet worden. Als u een bestands-id wilt ophalen, gebruikt u de FILE_IDEX systeemfunctie of voert u een query uit op de sys.database_files catalogusweergave in de huidige database.
doelgrootte
Een geheel getal dat de nieuwe megabytegrootte van het bestand vertegenwoordigt. Als dit niet is gespecificeerd of 0, wordt DBCC SHRINKFILE
teruggebracht tot de initiële bestandsgrootte.
U kunt de standaardgrootte van een leeg bestand verkleinen met behulp van DBCC SHRINKFILE <target_size>
. Als u bijvoorbeeld een bestand van 5 MB maakt en het bestand vervolgens verkleint tot 3 MB terwijl het bestand nog steeds leeg is, is de standaardbestandsgrootte ingesteld op 3 MB. Dit geldt alleen voor lege bestanden die nooit gegevens bevatten.
Deze optie wordt niet ondersteund voor FILESTREAM-bestandsgroepcontainers.
Indien opgegeven, probeert DBCC SHRINKFILE
het bestand te verkleinen naar target_size. Gebruikte pagina's in het gebied van het bestand die moeten worden vrijgemaakt, worden verplaatst naar vrije ruimte in de bewaarde gebieden van het bestand. Met een gegevensbestand van 10 MB verplaatst een DBCC SHRINKFILE
-bewerking met een 8
target_size alle gebruikte pagina's in de laatste 2 MB van het bestand naar niet-toegewezen pagina's in de eerste 8 MB van het bestand.
DBCC SHRINKFILE
een bestand niet kleiner maakt dan de benodigde opgeslagen gegevensgrootte. Als bijvoorbeeld 7 MB van een gegevensbestand van 10 MB wordt gebruikt, wordt een DBCC SHRINKFILE
instructie met een target_size van 6 het bestand verkleind tot slechts 7 MB, niet 6 MB.
EMPTYFILE
Hiermee worden alle gegevens van het opgegeven bestand naar andere bestanden in de dezelfde bestandsgroep gemigreerd. Met andere woorden, EMPTYFILE
gegevens migreert van een opgegeven bestand naar andere bestanden in dezelfde bestandsgroep.
EMPTYFILE
verzekert u dat er geen nieuwe gegevens aan het bestand worden toegevoegd, ondanks dat dit bestand niet alleen-lezen is. U kunt de instructie ALTER DATABASE gebruiken om een bestand te verwijderen. Als u de instructie ALTER DATABASE gebruikt om de bestandsgrootte te wijzigen, wordt de alleen-lezen vlag opnieuw ingesteld en kunnen gegevens worden toegevoegd.
Voor FILESTREAM-bestandsgroepcontainers kunt u geen ALTER DATABASE
gebruiken om een bestand te verwijderen totdat filestream garbagecollection is uitgevoerd en alle onnodige bestandsgroepcontainerbestanden die EMPTYFILE
naar een andere container heeft gekopieerd, verwijderd. Zie sp_filestream_force_garbage_collectionvoor meer informatie. Zie de bijbehorende sectie in ALTER DATABASE File and Filegroup Options (Transact-SQL) voor meer informatie over het verwijderen van een FILESTREAM-container
EMPTYFILE
wordt niet ondersteund in Azure SQL Database of Azure SQL Database Hyperscale.
NOTRUNCATE
Hiermee verplaatst u toegewezen pagina's van het einde van een gegevensbestand naar niet-toegewezen pagina's aan de voorzijde van een bestand met of zonder target_percentop te geven. De vrije ruimte aan het einde van het bestand wordt niet teruggezet naar het besturingssysteem en de fysieke grootte van het bestand verandert niet. Als NOTRUNCATE
is opgegeven, wordt het bestand daarom niet verkleind.
NOTRUNCATE
is alleen van toepassing op gegevensbestanden. De logboekbestanden worden niet beïnvloed.
Deze optie wordt niet ondersteund voor FILESTREAM-bestandsgroepcontainers.
TRUNCATEONLY
Maakt alle vrije ruimte aan het einde van het bestand vrij voor het besturingssysteem, maar voert geen paginaverplaatsing binnen het bestand uit. Het gegevensbestand wordt alleen verkleind tot het laatst toegewezen gedeelte.
target_size wordt genegeerd als deze is opgegeven met TRUNCATEONLY
.
De optie TRUNCATEONLY
verplaatst geen gegevens in het logboek, maar verwijdert wel inactieve VLF's aan het einde van het logboekbestand. Deze optie wordt niet ondersteund voor FILESTREAM-bestandsgroepcontainers.
Gebruik NO_INFOMSGS
Onderdrukt alle informatieve berichten.
WAIT_AT_LOW_PRIORITY met verkleiningsbewerkingen
Van toepassing op: SQL Server 2022 (16.x) en latere versies, Azure SQL Database, Azure SQL Managed Instance
De functie wachten met een lage prioriteit vermindert conflicten met de vergrendeling. Voor meer informatie, zie Begrip van gelijktijdigheidsproblemen met DBCC SHRINKDATABASE.
Deze functie is vergelijkbaar met de WAIT_AT_LOW_PRIORITY met online indexbewerkingen, met enkele verschillen.
- U kunt ABORT_AFTER_WAIT optie GEEN opgeven.
WACHTEN_OP_LAGE_PRIORITEIT
van toepassing op: SQL Server (SQL Server 2022 (16.x) en hoger) en Azure SQL Database.
Wanneer een opdracht verkleinen wordt uitgevoerd in WAIT_AT_LOW_PRIORITY modus, worden nieuwe query's waarvoor schemastabiliteit (Sch-S) is vereist, niet geblokkeerd door de wachtbewerking voor verkleinen totdat de verkleiningsbewerking stopt met wachten en wordt gestart met uitvoeren. De verkleiningsbewerking wordt uitgevoerd wanneer er een schemawijzigingsvergrendeling (Sch-M) kan worden verkregen. Als een nieuwe verkleiningsbewerking in de modus WAIT_AT_LOW_PRIORITY geen vergrendeling kan verkrijgen vanwege een langdurige query, zal de verkleiningsbewerking standaard na 1 minuut een time-out bereiken en geruisloos stoppen.
Als een nieuwe verkleiningsbewerking in de modus WAIT_AT_LOW_PRIORITY geen vergrendeling kan verkrijgen vanwege een langlopende query, raakt de verkleiningsbewerking standaard na 1 minuut in een time-out en sluit de bewerking stil af. Dit gebeurt als de verkleiningsbewerking de Sch-M-vergrendeling niet kan verkrijgen vanwege gelijktijdige query's met Sch-S-vergrendelingen. Wanneer er een time-out optreedt, wordt fout 49516 verzonden naar het SQL Server-foutenlogboek, bijvoorbeeld: 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
. Voer de verkleinbewerking opnieuw uit in WAIT_AT_LOW_PRIORITY
-modus.
ABORT_AFTER_WAIT = [ SELF | BLOCKERS ]
van toepassing op: SQL Server (SQL Server 2022 (16.x) en hoger) en Azure SQL Database.
ZELF
Sluit de verkleiningsbestandsbewerking die momenteel wordt uitgevoerd zonder actie te ondernemen.
BLOKKEREN
Alle gebruikerstransacties beëindigen die de bewerking voor het verkleinen van bestanden blokkeren, zodat de bewerking kan worden voortgezet. De optie BLOCKERS vereist dat aanmeldingen de machtiging ALTER ANY CONNECTION moeten hebben.
Resultaatset
In de volgende tabel worden kolommen voor resultatensets beschreven.
Kolomnaam | Beschrijving |
---|---|
DbId |
Databaseidentificatienummer van het bestand dat de database-engine probeerde te verkleinen. |
FileId |
Het bestandsidentificatienummer van het bestand dat de database-engine probeerde te verkleinen. |
CurrentSize |
Het aantal pagina's van 8 kB dat het bestand momenteel in beslag neemt. |
MinimumSize |
Het minimale aantal 8-kB-pagina's dat het bestand kan innemen. Dit getal komt overeen met de minimale grootte of oorspronkelijk gemaakte grootte van een bestand. |
UsedPages |
Het aantal pagina's van 8 kB dat momenteel door het bestand wordt gebruikt. |
EstimatedPages |
Het aantal 8-KB pagina's waarnaar de database-engine schat dat het bestand kan worden verkleind. |
Opmerkingen
DBCC SHRINKFILE
is van toepassing op de bestanden van de huidige database. Zie USE (Transact-SQL)voor meer informatie over het wijzigen van de huidige database.
U kunt DBCC SHRINKFILE
bewerkingen op elk moment stoppen en alle voltooide werkzaamheden worden bewaard. Als u de parameter EMPTYFILE
gebruikt en de bewerking annuleert, wordt het bestand niet gemarkeerd om te voorkomen dat extra gegevens worden toegevoegd.
Wanneer een DBCC SHRINKFILE
-bewerking mislukt, wordt er een fout gegenereerd.
Andere gebruikers kunnen tijdens het verkleinen van bestanden in de database werken; de database hoeft zich niet in de modus voor één gebruiker te bevinden. U hoeft het exemplaar van SQL Server niet uit te voeren in de modus voor één gebruiker om de systeemdatabases te verkleinen.
Wanneer deze is opgegeven met WAIT_AT_LOW_PRIORITY, wacht de Sch-M-vergrendelingsaanvraag van de verkleinbewerking met een lage prioriteit bij het uitvoeren van de opdracht gedurende 1 minuut. Als de bewerking voor de duur wordt geblokkeerd, wordt de opgegeven ABORT_AFTER_WAIT actie uitgevoerd.
Bekende problemen
van toepassing op: SQL Server, Azure SQL Database, Azure SQL Managed Instance, toegewezen SQL-pool van Azure Synapse Analytics
- Op dit moment worden lob-kolomtypen (varbinary(max), varchar(max)en nvarchar(max)) in gecomprimeerde columnstore-segmenten niet beïnvloed door
DBCC SHRINKDATABASE
enDBCC SHRINKFILE
.
Begrijp gelijktijdigheidsproblemen met DBCC SHRINKFILE
De opdrachten voor het verkleinen van de database en het verkleinen van bestanden kunnen leiden tot gelijktijdigheidsproblemen, met name bij actief onderhoud, zoals het opnieuw opbouwen van indexen of in drukke OLTP-omgevingen. Wanneer uw toepassing query's uitvoert op databasetabellen, verkrijgen en onderhouden deze query's een stabiliteitsvergrendeling voor schema's (Sch-S) totdat de query's hun bewerkingen voltooien. Bij een poging om ruimte vrij te maken tijdens normaal gebruik, vereisen database- en bestandinkrimpen-bewerkingen momenteel een schemawijzigingsvergrendeling (Sch-M) bij het verplaatsen of verwijderen van IAM-pagina's (Index Allocation Map), wat de Sch-S-vergrendelingen blokkeert die nodig zijn voor gebruikersquery's. Als gevolg hiervan blokkeren langlopende query's een verkleiningsbewerking totdat de query's zijn voltooid. Dit betekent dat nieuwe query's waarvoor Sch-S-vergrendelingen vereist zijn, ook in de wachtrij worden geplaatst achter de beperkte bewerking in uitvoering en ook worden geblokkeerd, wat dit gelijktijdigheidsprobleem verder verergert. Dit kan aanzienlijk van invloed zijn op de prestaties van de toepassingsquery en kan ook problemen veroorzaken bij het voltooien van het benodigde onderhoud om databasebestanden te verkleinen. Geïntroduceerd in SQL Server 2022 (16.x), de functie verkleinen met lage prioriteit lost dit probleem op door een schemawijzigingsvergrendeling in WAIT_AT_LOW_PRIORITY
modus te nemen. Voor meer informatie, zie WAIT_AT_LOW_PRIORITY bij verkleiningsbewerkingen.
Zie voor meer informatie over Sch-S en Sch-M vergrendelingen handleiding voor transactievergrendeling en het versiebeheer van rijen.
Een logboekbestand verkleinen
Voor logboekbestanden gebruikt de database-engine target_size om de doelgrootte van het hele logboek te berekenen. Daarom is target_size de vrije ruimte die in het logboek overblijft na de verkleiningsbewerking. De doelgrootte van het hele logboek wordt vervolgens omgezet in de doelgrootte van elk logboekbestand.
DBCC SHRINKFILE
probeert elk fysiek logboekbestand onmiddellijk te verkleinen tot de doelgrootte. Als een deel van het logische logboek zich echter in de virtuele logboeken bevindt die buiten de doelgrootte liggen, maakt de database-engine zoveel mogelijk ruimte vrij en geeft het vervolgens een informatief bericht uit. In het bericht wordt beschreven welke acties nodig zijn om het logische logboek uit de virtuele logboeken aan het einde van het bestand te verplaatsen. Nadat de acties zijn uitgevoerd, kan DBCC SHRINKFILE
worden gebruikt om de resterende ruimte vrij te maken.
Omdat een logboekbestand alleen kan worden verkleind tot de grens van een virtueel logboekbestand, is het verkleinen van een logboekbestand tot een grootte kleiner dan de grootte van een virtueel logboekbestand mogelijk, zelfs niet als het niet wordt gebruikt. De database-engine kiest dynamisch de grootte van het virtuele bestandslogboek wanneer logboekbestanden worden gemaakt of uitgebreid.
Beste werkwijzen
Houd rekening met de volgende informatie wanneer u van plan bent een bestand te verkleinen:
Een verkleiningsbewerking is het meest effectief na een bewerking waarmee een grote hoeveelheid ongebruikte ruimte wordt gemaakt, zoals een afkappende tabel of een tabelvervalbewerking.
De meeste databases vereisen dat er vrije ruimte beschikbaar is voor normale dagelijkse bewerkingen. Als u een databasebestand herhaaldelijk verkleint en merkt dat de databasegrootte opnieuw toeneemt, geeft dit aan dat de vrije ruimte vereist is voor normale bewerkingen. In deze gevallen is het herhaaldelijk verkleinen van het databasebestand een verspilde bewerking. Gebeurtenissen die noodzakelijk zijn om het databasebestand te vergroten, belemmeren de prestaties.
Bij een verkleiningsbewerking blijft de fragmentatiestatus van indexen in de database niet behouden en neemt de fragmentatie over het algemeen tot een bepaalde mate toe. Deze fragmentatie is een andere reden om de database niet herhaaldelijk te verkleinen.
Meerdere bestanden in dezelfde database opeenvolgend verkleinen in plaats van gelijktijdig. Conflicten in systeemtabellen kunnen blokkades veroorzaken en tot vertragingen leiden.
Problemen oplossen
In deze sectie wordt beschreven hoe u problemen kunt vaststellen en corrigeren die kunnen optreden bij het uitvoeren van de opdracht DBCC SHRINKFILE
.
Het bestand wordt niet verkleind
Als de bestandsgrootte niet wordt gewijzigd na een foutloze verkleiningsbewerking, probeert u het volgende om te controleren of het bestand voldoende vrije ruimte heeft:
- Voer de volgende query uit.
SELECT name
, size / 128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS AvailableSpaceInMB
FROM sys.database_files;
- Voer de opdracht DBCC SQLPERF uit om de ruimte te retourneren die in het transactielogboek wordt gebruikt.
De verkleiningsbewerking kan de bestandsgrootte niet verder verkleinen als er onvoldoende vrije ruimte beschikbaar is.
Meestal is het het logboekbestand dat niet kleiner lijkt te worden, meestal het resultaat van een logboekbestand dat niet is afgekapt door een normale back-up van het transactielogboek. Als u het logboek wilt afkappen, maakt u een back-up van het transactielogboek en voert u de DBCC SHRINKFILE
bewerking opnieuw uit. Als herstel naar een bepaald tijdstip niet vereist is, kunt u het SIMPLE-herstelmodel voor databasesoverwegen.
De verkleiningsbewerking is geblokkeerd
Een transactie die wordt uitgevoerd onder een isolatieniveau op basis van rijversies kan verkleiningsbewerkingen blokkeren. Als een grote verwijderbewerking wordt uitgevoerd onder een isolatieniveau op basis van rijversiebeheer en er een DBCC SHRINKDATABASE
-bewerking plaatsvindt, wacht de verkleiningsbewerking totdat de verwijdering is voltooid voordat verder gegaan wordt. Wanneer deze blokkering plaatsvindt, worden in DBCC SHRINKFILE
en DBCC SHRINKDATABASE
bewerkingen een informatief bericht (5202 voor SHRINKDATABASE
en 5203 voor SHRINKFILE
) afgedrukt naar het SQL Server-foutenlogboek. Dit bericht wordt om de vijf minuten in het eerste uur en vervolgens elk uur geregistreerd. Bijvoorbeeld:
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.
Dit bericht betekent dat momentopnametransacties met tijdstempels die ouder zijn dan 109 (de laatste transactie die de verkleiningsbewerking heeft voltooid) de verkleiningsbewerking blokkeren. Het geeft ook aan dat de kolommen transaction_sequence_num
of first_snapshot_sequence_num
in de dynamische beheerweergave sys.dm_tran_active_snapshot_database_transactions een waarde van 15 bevatten. Als de kolom transaction_sequence_num
of first_snapshot_sequence_num
weergave een getal bevat dat kleiner is dan de laatste voltooide transactie van een verkleiningsbewerking (109), wacht de verkleiningsbewerking totdat deze transacties zijn voltooid.
U kunt een van de volgende taken uitvoeren om het probleem op te lossen:
- Beëindig de transactie die de verkleiningsbewerking blokkeert.
- De verkleiningsbewerking beëindigen. Voltooid werk wordt bewaard als de verkleiningsbewerking eindigt.
- Doe niets en laat de verkleiningsbewerking wachten totdat de blokkeringstransactie is voltooid.
Machtigingen
Vereist lidmaatschap van de sysadmin vaste serverfunctie of de db_owner vaste databaserol.
Voorbeelden
Een. Een gegevensbestand verkleinen tot een opgegeven doelgrootte
In het volgende voorbeeld wordt de grootte van een gegevensbestand met de naam DataFile1
in de UserDB
gebruikersdatabase verkleind tot 7 MB.
USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO
B. Een logboekbestand verkleinen tot een opgegeven doelgrootte
In het volgende voorbeeld wordt het logboekbestand in de AdventureWorks2022
-database verkleind tot 1 MB. Om de DBCC SHRINKFILE
-opdracht het bestand te laten verkleinen, wordt het bestand eerst ingekort door het databaseterugzetmodel in te stellen op SIMPLE.
USE AdventureWorks2022;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2022
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2022_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2022
SET RECOVERY FULL;
GO
C. Een gegevensbestand afkappen
In het volgende voorbeeld wordt het primaire gegevensbestand in de AdventureWorks2022
-database afgekapt. De sys.database_files
catalogusweergave wordt opgevraagd om de file_id
van het gegevensbestand te verkrijgen.
USE AdventureWorks2022;
GO
SELECT file_id, name
FROM sys.database_files;
GO
DBCC SHRINKFILE (1, TRUNCATEONLY);
D. Een bestand leegmaken
In het volgende voorbeeld ziet u hoe u een bestand leeg maakt, zodat het uit de database kan worden verwijderd. Voor de doeleinden van dit voorbeeld wordt eerst een gegevensbestand gemaakt en bevat deze gegevens.
USE AdventureWorks2022;
GO
-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2022
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 AdventureWorks2022
REMOVE FILE Test1data;
GO
E. Een databasebestand verkleinen met WAIT_AT_LOW_PRIORITY
In het volgende voorbeeld wordt geprobeerd de grootte van een gegevensbestand in de huidige gebruikersdatabase te verkleinen tot 1 MB. De sys.database_files
catalogusweergave wordt opgevraagd om de file_id
van het gegevensbestand op te halen, in dit voorbeeld file_id
5. Als een vergrendeling niet binnen één minuut kan worden verkregen, wordt de verkleiningsbewerking afgebroken.
USE AdventureWorks2022;
GO
SELECT file_id, name
FROM sys.database_files;
GO
DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);
Verwante inhoud
- een database verkleinen
- een bestand verkleinen
- DBCC SHRINKDATABASE (Transact-SQL)
- Overwegingen voor de instellingen voor automatisch vergroten en automatisch verkleinen in SQL Server
- databasebestanden en bestandsgroepen
- sys.database_files (Transact-SQL)
- sys.databases (Transact-SQL)
- FILE_ID (Transact-SQL)
- ALTER DATABASE (Transact-SQL)