- 07/17/2017
- 8 minuter att läsa
-
- p
- M
- j
- i
- K
-
+12
Gäller: SQL Server (alla versioner som stöds) Azure SQL Database Azure Synapse Analytics
Krymper storleken på data- och loggfiler i den angivna databasen.
Transact-SQL syntaxkonventioner
Syntax
DBCC SHRINKDATABASE ( database_name | database_id | 0 )
-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name )
Notis
Om du vill visa Transact-SQL-syntaxen för SQL Server 2014 och tidigare versioner, se dokumentationen för tidigare versioner.
Argument
database_name | database_id | 0
Är databasens namn eller ID som ska krympas. 0 anger att den aktuella databasen används.
target_percent
Är den procentandel ledigt utrymme som du vill ha kvar i databasfilen efter att databasen har krympts.
NOTRUNCATE
Flyttar tilldelade sidor från filens ände till icke tilldelade sidor i början av filen. Den här åtgärden komprimerar data i filen. target_percent är valfritt. Azure Synapse Analytics har inte stöd för det här alternativet.
Det fria utrymmet i slutet av filen returneras inte till operativsystemet och den fysiska storleken på filen ändras inte. Databasen verkar därför inte krympa när du anger NOTRUNCATE.
NOTRUNCATE gäller endast för datafiler. NOTRUNCATE påverkar inte loggfilen.
TRUNCATEONLY
Lämnar allt ledigt utrymme i slutet av filen till operativsystemet. Flyttar inte några sidor i filen. Datafilen krymper endast till den senast tilldelade omfattningen. Ignorerar target_percent om den anges med TRUNCATEONLY. Azure Synapse Analytics har inte stöd för det här alternativet.
TRUNCATEONLY påverkar loggfilen. Använd DBCC SHRINKFILE om du vill trunka endast datafilen.
WITH NO_INFOMSGS
Undertrycker alla informationsmeddelanden som har allvarlighetsnivåer från 0 till 10.
Resultatuppsättningar
I följande tabell beskrivs kolumnerna i resultatuppsättningen.
Kolumnnamn | Beskrivning |
---|---|
DbId | Databasens identifieringsnummer för filen som databasmotorn försökte krympa. |
FileId | Filidentifikationsnummer för filen som databasmotorn försökte krympa. |
CurrentSize | Antal 8-KB-sidor som filen för närvarande upptar. |
MinimumSize | Antal 8-KB-sidor som filen kan uppta, som minimum. Detta värde motsvarar filens minimistorlek eller ursprungligen skapade storlek. |
UsedPages | Antal 8-KB-sidor som filen för närvarande använder. |
EstimatedPages | Antal 8-KB-sidor som databasmotorn uppskattar att filen skulle kunna krympas ner till. |
Note
Databasmotorn visar inte rader för de filer som inte har krympts.
Remarks
Note
Att köra det här kommandot rekommenderas inte, eftersom det här är en i/o-intensiv operation som kan göra att datalagret blir offline. Dessutom kommer dina ögonblicksbilder av datalagret att få konsekvenser för kostnadsberäkningen efter att du har kört det här kommandot.
För att krympa alla data- och loggfiler för en specifik databas utför du kommandot DBCC SHRINKDATABASE. Om du vill krympa en data- eller loggfil i taget för en specifik databas utför du kommandot DBCC SHRINKFILE.
För att visa den aktuella mängden ledigt (oallokerat) utrymme i databasen kör du sp_spaceused.
DBCC SHRINKDATABASE-operationer kan stoppas när som helst i processen, och allt avslutat arbete behålls.
Databasen kan inte vara mindre än databasens konfigurerade minsta storlek. Du anger minimistorleken när databasen ursprungligen skapas. Eller så kan minimistorleken vara den senaste storleken som uttryckligen fastställts med hjälp av en filstorleksändringsoperation. Operationer som DBCC SHRINKFILE eller ALTER DATABASE är exempel på operationer som ändrar filstorlek.
Säg att en databas ursprungligen skapas med en storlek på 10 MB i storlek. Sedan växer den till 100 MB. Det minsta som databasen kan minskas till är 10 MB, även om alla data i databasen har raderats.
Ange antingen alternativet NOTRUNCATE eller alternativet TRUNCATEONLY när du kör DBCC SHRINKDATABASE. Om du inte gör det blir resultatet detsamma som om du kör en DBCC SHRINKDATABASE-operation med NOTRUNCATE följt av en DBCC SHRINKDATABASE-operation med TRUNCATEONLY.
Den krympta databasen behöver inte vara i enanvändarläge. Andra användare kan arbeta i databasen när den krymps, inklusive systemdatabaser.
Du kan inte krympa en databas medan databasen säkerhetskopieras. Omvänt kan du inte säkerhetskopiera en databas medan en krympningsoperation på databasen pågår.
Hur DBCC SHRINKDATABASE fungerar
DBCC SHRINKDATABASE krymper datafiler per fil, men krymper loggfiler som om alla loggfiler fanns i en sammanhängande loggpool. Filerna krymps alltid från slutet.
Antag att du har ett par loggfiler, en datafil och en databas som heter mydb. Data- och loggfilerna är 10 MB vardera och datafilen innehåller 6 MB data. Databasmotorn beräknar en målstorlek för varje fil. Detta värde är den storlek som filen ska krympas till. När DBCC SHRINKDATABASE anges med target_percent beräknar databasmotorn målstorleken som target_percent av det fria utrymmet i filen efter krympningen.
Till exempel, om du anger target_percent på 25 för krympning av mydb beräknar databasmotorn målstorleken för datafilen till 8 MB (6 MB data plus 2 MB fritt utrymme). Databasmotorn flyttar därför all data från datafilens sista 2 MB till allt ledigt utrymme i datafilens första 8 MB och krymper sedan filen.
Antag att datafilen för mydb innehåller 7 MB data. Genom att ange target_percent på 30 kan den här datafilen krympas till den fria procentandelen på 30. Att ange target_percent på 40 krymper dock inte datafilen eftersom databasmotorn inte krymper en fil till en storlek som är mindre än vad datan för närvarande upptar.
Du kan också tänka på det här problemet på ett annat sätt: Du kan också se det på ett annat sätt: 40 procent önskat ledigt utrymme + 70 procent full datafil (7 MB av 10 MB) är mer än 100 procent. En target_size som är större än 30 krymper inte datafilen. Den krymper inte eftersom den procentuella andelen fritt utrymme som du vill ha plus den aktuella procentuella andelen som datafilen upptar är över 100 procent.
För loggfiler använder databasmotorn target_percent för att beräkna målstorleken för hela loggfilen. Det är därför target_percent är mängden fritt utrymme i loggen efter krympningsoperationen. Målstorlek för hela loggen översätts sedan till en målstorlek för varje loggfil.
DBCC SHRINKDATABASE försöker krympa varje fysisk loggfil till sin målstorlek omedelbart. Låt oss säga att ingen del av den logiska loggen stannar kvar i de virtuella loggarna utöver loggfilens målstorlek. Då är filen framgångsrikt nedskuren och DBCC SHRINKDATABASE avslutas utan några meddelanden. Om en del av den logiska loggen stannar kvar i de virtuella loggarna utöver målstorleken frigör databasmotorn så mycket utrymme som möjligt och utfärdar sedan ett informationsmeddelande. Meddelandet beskriver vilka åtgärder som krävs för att flytta den logiska loggen ut ur de virtuella loggarna i slutet av filen. När åtgärderna har utförts kan DBCC SHRINKDATABASE användas för att frigöra det återstående utrymmet.
En loggfil kan endast krympas till en virtuell loggfilgräns. Därför är det kanske inte möjligt att krympa en loggfil till en storlek som är mindre än storleken på en virtuell loggfil. Det kanske inte är möjligt även om den inte används. Storleken på den virtuella loggfilen väljs dynamiskt av databasmotorn när loggfiler skapas eller utökas.
Bästa praxis
Tänk på följande information när du planerar att krympa en databas:
- En krympningsoperation är mest effektiv efter en operation som skapar oanvänt utrymme, t.ex. en truncate table (trunkerad tabell) eller en drop table (borttappad tabell).
- De flesta databaser kräver att ett visst ledigt utrymme ska finnas tillgängligt för vanlig daglig verksamhet. Det kan hända att du krymper en databas upprepade gånger och märker att databasens storlek växer igen. Denna tillväxt indikerar att det krympta utrymmet krävs för regelbunden verksamhet. I dessa fall är upprepad krympning av databasen en bortkastad operation.
- En krympningsoperation bevarar inte fragmenteringstillståndet för indexen i databasen och ökar i allmänhet fragmenteringen i viss utsträckning. Detta resultat är ytterligare en anledning till att inte krympa databasen upprepade gånger.
- Om du inte har ett specifikt krav ska du inte ställa in databasalternativet AUTO_SHRINK på ON.
Felsökning
Det är möjligt att blockera krympningsoperationer av en transaktion som körs under en isoleringsnivå baserad på radversionering. Till exempel pågår en stor raderingsoperation som körs under en radversioneringsbaserad isoleringsnivå när en DBCC SHRINK DATABASE-operation utförs. När den här situationen inträffar kommer krympningsoperationen att vänta tills raderingsoperationen är klar innan den krymper filerna. När krympningsoperationen väntar skriver DBCC SHRINKFILE och DBCC SHRINKDATABASE ut ett informationsmeddelande (5202 för SHRINKDATABASE och 5203 för SHRINKFILE). Meddelandet skrivs ut i SQL Servers felprotokoll var femte minut under den första timmen och därefter varje kommande timme. Om felloggen till exempel innehåller följande felmeddelande:
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.
Detta fel innebär att snapshottransaktioner som har tidsstämplar som är äldre än 109 blockerar krympningsoperationen. Den transaktionen är den sista transaktionen som krympningsoperationen slutförde. Det visar också att kolumnerna transaction_sequence_num eller first_snapshot_sequence_num i den dynamiska hanteringsvyn sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) innehåller värdet 15. Kolumnen transaction_sequence_num eller first_snapshot_sequence_num i vyn kan innehålla ett nummer som är mindre än den senaste transaktionen som slutfördes av en krympningsoperation (109). I så fall väntar krympningsoperationen på att de transaktionerna ska avslutas.
För att lösa problemet kan du utföra en av följande uppgifter:
- Avsluta den transaktion som blockerar krympningsoperationen.
- Avsluta krympningsoperationen. Allt slutfört arbete behålls.
- Gör ingenting och låt krympningsoperationen vänta tills den blockerande transaktionen är klar.
Permissioner
Kräver medlemskap i den fasta serverrollen sysadmin eller den fasta databasrollen db_owner.
Exempel
A. Minska en databas och ange en procentandel ledigt utrymme
Följande exempel minskar storleken på data- och loggfilerna i UserDB
-användardatabasen för att ge 10 procent ledigt utrymme i databasen.
DBCC SHRINKDATABASE (UserDB, 10); GO
B. Skära av en databas
Följande exempel krymper data- och loggfilerna i AdventureWorks
provdatabasen till den senast tilldelade omfattningen.
DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);
C. Krympning av en Azure Synapse Analytics-databas
DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10);
Se även
ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Krympning av en databas
.