DBCC KRIMPEN database (Transact-SQL)

van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL-database in Microsoft Fabric

Hiermee verkleint u de grootte van de gegevens en logboekbestanden in de opgegeven database.

Beschouw shrink operations niet als een regulier onderhoudswerk. Voor gegevens- en logboekbestanden die worden vergroot vanwege regelmatige, terugkerende zakelijke activiteiten, zijn geen verkleiningsbewerkingen vereist.

Transact-SQL syntaxisconventies

Syntaxis

Syntaxis voor SQL Server:

DBCC SHRINKDATABASE
( database_name | database_id | 0
     [ , target_percent ]
     [ , { 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 }

Syntaxis voor Azure Synapse Analytics:

DBCC SHRINKDATABASE
( database_name
     [ , target_percent ]
)
[ WITH NO_INFOMSGS ]

Argumenten

{ database_name | database_id | 0 }

De naam of ID van de database moet verkleinen. Een waarde van 0 geeft de huidige database aan.

target_percent

Het percentage vrije ruimte dat in het databasebestand moet blijven nadat de verkleiningsoperatie is voltooid.

Als je target_percent specificeert met TRUNCATEONLY, kan de verkleiningsoperatie geen vrije ruimte vrijmaken aan het einde van het bestand.

NIET AFGEKAPT

Hiermee verplaatst u toegewezen pagina's van het einde van het bestand naar niet-toegewezen pagina's aan de voorkant van het bestand. Met deze actie worden de gegevens in het bestand gecomprimeerd. target_percent is optioneel. Azure Synapse Analytics biedt geen ondersteuning voor deze optie.

De vrije ruimte aan het einde van het bestand wordt niet teruggezet naar het besturingssysteem en de fysieke grootte van het bestand verandert niet. De database lijkt dus niet te krimpen wanneer u NOTRUNCATEopgeeft.

NOTRUNCATE geldt alleen voor databestanden. NOTRUNCATE heeft geen invloed op het logboekbestand.

TRUNCATEONLY

Alle vrije ruimte aan het einde van het bestand wordt vrijgegeven aan het besturingssysteem. Verplaatst geen pagina's in het bestand. Het gegevensbestand wordt alleen verkleind tot de laatst toegewezen omvang. Azure Synapse Analytics biedt geen ondersteuning voor deze optie.

Als je target_percent specificeert met TRUNCATEONLY, kan de verkleiningsoperatie geen vrije ruimte vrijmaken aan het einde van het bestand.

MET NO_INFOMSGS

Onderdrukt alle informatieve berichten met ernstniveaus van 0 tot en met 10.

WAIT_AT_LOW_PRIORITY met verkleiningsbewerkingen

Van toepassing op: SQL Server 2022 (16.x) en latere versies, Azure SQL Database, Azure SQL Managed Instance, SQL-database in Microsoft Fabric

De functie 'wacht bij lage prioriteit' vermindert de vergrendelingscongretie tijdens de krimpoperatie. Zie Informatie over gelijktijdigheidsproblemen met DBCC SHRINKDATABASE voor meer informatie.

Deze functie is vergelijkbaar met de WAIT_AT_LOW_PRIORITY met online indexbewerkingen, met enkele verschillen.

• Je kunt geen optie NONEspecificerenABORT_AFTER_WAIT.
• Je kunt de MAX_DURATION optie niet instellen. De timeout voor een verkleiningsoperatie voor een lage prioriteit is altijd één minuut.

WACHTEN_OP_LAGE_PRIORITEIT

Wanneer een shrink-commando in WAIT_AT_LOW_PRIORITY modus wordt uitgevoerd, worden queries die schema stability (Sch-S) vergrendelingen vereisen op de Index Allocation Map (IAM)-pagina's niet geblokkeerd door de shrink-operatie. De verkleiningsoperatie kan echter worden geblokkeerd door een Sch-S lock op een IAM-pagina. Shrink blijft alleen uitvoeren wanneer het een schema modify lock () lock kanSch-M verkrijgen op een IAM-pagina die het vereist.

Als een verkleiningsoperatie in WAIT_AT_LOW_PRIORITY modus deze vergrendeling niet kan verkrijgen vanwege een langlopende query met een Sch-S vergrendeling, loopt de verkleiningsoperatie uit met fout 49516, 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.

{ ABORT_AFTER_WAIT = [ ZELF | BLOKKEERDERS ] }

• SELF

  SELF is de standaardoptie. Verlaat de momenteel uitgevoerde verkleiningsdatabase-operatie zonder verdere actie te ondernemen.

• BLOCKERS

  Alle gebruikerstransacties beëindigen die de bewerking voor het verkleinen van bestanden blokkeren, zodat de bewerking kan worden voortgezet. De BLOCKERS optie vereist dat de login de of KILL DATABASE CONNECTION toestemming ALTER ANY CONNECTION heeft.

Resultaatset

In de volgende tabel worden de kolommen in de resultatenset beschreven.

Opmerkingen

Als u alle gegevens en logboekbestanden voor een specifieke database wilt verkleinen, voert u de opdracht DBCC SHRINKDATABASE uit. Als u één gegevens- of logboekbestand tegelijk voor een specifieke database wilt verkleinen, voert u de OPDRACHT DBCC SHRINKFILE uit.

Als u de huidige hoeveelheid vrije (niet-toegewezen) ruimte in de database wilt weergeven, voert u sp_spaceused uit.

DBCC SHRINKDATABASE bewerkingen kunnen op elk moment in het proces worden gestopt en wordt voltooid werk bewaard.

De database kan niet kleiner zijn dan de geconfigureerde minimale grootte van de database. U geeft de minimale grootte op wanneer de database oorspronkelijk is gemaakt. Of de minimale grootte kan de laatste grootte zijn die expliciet is ingesteld met behulp van een bewerking voor het wijzigen van de bestandsgrootte. Bewerkingen zoals DBCC SHRINKFILE of ALTER DATABASE zijn voorbeelden van wijzigingen in de bestandsgrootte.

Overweeg dat een database oorspronkelijk is gemaakt met een grootte van 10 MB. Vervolgens groeit het tot 100 MB. De kleinste database kan worden verkleind tot 10 MB, zelfs als alle gegevens in de database zijn verwijderd.

Je kunt de NOTRUNCATE optie of de optie specificeren TRUNCATEONLY wanneer je het uitvoert DBCC SHRINKDATABASE. Als je geen van beide opties specificeert, is het resultaat hetzelfde als wanneer je een DBCC SHRINKDATABASE bewerking uitvoert met NOTRUNCATE gevolgd door een DBCC SHRINKDATABASE bewerking met TRUNCATEONLY.

De shrunk-database hoeft zich niet in de modus voor één gebruiker te bevinden. Andere gebruikers kunnen in de database werken wanneer deze is verkleind, inclusief systeemdatabases.

U kunt een database niet verkleinen terwijl er een back-up van de database wordt gemaakt. U kunt daarentegen geen back-ups maken van een database terwijl een verkleiningsbewerking voor de database wordt uitgevoerd.

In Azure Synapse SQL-pools moet je een shrink-commando vermijden omdat het een I/O-intensieve operatie is die je dedicated SQL-pool (voorheen SQL DW) offline kan halen. Dit commando beïnvloedt ook de kosten van je datawarehouse-snapshots.

Bekende problemen

Van toepassing op: SQL Server, Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics dedicated SQL pool

• In SQL Server 2022 (16.x) en eerdere versies kunnen de pagina's die door LOB-kolomtypes (varbinary(max),varchar(max) en nvarchar(max)) in gecomprimeerde kolomstore-segmenten worden gebruikt, niet worden verplaatst door DBCC SHRINKDATABASE en DBCC SHRINKFILE. Zie Wat is er nieuw in columnstore-indexen voor meer informatie.

Hoe DBCC SHRINKDATABASE werkt

DBCC SHRINKDATABASE verkleint gegevensbestanden per bestand, maar verkleint logboekbestanden alsof alle logboekbestanden in één aaneengesloten logboekgroep bestaan. Bestanden worden altijd vanaf het einde verkleind.

Stel dat je twee logbestanden en een databestand hebt in een database genaamd mydb. De gegevens en logboekbestanden zijn elk 10 MB en het gegevensbestand bevat 6 MB aan gegevens. De database-engine berekent een doelgrootte voor elk bestand. Deze waarde is de doelgrootte van het bestand na het verkleinen. Wanneer je met target_percent specificeertDBCC SHRINKDATABASE, berekent de Database Engine de doelgrootte als de target_percent hoeveelheid ruimte die vrij is in het bestand na het verkleinen.

Als u bijvoorbeeld een target_percent van 25 opgeeft om te verkleinen mydb, berekent de database-engine de doelgrootte voor het gegevensbestand als 8 MB (6 MB aan gegevens plus 2 MB vrije ruimte). Als zodanig verplaatst de database-engine alle gegevens van het laatste 2 MB van het gegevensbestand naar vrije ruimte in de eerste 8 MB van het gegevensbestand en verkleint het bestand.

Stel dat het gegevensbestand van mydb 7 MB aan gegevens bevat. Als u een target_percent van 30 opgeeft, kan dit gegevensbestand worden verkleind tot het gratis percentage van 30. Als u echter een target_percent van 40 opgeeft, wordt het gegevensbestand niet verkleind omdat er onvoldoende vrije ruimte kan worden gemaakt in de huidige totale grootte van het gegevensbestand.

U kunt dit probleem op een andere manier beschouwen: 40 procent vrije ruimte + 70 procent volledig gegevensbestand (7 MB van 10 MB) is meer dan 100 procent. Elke target_percent groter dan 30 verkleint het gegevensbestand niet. Het wordt niet verkleind omdat het percentage gratis dat u wilt plus het huidige percentage dat het gegevensbestand in beslag neemt, hoger is dan 100 procent.

Voor logboekbestanden gebruikt de database-engine target_percent om de doelgrootte voor het hele logboek te berekenen. Daarom is target_percent de hoeveelheid vrije ruimte in het logboek na de verkleiningsbewerking. De doelgrootte voor het hele logboek wordt vervolgens omgezet in een doelgrootte voor elk logboekbestand.

DBCC SHRINKDATABASE probeert elk fysiek logboekbestand onmiddellijk te verkleinen tot de doelgrootte. Als geen enkel deel van het logische logboek in de virtuele logs blijft buiten de doelgrootte van het logbestand, DBCC SHRINKDATABASE wordt het bestand succesvol afgekort en wordt het zonder berichten afgerond. Als een deel van het logische logboek echter binnen de virtuele logboeken blijft en daarmee buiten de doelgrootte, maakt de databasemotor zoveel mogelijk ruimte vrij en geeft vervolgens een informatief bericht. Het bericht beschrijft de acties om het logische loglogboek uit de virtuele logs aan het einde van het bestand te verplaatsen. Nadat de acties zijn uitgevoerd, gebruik DBCC SHRINKDATABASE je het om de resterende ruimte vrij te maken.

Je kunt een logbestand alleen verkleinen tot een virtuele logbestandgrens. Daarom is het niet mogelijk om een logbestand te verkleinen tot een kleinere grootte dan de grootte van een virtueel logbestand. De Database Engine kiest dynamisch de grootte van het virtuele logbestand bij het aanmaken of uitbreiden van logbestanden.

Gelijktijdigheidsproblemen met DBCC SHRINKDATABASE begrijpen

De commando's voor verkleindatabase- en verkleiningsbestanden kunnen leiden tot gelijktijdigheidsproblemen, vooral bij actief onderhoud zoals het herbouwen van indexen, of in drukke OLTP-omgevingen.

Bijvoorbeeld, een gebruikersquery kan een schema-stabiliteitslock (Sch-S) verkrijgen op een Index Allocation Map (IAM)-pagina en deze vasthouden tot voltooiing. Bij het proberen ruimte terug te winnen tijdens normaal gebruik, vereisen verkleiningsdatabase- en verkleiningsbestandoperaties een schemawijziging (Sch-M) lock () bij het verplaatsen of verwijderen van IAM-pagina's, waardoor de Sch-S vergrendelingen die nodig zijn voor gebruikersqueries worden geblokkeerd. Als gevolg hiervan kunnen langlopende queries een verkleiningsoperatie blokkeren. Dit gedrag betekent ook dat elke nieuwe query die een Sch-S lock op een IAM-pagina vereist, achter de shrink-operatie kan komen te staan, wat dit gelijktijdigheidsprobleem verder verergert.

Geïntroduceerd in SQL Server 2022 (16.x), lost de 'wait at low priority'-functie voor shrink-operaties dit probleem aan door de schema-wijzigingslock op IAM-pagina's in de WAIT_AT_LOW_PRIORITY modus te nemen. Zie WAIT_AT_LOW_PRIORITY met verkleiningsbewerkingenvoor meer informatie.

Voor meer informatie over Sch-S en Sch-M locks, zie Transaction locking and row versioning guide.

Beste praktijken

Houd rekening met de volgende informatie wanneer u van plan bent om een database te verkleinen:

• Een verkleiningsbewerking is het meest effectief na een bewerking die ongebruikte ruimte creëert, zoals een trunceren van een tabel of een drop table-operatie.

• De meeste databases hebben wat vrije ruimte nodig voor de dagelijkse werkzaamheden. Als je een databasebestand herhaaldelijk verkleint en merkt dat de databasegrootte weer toeneemt, geeft deze groei aan dat reguliere bewerkingen de vrije ruimte vereisen. In deze gevallen is het herhaaldelijk verkleinen van het databasebestand contraproductief. De bestandsgroei die nodig is om nieuwe ruimte toe te wijzen na het verkleinen kan de prestaties belemmeren.

• Een verkleiningsoperatie behoudt de fragmentatietoestand van indexen in de database niet en kan de indexfragmentatie verhogen, wat de lees-I/O-doorvoer voor zoekopdrachten met grote scans kan verminderen.

• Tenzij u een specifieke vereiste hebt, moet u de AUTO_SHRINK databaseoptie niet instellen op ON.

• Als je de databestanden van een grote database moet verkleinen, overweeg dan het ShrinkDriver PowerShell-script te gebruiken. Het script automatiseert en vereenvoudigt het krimpproces, waardoor het een enkele, waarneembare en hervatbare operatie wordt. Het script verkleint meerdere bestanden parallel, probeert opnieuw wanneer het wordt onderbroken en geeft gedetailleerde statusrapporten terwijl het draait.

Problemen oplossen

Een transactie die wordt uitgevoerd onder een isolatieniveau op basis van rijversies kan verkleiningsbewerkingen blokkeren. Je voert DBCC SHRINKDATABASE bijvoorbeeld uit terwijl een grote verwijderingsoperatie onder een op rijversies gebaseerde isolatie bezig is. In dit geval wacht de verkleiningsoperatie tot de verwijderingsoperatie is voltooid voordat de bestanden worden verkleind. Wanneer de verkleiningsbewerking wacht, wordt een informatief bericht afgedrukt voor de bewerkingen DBCC SHRINKFILE en DBCC SHRINKDATABASE (5202 voor SHRINKDATABASE en 5203 voor SHRINKFILE). Dit bericht wordt elke vijf minuten in het eerste uur en daarna elk uur naar het SQL Server-foutlogboek geprint. Als het foutenlogboek bijvoorbeeld het volgende foutbericht bevat:

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.

Deze fout betekent dat snapshottransacties met tijdstempels ouder dan 109 de krimpbewerking blokkeren. Deze transactie is de laatste transactie die de verkleiningsbewerking heeft voltooid. Het geeft ook aan dat de transaction_sequence_num of-kolommen first_snapshot_sequence_num in de dynamische beheerweergave van sys.dm_tran_active_snapshot_database_transactions een waarde van 15 bevatten. De kolom transaction_sequence_num of first_snapshot_sequence_num in de weergave kan een getal bevatten dat kleiner is dan de laatste transactie die is voltooid door een verkleiningsbewerking (109). Zo ja, dan wacht de verkleiningsbewerking totdat deze transacties zijn voltooid.

Om het probleem op te lossen, kun je een van de volgende doen:

• Beëindig de transactie die de verkleiningsbewerking blokkeert.
• De verkleiningsbewerking beëindigen. Voltooid werk wordt bewaard.
• 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

De codevoorbeelden in dit artikel gebruiken de AdventureWorks2025 of AdventureWorksDW2025 voorbeelddatabase die u kunt downloaden van de startpagina van Microsoft SQL Server Samples en Community Projects .

Een. Een database verkleinen en een percentage vrije ruimte opgeven

In het volgende voorbeeld wordt de grootte van de gegevens en logboekbestanden in de UserDB gebruikersdatabase verkleind om 10 procent vrije ruimte in de database mogelijk te maken.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Een database afkappen

In het volgende voorbeeld worden de gegevens en logboekbestanden in de AdventureWorks2025 voorbeelddatabase verkleind tot aan het laatst toegewezen gedeelte.

DBCC SHRINKDATABASE (AdventureWorks2025, TRUNCATEONLY);

C. Een Azure Synapse Analytics-database verkleinen

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

D. Verklein een database met WAIT_AT_LOW_PRIORITY

In het volgende voorbeeld wordt geprobeerd om de grootte van de gegevens en logboekbestanden in de AdventureWorks2025-database te verkleinen om 20% vrije ruimte in de database mogelijk te maken. Als een vergrendeling niet binnen één minuut kan worden verkregen, wordt de verkleiningsbewerking afgebroken.

DBCC SHRINKDATABASE ([AdventureWorks2025], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Verwante inhoud

• Een database verkleinen
• Een bestand verkleinen
• DBCC SHRINKFILE (Transact-SQL)
• Overwegingen voor de instellingen voor automatisch vergroten en automatisch maken in SQL Server
• Databasebestanden en bestandsgroepen
• sys.databases (Transact-SQL)
• sys.database_files (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Bestandsruimte voor databases in Azure SQL Database beheren