DBCC SHRINKDATABASE (Transact-SQL)

• 07/17/2017
• 8 minuten om te lezen
• • p
  • M
  • j
  • i
  • K
  • +12

Geldt voor: SQL Server (alle ondersteunde versies) Azure SQL Database Azure Synapse Analytics

Kleint de grootte van de gegevens- en logbestanden in de opgegeven database.

Transact-SQL Syntaxconventies

Syntax

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 

-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

Arguments

database_name | database_id | 0
Is de database naam of ID die verkleind moet worden. 0 geeft aan dat de huidige database wordt gebruikt.

target_percent
Is het percentage vrije ruimte dat u in het databasebestand wilt overhouden nadat de database is verkleind.

NOTRUNCATE
Verplaatst toegewezen pagina’s van het einde van het bestand naar niet-toegewezen pagina’s aan de voorzijde van het bestand. Deze actie verdicht de gegevens in het bestand. target_percent is optioneel. Azure Synapse Analytics ondersteunt deze optie niet.

De vrije ruimte aan het einde van het bestand wordt niet teruggegeven aan het besturingssysteem, en de fysieke grootte van het bestand verandert niet. Als zodanig lijkt de database niet te krimpen wanneer u NOTRUNCATE opgeeft.

NOTRUNCATE is alleen van toepassing op gegevensbestanden. NOTRUNCATE heeft geen invloed op het logbestand.

TRUNCATEONLY
Geeft alle vrije ruimte aan het einde van het bestand vrij aan het besturingssysteem. Verplaatst geen pagina’s in het bestand. Het gegevensbestand krimpt alleen tot de laatst toegewezen extent. Negeert target_percent indien opgegeven met TRUNCATEONLY. Azure Synapse Analytics ondersteunt deze optie niet.

TRUNCATEONLY beïnvloedt het logbestand. Om alleen het gegevensbestand te trunceren, gebruikt u DBCC SHRINKFILE.

WITH NO_INFOMSGS
Onderdrukt alle informatieve berichten die een ernstniveau van 0 tot en met 10 hebben.

Result Sets

De volgende tabel beschrijft de kolommen in de resultatenset.

Kolomnaam	Beschrijving
DbId	Database-identificatienummer van het bestand dat de Database Engine heeft geprobeerd te verkleinen.
FileId	Het identificatienummer van het bestand dat de Database Engine heeft proberen te verkleinen.
CurrentSize	Aantal pagina’s van 8 KB dat het bestand momenteel in beslag neemt.
MinimumSize	Aantal pagina’s van 8 KB dat het bestand minimaal in beslag zou kunnen nemen. Deze waarde komt overeen met de minimumgrootte of de oorspronkelijk gemaakte grootte van een bestand.
GebruiktePagina’s	Aantal 8-KB pagina’s dat momenteel door het bestand wordt gebruikt.
GeschattePagina’s	Aantal 8-KB pagina’s dat het bestand volgens de Database Engine naar schatting zou kunnen worden ingekrompen.

Remarks

Om alle gegevens- en logbestanden voor een specifieke database te verkleinen, voert u de opdracht DBCC SHRINKDATABASE uit. Om één gegevens- of logbestand per keer voor een specifieke database te verkleinen, voert u het DBCC SHRINKFILE-commando uit.

Om de huidige hoeveelheid vrije (niet-toegewezen) ruimte in de database te bekijken, voert u sp_spaceused uit.

DBCC SHRINKDATABASE-bewerkingen kunnen op elk punt in het proces worden gestopt, en al het voltooide werk blijft behouden.

De database kan niet kleiner zijn dan de geconfigureerde minimumgrootte van de database. U geeft de minimumgrootte op wanneer de database oorspronkelijk wordt gemaakt. Of, de minimum grootte kan de laatste grootte zijn die expliciet is ingesteld met behulp van een operatie voor het wijzigen van de bestandsgrootte. Operaties als DBCC SHRINKFILE of ALTER DATABASE zijn voorbeelden van operaties waarbij de bestandsgrootte wordt gewijzigd.

Zeg dat een database oorspronkelijk is gemaakt met een grootte van 10 MB. Vervolgens groeit hij tot 100 MB. De database kan niet kleiner worden gemaakt dan 10 MB, zelfs niet als alle gegevens in de database zijn verwijderd.

Specifieer ofwel de NOTRUNCATE-optie of de TRUNCATEONLY-optie wanneer u DBCC SHRINKDATABASE uitvoert. Als u dat niet doet, is het resultaat hetzelfde als wanneer u een DBCC SHRINKDATABASE-operatie met NOTRUNCATE uitvoert, gevolgd door een DBCC SHRINKDATABASE-operatie met TRUNCATEONLY.

De gekrompen database hoeft niet in single user-modus te staan. Andere gebruikers kunnen in de database werken wanneer deze wordt verkleind, inclusief systeemdatabases.

U kunt een database niet verkleinen terwijl er een back-up van de database wordt gemaakt. Omgekeerd kunt u geen back-up van een database maken terwijl er een krimpbewerking op de database wordt uitgevoerd.

Hoe DBCC SHRINKDATABASE werkt

DBCC SHRINKDATABASE krimpt gegevensbestanden per bestand, maar krimpt logbestanden alsof alle logbestanden in één aaneengesloten logpool bestaan. Bestanden worden altijd vanaf het einde gekrompen.

Veronderstel dat u een paar logbestanden, een gegevensbestand en een database met de naam mydb hebt. De gegevens- en logbestanden zijn elk 10 MB groot en het gegevensbestand bevat 6 MB aan gegevens. De Database Engine berekent een doelgrootte voor elk bestand. Deze waarde is de grootte waarnaar het bestand moet worden gekrompen. Wanneer DBCC SHRINKDATABASE wordt opgegeven met target_percent, berekent de Database Engine de doelgrootte als de target_percent hoeveelheid vrije ruimte in het bestand na het verkleinen.

Wanneer u bijvoorbeeld een target_percent van 25 opgeeft voor het verkleinen van mydb, berekent de Database Engine de doelgrootte voor het gegevensbestand op 8 MB (6 MB aan gegevens plus 2 MB aan vrije ruimte). Als zodanig verplaatst de Database Engine alle gegevens van de laatste 2 MB van het gegevensbestand naar vrije ruimte in de eerste 8 MB van het gegevensbestand en wordt het bestand gekrompen.

Aannemelijk is dat het gegevensbestand van mydb 7 MB aan gegevens bevat. Door een doel_percentage van 30 op te geven, kan dit gegevensbestand worden gekrompen tot het vrije percentage van 30. Als u echter een doel_percentage van 40 opgeeft, wordt het gegevensbestand niet gekrompen, omdat de Database Engine een bestand niet zal krimpen tot een grootte die kleiner is dan de gegevens op dat moment innemen.

U kunt dit probleem ook op een andere manier bekijken: 40 procent gezochte vrije ruimte + 70 procent vol gegevensbestand (7 MB van de 10 MB) is meer dan 100 procent. Elke target_size groter dan 30 zal het data bestand niet verkleinen. Het zal niet krimpen omdat het gewenste percentage vrije ruimte plus het huidige percentage dat het databestand in beslag neemt meer dan 100 procent is.

Voor logbestanden gebruikt de Database Engine target_percent om de doelgrootte voor het hele logbestand te berekenen. Daarom is target_percent de hoeveelheid vrije ruimte in het logboek na de krimpoperatie. De doelgrootte voor het hele log wordt dan vertaald naar een doelgrootte voor elk logbestand.

DBCC SHRINKDATABASE probeert elk fysiek logbestand onmiddellijk naar zijn doelgrootte te verkleinen. Laten we zeggen dat geen enkel deel van het logboek in de virtuele logboeken blijft tot voorbij de doelgrootte van het logbestand. Dan wordt het bestand succesvol gekrompen en DBCC SHRINKDATABASE eindigt zonder berichten. Als echter een deel van het logboek in de virtuele logboeken voorbij de doelgrootte blijft, maakt de Database Engine zoveel mogelijk ruimte vrij en geeft dan een informatieve melding. Het bericht beschrijft welke acties nodig zijn om het logboek uit de virtuele logboeken te verwijderen aan het einde van het bestand. Nadat de acties zijn uitgevoerd, kan DBCC SHRINKDATABASE worden gebruikt om de resterende ruimte vrij te maken.

Een logbestand kan alleen worden gekrompen tot een virtuele grens van het logbestand. Daarom is het krimpen van een logbestand tot een grootte die kleiner is dan de grootte van een virtueel logbestand misschien niet mogelijk. Het kan zelfs onmogelijk zijn als het niet gebruikt wordt. De grootte van het virtuele logbestand wordt dynamisch gekozen door de Database Engine wanneer logbestanden worden gemaakt of uitgebreid.

Best Practices

Overweeg de volgende informatie wanneer u van plan bent een database te verkleinen:

• Een krimpbewerking is het effectiefst na een bewerking die ongebruikte ruimte creëert, zoals een truncate table- of een drop table-bewerking.
• De meeste databases hebben enige vrije ruimte nodig om beschikbaar te zijn voor normale, dagelijkse bewerkingen. U kunt een database herhaaldelijk verkleinen en merken dat de databasegrootte weer toeneemt. Deze groei geeft aan dat de gekrompen ruimte nodig is voor regelmatige bewerkingen. In deze gevallen is het herhaaldelijk verkleinen van de database een verspilde operatie.
• Een krimpbewerking behoudt de fragmentatietoestand van indexen in de database niet, en verhoogt over het algemeen de fragmentatie tot op zekere hoogte. Dit resultaat is een andere reden om de database niet herhaaldelijk te verkleinen.
• Niet de AUTO_SHRINK database optie op ON zetten, tenzij u een specifieke eis heeft.

Troubleshooting

Het is mogelijk om krimp operaties te blokkeren door een transactie die draait onder een rij versie-gebaseerd isolatieniveau. Er is bijvoorbeeld een grote verwijderoperatie bezig die wordt uitgevoerd onder een rijenversiegebaseerd isolatieniveau wanneer een DBCC SHRINK DATABASE operatie wordt uitgevoerd. Als deze situatie zich voordoet, wacht de krimpbewerking tot de verwijderbewerking is voltooid voordat de bestanden worden gekrompen. Wanneer de shrink-bewerking wacht, drukken de DBCC SHRINKFILE- en DBCC SHRINKDATABASE-bewerkingen een informatief bericht af (5202 voor SHRINKDATABASE en 5203 voor SHRINKFILE). Deze melding wordt in het eerste uur om de vijf minuten en daarna om het uur afgedrukt in het foutenlogboek van SQL Server. Als het foutenlogboek bijvoorbeeld de volgende foutmelding 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 snapshot-transacties met tijdstempels ouder dan 109 de krimpbewerking blokkeren. Die transactie is de laatste transactie die de krimpoperatie heeft voltooid. 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 (Transact-SQL) een waarde van 15 bevatten. De kolom transaction_sequence_num of first_snapshot_sequence_num in de view kan een getal bevatten dat lager is dan de laatste transactie die door een krimpbewerking is voltooid (109). Als dat het geval is, wacht de krimpbewerking tot die transacties zijn voltooid.

Om het probleem op te lossen, kunt u een van de volgende taken uitvoeren:

• Beëindig de transactie die de krimpbewerking blokkeert.
• Beëindig de krimpbewerking. Al het voltooide werk blijft behouden.
• Niets doen en de krimpbewerking laten wachten tot de blokkerende transactie is voltooid.

Permissies

Veist lidmaatschap van de vaste serverrol sysadmin of de vaste databaserol db_owner.

Voorbeelden

A. Een database verkleinen en een percentage vrije ruimte opgeven

Het volgende voorbeeld verkleint de grootte van de gegevens- en logbestanden in de UserDB gebruikersdatabase om 10 procent vrije ruimte in de database mogelijk te maken.

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. Een database verkleinen

Het volgende voorbeeld verkleint de gegevens- en logbestanden in de AdventureWorks voorbeelddatabase tot de laatst toegewezen extent.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Een Azure Synapse Analytics database verkleinen

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

Zie ook

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Een database verkleinen