DBCC KRYMPDATABAS (Transact-SQL)

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL-databas i Microsoft Fabric

Minskar storleken på data och loggfiler i den angivna databasen.

Se inte krympningsverksamheten som en vanlig underhållsverksamhet. Data och loggfiler som växer på grund av regelbundna återkommande affärsåtgärder kräver inte krympningsåtgärder.

Transact-SQL syntaxkonventioner

Syntax

Syntax för 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 }

Syntax för Azure Synapse Analytics:

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

Argumenten

{ database_name | database_id | 0 }

Namnet eller ID:t på databasen som ska krympas. Ett värde 0 specificerar den aktuella databasen.

target_percent

Andelen ledigt utrymme som ska lämnas kvar i databasfilen efter att förminskningsoperationen är klar.

Om du anger target_percent med TRUNCATEONLY, kanske krympningsoperationen inte frigör ledigt utrymme i slutet av filen.

NOTRUNCATE

Flyttar tilldelade sidor från filens slut till otilldelade sidor framför filen. Den här åtgärden komprimerar data i filen. target_percent är valfritt. Azure Synapse Analytics stöder inte det här alternativet.

Det lediga utrymmet i slutet av filen returneras inte till operativsystemet och filens fysiska storlek ändras inte. Därför verkar databasen inte krympa när du anger NOTRUNCATE.

NOTRUNCATE gäller endast för datafiler. NOTRUNCATE påverkar inte loggfilen.

ENDAST ENDAST

Frigör allt ledigt utrymme i slutet av filen till operativsystemet. Flyttar inga sidor i filen. Datafilen krymper endast till den senast tilldelade omfattningen. Azure Synapse Analytics stöder inte det här alternativet.

Om du anger target_percent med TRUNCATEONLY, kanske krympningsoperationen inte frigör ledigt utrymme i slutet av filen.

UTAN NO_INFOMSGS

Undertrycker alla informationsmeddelanden som har allvarlighetsgrad mellan 0 och 10.

WAIT_AT_LOW_PRIORITY med krympåtgärder

Gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database, Azure SQL Managed Instance, SQL database i Microsoft Fabric

Funktionen 'vänta vid låg prioritet' minskar låskonkurrens under krympningsoperationen. Mer information finns i Förstå samtidighetsproblem med DBCC SHRINKDATABASE.

Den här funktionen liknar WAIT_AT_LOW_PRIORITY med onlineindexåtgärder, med vissa skillnader.

• Du kan inte specificera ABORT_AFTER_WAIT alternativ NONE.
• Du kan inte ställa in MAX_DURATION valet. Tidsavslutningen för lågprioriterat lås för en krympoperation är alltid en minut.

VÄNTA MED LÅG PRIORITET

När ett shrink-kommando körs i WAIT_AT_LOW_PRIORITY mode blockeras inte frågor som kräver schema stability (Sch-S) låsningar på Index Allocation Map (IAM)-sidorna av shrink-operationen. Dock kan krympningsoperationen blockeras av ett Sch-S lås på en IAM-sida. Shrink fortsätter att köras endast när den kan få ett schema modifiera lås () lås påSch-M en IAM-sida som det kräver.

Om en krympoperation i WAIT_AT_LOW_PRIORITY läge inte kan få detta lås på grund av en långvarig fråga som håller ett Sch-S lås, går krympoperationen ut med fel 49516, till exempel: 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 = [ SJÄLV | BLOCKERARE ] }

• SELF

  SELF är standardalternativet. Avsluta den krympdatabasoperation som för närvarande körs utan att vidta ytterligare åtgärder.

• BLOCKERS

  Avsluta alla användartransaktioner som blockerar krympningsfilåtgärden så att åtgärden kan fortsätta. Alternativet BLOCKERS kräver att inloggningen har ALTER ANY CONNECTION OR-behörighet KILL DATABASE CONNECTION .

Resultatuppsättning

I följande tabell beskrivs kolumnerna i resultatuppsättningen.

Anmärkningar

Om du vill krympa alla data och loggfiler för en specifik databas kör du kommandot DBCC SHRINKDATABASE. Om du vill krympa en data- eller loggfil åt gången för en specifik databas kör du kommandot DBCC SHRINKFILE .

Om du vill visa den aktuella mängden ledigt (oallokerat) utrymme i databasen kör du sp_spaceused.

DBCC SHRINKDATABASE åtgärder kan stoppas när som helst i processen och allt slutfört arbete sparas.

Databasen får inte vara mindre än databasens konfigurerade minsta storlek. Du anger den minsta storleken när databasen ursprungligen skapades. Eller så kan den minsta storleken vara den sista storleken som uttryckligen anges med hjälp av en ändringsåtgärd för filstorlek. Åtgärder som DBCC SHRINKFILE eller ALTER DATABASE är exempel på filstorleksförändrande åtgärder.

Överväg att en databas ursprungligen har skapats med storleken 10 MB. Sedan växer den till 100 MB. Den minsta databasen kan minskas till 10 MB, även om alla data i databasen har tagits bort.

Du kan ange NOTRUNCATE alternativet eller TRUNCATEONLY alternativet när du kör DBCC SHRINKDATABASE. Om du inte specificerar något av alternativen blir resultatet detsamma som om du kör en DBCC SHRINKDATABASE operation med NOTRUNCATE följt av att köra en DBCC SHRINKDATABASE operation med TRUNCATEONLY.

Den krympta databasen behöver inte vara i enst användarläge. Andra användare kan arbeta i databasen när den är krympt, inklusive systemdatabaser.

Du kan inte krympa en databas när databasen säkerhetskopieras. Omvänt kan du inte säkerhetskopiera en databas medan en krympningsåtgärd på databasen pågår.

I Azure Synapse SQL-pooler, undvik att köra ett shrink-kommando eftersom det är en I/O-intensiv operation som kan ta din dedikerade SQL-pool (tidigare SQL Dream) offline. Detta kommando påverkar också kostnaden för dina data warehouse-snapshots.

Kända problem

Gäller för: SQL Server, Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics dedicated SQL pool

• I SQL Server 2022 (16.x) och tidigare versioner kan sidorna som används av LOB-kolumntyper (varbinary(max),varchar(max) och nvarchar(max)) i komprimerade kolumnlagringssegment inte flyttas av DBCC SHRINKDATABASE och DBCC SHRINKFILE. Mer information finns i Nyheter i kolumnlagringsindex.

Så här fungerar DBCC SHRINKDATABASE

DBCC SHRINKDATABASE krymper datafiler per fil, men krymper loggfiler som om alla loggfiler fanns i en sammanhängande loggpool. Filer krymps alltid från slutet.

Anta att du har två loggfiler och en datafil i 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 målstorleken för filen efter att den krympt. När du specificerar DBCC SHRINKDATABASE med target_percent beräknar Database Engine målstorleken som den target_percent lediga platsen i filen efter att filen krympt.

Om du till exempel anger en target_percent på 25 för krympning mydbberäknar databasmotorn målstorleken för datafilen till 8 MB (6 MB data plus 2 MB ledigt utrymme). Därför flyttar databasmotorn alla data från datafilens sista 2 MB till ledigt utrymme i datafilens första 8 MB och krymper sedan filen.

Anta att datafilen för mydb innehåller 7 MB data. Om du anger en target_percent på 30 kan datafilen krympas till den kostnadsfria procentandelen på 30. Att ange en target_percent på 40 krymper dock inte datafilen eftersom det inte går att skapa tillräckligt med ledigt utrymme i datafilens aktuella totala storlek.

Du kan tänka dig det här problemet på ett annat sätt: 40 procent ville ha ledigt utrymme + 70 procent fullständig datafil (7 MB av 10 MB) är mer än 100 procent. Alla target_percent större än 30 krymper inte datafilen. Den kommer inte att krympa eftersom den procentuella mängden fri utrymme du vill ha plus den aktuella mängden 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 loggen. Det är därför target_percent är mängden ledigt utrymme i loggen efter krympningsåtgärden. Målstorleken 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 målstorleken omedelbart. Om ingen del av den logiska loggen finns kvar i de virtuella loggarna utöver målfilens målstorlek, DBCC SHRINKDATABASE kortas filen framgångsrikt och avslutas utan några meddelanden. Men om en del av den logiska loggen finns 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 åtgärderna för att flytta den logiska loggen ut ur de virtuella loggarna i slutet av filen. Efter att åtgärderna har körts, använd DBCC SHRINKDATABASE för att frigöra det återstående utrymmet.

Du kan bara krympa en loggfil till en virtuell loggfilgräns. Det är därför det inte är möjligt att krympa en loggfil till en storlek mindre än storleken på en virtuell loggfil. Database Engine väljer dynamiskt storleken på den virtuella loggfilen när loggfiler skapas eller utökas.

Förstå samtidighetsproblem med DBCC SHRINKDATABASE

Kommandona för att krympa databasen och förminska filen kan leda till samtidighetsproblem, särskilt vid aktivt underhåll som att bygga om index, eller i hektiska OLTP-miljöer.

Till exempel kan en användarfråga få ett schemastabilitetslås (Sch-S) på en Index Allocation Map (IAM)-sida och hålla den tills den är klar. Vid försök att återta utrymme vid vanlig användning kräver krympningsdatabas och förminskningsfiloperationer ett schema-modifieringslås (Sch-M) vid flytt eller borttagning av IAM-sidor, vilket blockerar de Sch-S lås som användarens frågor behöver. Som ett resultat kan långvariga frågor blockera en krympningsoperation. Detta beteende innebär också att varje ny fråga som kräver låsning Sch-S på en IAM-sida kan köas bakom krympoperationen, vilket ytterligare förvärrar detta samtidighetsproblem.

Introducerad i SQL Server 2022 (16.x), åtgärdar funktionen 'vänta vid låg prioritet för krympoperationer' detta problem genom att ta schema-modifieringslåset på IAM-sidor i lägetWAIT_AT_LOW_PRIORITY. Mer information finns i WAIT_AT_LOW_PRIORITY med krympningsåtgärder.

För mer information om Sch-S lås, Sch-M se Transaction locking and row versioning guide.

Metodtips

Tänk på följande information när du planerar att krympa en databas:

• En krympningsåtgärd är mest effektiv efter en åtgärd som skapar oanvänt utrymme, till exempel när man trunkerar en tabell eller utför en åtgärd för att ta bort en tabell.

• De flesta databaser kräver lite ledigt utrymme för den dagliga driften. Om du krymper en databasfil upprepade gånger och märker att databasstorleken växer igen, indikerar denna tillväxt att vanliga operationer kräver ledigt utrymme. I dessa fall är det kontraproduktivt att upprepade gånger krympa databasfilen. Den filtillväxt som krävs för att allokera nytt utrymme efter krympning kan hämma prestandan.

• En krympningsoperation bevarar inte fragmenteringstillståndet för index i databasen och kan öka indexfragmenteringen, vilket kan minska läs-I/O-genomströmningen för frågor som använder stora skanningar.

• Om du inte har ett specifikt krav ska du inte ange databasalternativet AUTO_SHRINK till ON.

• Om du behöver krympa datafilerna i en stor databas, överväg att använda PowerShell-skriptet ShrinkDriver . Skriptet automatiserar och förenklar förminskningsprocessen, vilket gör den till en enda, observerbar och återupptagbar operation. Skriptet krymper flera filer parallellt, försöker igen när det avbryts och ger detaljerade statusrapporter medan det körs.

Felsöka

En transaktion som körs under en radversionsbaserad isoleringsnivå kan blockera krympningsåtgärder. Till exempel kör DBCC SHRINKDATABASE du medan en stor borttagningsoperation under en radversionsbaserad isoleringsnivå pågår. I detta fall väntar förminskningsoperationen på att raderingsoperationen ska slutföras innan den krymper filerna. När krympåtgärden väntar skriver åtgärderna DBCC SHRINKFILE och DBCC SHRINKDATABASE ut ett informationsmeddelande (5202 för SHRINKDATABASE och 5203 för SHRINKFILE). Detta meddelande skrivs ut till SQL Server-felloggen var femte minut under den första timmen och sedan varje timme därefter. Om till exempel felloggen 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 ögonblickskopiska transaktioner med tidsstämplar äldre än 109 blockerar förminskningsoperationen. Den transaktionen är den sista transaktionen som krympningsåtgärden slutförde. Den anger också att kolumnerna transaction_sequence_num eller first_snapshot_sequence_num i den sys.dm_tran_active_snapshot_database_transactions dynamiska hanteringsvyn innehåller värdet 15. Kolumnen transaction_sequence_num eller first_snapshot_sequence_num i vyn kan innehålla ett tal som är mindre än den senaste transaktionen som slutfördes av en krympningsåtgärd (109). I så fall väntar krympprocessen på att transaktionerna ska slutföras.

För att lösa problemet kan du göra något av följande:

• Avsluta transaktionen som blockerar krympningsåtgärden.
• Avsluta krympningsåtgärden. Allt slutfört arbete behålls.
• Gör ingenting och låt krympningsåtgärden vänta tills den blockerande transaktionen har slutförts.

Behörigheter

Kräver medlemskap i sysadmin fast serverroll eller db_owner fast databasroll.

Exempel

Kodexemplen i den här artikeln använder AdventureWorks2025- eller AdventureWorksDW2025-exempeldatabasen, som du kan ladda ned från startsidan Microsoft SQL Server Samples och Community Projects.

A. Krymp en databas och ange en procentandel ledigt utrymme

I följande exempel minskar storleken på data och loggfiler i UserDB användardatabas så att det finns 10 procent ledigt utrymme i databasen.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Trunkera en databas

I följande exempel krymper data- och loggfilerna i AdventureWorks2025 exempeldatabasen till den senaste tilldelade omfattningen.

DBCC SHRINKDATABASE (AdventureWorks2025, TRUNCATEONLY);

C. Krymp en Azure Synapse Analytics-databas

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

D. Krymp en databas med WAIT_AT_LOW_PRIORITY

I följande exempel försöker du minska storleken på data och loggfiler i AdventureWorks2025 databas för att tillåta 20% ledigt utrymme i databasen. Om ett lås inte kan hämtas inom en minut avbryts krympningsåtgärden.

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

Relaterat innehåll

• Krymp en databas
• Krymp en fil
• DBCC KRYMPFIL (Transact-SQL)
• Överväganden för inställningarna för automatisk tillväxt och automatisk skalning i SQL Server
• Databasfiler och filgrupper
• sys.databaser (Transact-SQL)
• sys.database_files (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Hantera filutrymme för databaser i Azure SQL Database