Sdílet prostřednictvím

DBCC SHRINKDATABASE (Transact-SQL)

  • Článek

platí pro:SQL ServerAzure SQL Databaseazure SQL Managed Instanceazure Synapse Analytics

Zmenší velikost dat a souborů protokolu v zadané databázi.

Poznámka

Operace zmenšení by se neměly považovat za pravidelnou operaci údržby. Data a soubory protokolů, které se zvětšují z důvodu pravidelných opakovaných obchodních operací, nevyžadují operace zmenšení.

Transact-SQL konvence syntaxe

Syntaxe

Syntaxe SQL Serveru:

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 }

Syntaxe pro Azure Synapse Analytics:

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

Argumenty

database_name | database_id | 0

Název nebo ID databáze, které se mají zmenšit. Hodnota 0 určuje, že se používá aktuální databáze.

target_percent

Procento volného místa, které chcete nechat v databázovém souboru po dokončení operace zmenšení.

NOTRUNCATE

Přesune přiřazené stránky z konce souboru na nepřiřazené stránky před souborem. Tato akce zkomprimuje data v souboru. target_percent je nepovinný. Azure Synapse Analytics tuto možnost nepodporuje.

Volné místo na konci souboru se nevrátí do operačního systému a fyzická velikost souboru se nezmění. Databáze se proto při zadávání NOTRUNCATEzdá, že se nezmenšuje.

NOTRUNCATE se vztahuje pouze na datové soubory. NOTRUNCATE nemá vliv na soubor protokolu.

TRUNCATEONLY

Uvolní veškeré volné místo na konci souboru do operačního systému. Nepřesune žádné stránky uvnitř souboru. Datový soubor se zmenší pouze do posledního přiřazeného rozsahu. Ignoruje target_percent, pokud je zadána pomocí TRUNCATEONLY. Azure Synapse Analytics tuto možnost nepodporuje.

DBCC SHRINKDATABASE s možností TRUNCATEONLY ovlivňuje pouze soubor protokolu transakcí databáze. Pokud chcete datový soubor zkrátit, použijte místo toho DBCC SHRINKFILE. Další informace naleznete v tématu DBCC SHRINKFILE.

WITH NO_INFOMSGS

Potlačí všechny informační zprávy, které mají úrovně závažnosti od 0 do 10.

WAIT_AT_LOW_PRIORITY s operacemi zmenšení

platí pro: SQL Server 2022 (16.x) a novější verze, Azure SQL Database, Azure SQL Managed Instance

Funkce čekání s nízkou prioritou snižuje kolize zámků. Další informace naleznete v tématu Porozumění problémům souběžnosti s DBCC SHRINKDATABASE.

Tato funkce je podobná WAIT_AT_LOW_PRIORITY při online operacích s indexy, ačkoli s několika rozdíly.

  • Nelze zadat možnost ABORT_AFTER_WAITNONE.

Čekat s nízkou prioritou

Když se příkaz pro zmenšení spustí v režimu WAIT_AT_LOW_PRIORITY, nebudou nové dotazy vyžadující stabilitu schématu (Sch-S) zablokované operací čekání na zmenšení, dokud operace zmenšení nepřestane čekat a nespustí se. Operace zmenšení se provede, když dokáže získat zámek změny schématu (Sch-M). Pokud nová operace zmenšení v režimu WAIT_AT_LOW_PRIORITY nemůže získat zámek kvůli dlouhotrvajícímu dotazu, operace zmenšení nakonec vyprší po 1 minutě a ukončí se bez chyby.

Pokud nová operace zmenšení v režimu WAIT_AT_LOW_PRIORITY nemůže získat zámek kvůli dlouhotrvajícímu dotazu, operace zmenšení nakonec ve výchozím nastavení vyprší po 1 minutě a ukončí se bez chyby. K tomu dochází v případě, že operace zmenšení nemůže získat zámek Sch-M kvůli souběžnému dotazu nebo dotazům, které uchovávají Sch-S zámky. Když dojde k vypršení časového limitu, odešle se chyba 49516 do protokolu chyb SQL Serveru, například: 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. Opakujte operaci zmenšení v režimu WAIT_AT_LOW_PRIORITY.

ABORT_AFTER_WAIT = [ SELF | BLOKÁTORY ]

  • JÁ

    SELF je výchozí možností. Ukončete operaci zmenšení databáze, která se právě spouští, aniž byste provedli žádnou akci.

  • BLOKÁTORY

    Ukončete všechny uživatelské transakce, které blokují operaci zmenšení databáze, aby operace nemohla pokračovat. Možnost BLOCKERS vyžaduje, aby přihlášení měla oprávnění ALTER ANY CONNECTION.

Sada výsledků

Následující tabulka popisuje sloupce v sadě výsledků.

Název sloupce Popis
DbId Identifikační číslo souboru, který se databázový stroj pokusil zmenšit.
FileId Identifikační číslo souboru, který se databázový stroj pokusil zmenšit.
CurrentSize Počet 8 kB stránek, které soubor aktuálně zabírá.
MinimumSize Minimálně počet 8 kB stránek, které může soubor zabírat. Tato hodnota odpovídá minimální velikosti nebo původně vytvořené velikosti souboru.
UsedPages Počet stránek, které soubor aktuálně používá, je 8 kB.
EstimatedPages Počet 8 KB stránek, na které databázový stroj odhaduje, že by mohlo dojít ke zmenšení souboru.

Poznámka

Databázový stroj nezobrazuje řádky pro soubory, které nejsou zmenšeny.

Poznámky

Pokud chcete zmenšit všechna data a soubory protokolu pro konkrétní databázi, spusťte příkaz DBCC SHRINKDATABASE. Pokud chcete zmenšit data nebo soubor protokolu najednou pro konkrétní databázi, spusťte příkaz DBCC SHRINKFILE.

Pokud chcete zobrazit aktuální množství volného (nepřiděleného) místa v databázi, spusťte sp_spaceused.

DBCC SHRINKDATABASE operace je možné kdykoli v procesu zastavit a veškerá dokončená práce se zachová.

Databáze nemůže být menší než nakonfigurovaná minimální velikost databáze. Minimální velikost zadáte při původním vytvoření databáze. Nebo minimální velikost může být poslední nastavená explicitně pomocí operace změny velikosti souboru. Příkladem operací, jako jsou DBCC SHRINKFILE nebo ALTER DATABASE, jsou operace změny velikosti souboru.

Představte si, že databáze je původně vytvořená s velikostí 10 MB. Pak se zvětšuje na 100 MB. Nejmenší velikost databáze je možné snížit na 10 MB, i když byla odstraněna všechna data v databázi.

Při spuštění DBCC SHRINKDATABASEzadejte možnost NOTRUNCATE nebo možnost TRUNCATEONLY . Pokud ne, výsledek je stejný, jako kdybyste spustili operaci DBCC SHRINKDATABASE s NOTRUNCATE následovanou spuštěním operace DBCC SHRINKDATABASE s TRUNCATEONLY.

Zmenšená databáze nemusí být v jednouživatelském režimu. Ostatní uživatelé mohou pracovat v databázi, když se zmenšuje, včetně systémových databází.

Databázi nemůžete zmenšit, když se databáze zálohuje. Naopak nemůžete zálohovat databázi, zatímco probíhá operace zmenšení databáze.

Při specifikaci s WAIT_AT_LOW_PRIORITY bude požadavek na uzamčení Sch-M v operaci zmenšení čekat s nízkou prioritou při provádění příkazu po dobu jedné minuty. Pokud je operace blokovaná po celou dobu trvání, bude provedena specifikovaná akce ABORT_AFTER_WAIT.

Ve fondech Azure Synapse SQL se nedoporučuje spustit příkaz pro zmenšení, protože se jedná o operaci náročnou na vstupně-výstupní operace a může převést vyhrazený fond SQL (dříve SQL DW) do offline režimu. Po spuštění tohoto příkazu budou mít snímky datového skladu finanční dopady.

Známé problémy

platí pro: SQL Server, Azure SQL Database, Azure SQL Managed Instance, vyhrazený fond SQL služby Azure Synapse Analytics

  • Sloupce používající datové typy LOB (varbinary(max), varchar(max)a nvarchar(max)) v komprimovaných segmentech columnstore nejsou ovlivněny DBCC SHRINKDATABASE a DBCC SHRINKFILE.

Jak DBCC SHRINKDATABASE funguje

DBCC SHRINKDATABASE zmenší datové soubory na základě jednotlivých souborů, ale zmenší soubory protokolu, jako by všechny soubory protokolů existovaly v jednom souvislém fondu protokolů. Soubory se vždy zmenšují od konce.

Předpokládejme, že máte několik souborů protokolu, datový soubor a databázi s názvem mydb. Soubory dat a protokolů jsou 10 MB a datový soubor obsahuje 6 MB dat. Databázový stroj vypočítá cílovou velikost každého souboru. Tato hodnota je velikost, na kterou se má soubor zmenšit. Pokud zadáte DBCC SHRINKDATABASE s target_percent, databázový stroj vypočítá cílovou velikost tak, aby množství volného místa v souboru po zmenšení bylo target_percent.

Pokud například zadáte target_percent 25 pro zmenšení mydb, databázový stroj vypočítá cílovou velikost datového souboru na 8 MB (6 MB dat plus 2 MB volného místa). Databázový stroj například přesune všechna data z posledních 2 MB datového souboru do libovolného volného místa v prvním 8 MB datového souboru a pak soubor zmenší.

Předpokládejme, že datový soubor mydb obsahuje 7 MB dat. Specifikace target_percent hodnoty 30 umožňuje, aby se tento datový soubor zmenšil na 30% volného prostoru. Pokud ale zadáte target_percent 40, nezmenší se datový soubor, protože v aktuální celkové velikosti datového souboru nelze vytvořit dostatek volného místa.

Tento problém si můžete představit jiným způsobem: 40 % chtělo volné místo + 70 % plný datový soubor (7 MB z 10 MB) je více než 100 procent. Jakýkoli target_percent větší než 30 nezmenší datový soubor. Nesmrští se, protože součet požadovaného procenta volného místa a aktuálního procenta, které datový soubor zabírá, přesahuje 100 procent.

Pro soubory protokolu používá Databázový stroj target_percent k výpočtu cílové velikosti pro celý protokol. Proto target_percent představuje množství volného místa v logu po operaci zmenšení. Cílová velikost celého protokolu se pak přeloží na cílovou velikost každého souboru protokolu.

DBCC SHRINKDATABASE se pokusí okamžitě zmenšit každý fyzický soubor protokolu na cílovou velikost. Řekněme, že žádná část logického protokolu nezůstane ve virtuálních protokolech za cílovou velikostí souboru protokolu. Potom se soubor úspěšně zkrátí a DBCC SHRINKDATABASE dokončí bez jakýchkoli zpráv. Pokud ale část logického protokolu zůstane ve virtuálních protokolech nad cílovou velikostí, databázový stroj uvolní co nejvíce místa a pak vydá informační zprávu. Tato zpráva popisuje, jaké akce jsou potřeba k přesunutí logického protokolu z virtuálních protokolů na konci souboru. Po spuštění akcí můžete DBCC SHRINKDATABASE použít k uvolnění zbývajícího místa.

Soubor protokolu je možné zmenšit pouze na hranici virtuálního souboru protokolu. To je důvod, proč zmenšení souboru protokolu na menší velikost, než je velikost virtuálního souboru protokolu, nemusí být možné. Nemusí to být možné, ani když se nepoužívá. Velikost souboru virtuálního protokolu je dynamicky zvolena databázovým strojem při vytváření nebo rozšíření souborů protokolu.

Vysvětlení problémů souběžnosti s DBCC SHRINKDATABASE

Příkazy pro zmenšení databáze a zmenšení souborů můžou vést k problémům se souběžností, zejména při aktivní údržbě, jako je opětovné sestavení indexů nebo v zaneprázdněných prostředích OLTP. Když vaše aplikace spustí dotazy na databázové tabulky, tyto dotazy získají a udržují zámek stability schématu (Sch-S), dokud dotazy nebudou dokončeny jejich operace. Při pokusu o uvolnění místa během pravidelného používání v současné době operace zmenšení databáze a zmenšení souborů vyžadují zámek schématu (Sch-M) při přesouvání nebo odstraňování stránek mapování přidělení indexů (IAM), čímž blokují zámky Sch-S potřebné pro uživatelské dotazy. Dlouhotrvající dotazy proto zablokují operaci zmenšení, dokud se tyto dotazy nedokončí. To znamená, že všechny nové dotazy vyžadující Sch-S zámky se také zařadí do fronty za čekající operaci zmenšení a budou také blokovány, což dále zhorší tento problém souběžnosti. To může výrazně ovlivnit výkon dotazů aplikace a může také způsobit potíže s dokončením potřebné údržby pro zmenšení databázových souborů. Funkce čekání při zmenšování s nízkou prioritou (WLP) v SQL Serveru 2022 (16.x) řeší tento problém tím, že přebírá zámek úprav schématu v módu WAIT_AT_LOW_PRIORITY. Další informace naleznete v části WAIT_AT_LOW_PRIORITY se zmenšovacími operacemi.

Další informace o Sch-S a zámkech Sch-M naleznete v tématu Průvodce uzamčením transakcí a správa verzí řádků.

Osvědčené postupy

Při plánování zmenšení databáze zvažte následující informace:

  • Operace zmenšení je nejúčinnější po operaci, která vytváří nevyužité místo, například po operaci zkrácení tabulky nebo operaci zrušení tabulky.
  • Většina databází vyžaduje, aby bylo k dispozici nějaké volné místo pro běžné každodenní operace. Pokud zmenšíte soubor databáze opakovaně a všimněte si, že se velikost databáze znovu zvětší, znamená to, že pro běžné operace se vyžaduje volné místo. V těchto případech je opakované zmenšení souboru databáze plýtvání operací. Události automatického růstu potřebné k rozšíření databázového souboru omezují výkon.
  • Operace zmenšení nezachovává stav fragmentace indexů v databázi a obecně zvyšuje fragmentaci do určité míry. Tento výsledek je dalším důvodem, proč databázi opakovaně nezmenšovat.
  • Pokud nemáte konkrétní požadavek, nenastavujte možnost AUTO_SHRINK databáze na hodnotu ZAPNUTO.

Řešení potíží

Je možné zablokovat operace zmenšení transakcí, která běží pod izolací na úrovni verzování řádků . Například probíhá velká operace odstranění spuštěná pod úrovní izolace na základě správy verzí na řádku při spuštění operace DBCC SHRINKDATABASE. Pokud k této situaci dojde, operace zmenšení čeká na dokončení operace odstranění, než zmenší soubory. Při čekání na operaci zmenšení zobrazí operace DBCC SHRINKFILE a DBCC SHRINKDATABASE informační zprávu (5202 pro SHRINKDATABASE a 5203 pro SHRINKFILE). Tato zpráva se vytiskne do protokolu chyb SQL Serveru každých pět minut v první hodině a potom každé nadcházející hodině. Pokud například protokol chyb obsahuje následující chybovou zprávu:

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.

Tato chyba znamená, že operace zmenšení zablokuje transakce snímků, které mají časové razítko starší než 109. Tato transakce je poslední transakce, kterou operace zmenšení dokončila. Označuje také, že sloupce transaction_sequence_num nebo first_snapshot_sequence_num v sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) zobrazení dynamického řízení obsahují hodnotu 15. Sloupec transaction_sequence_num nebo first_snapshot_sequence_num v zobrazení může obsahovat číslo, které je menší než poslední transakce dokončená operací zmenšení (109). Pokud ano, operace zmenšení čeká na dokončení těchto transakcí.

Pokud chcete tento problém vyřešit, můžete provést jednu z následujících úloh:

  • Ukončete transakci, která blokuje operaci zmenšení.
  • Ukončete operaci zmenšení. Veškerá dokončená práce se uchovává.
  • Nedělejte nic a nechte operaci zmenšení čekat, dokud se blokující transakce nedokončí.

Dovolení

Vyžaduje členství v pevné roli serveru sysadmin nebo v pevné databázové roli db_owner.

Příklady

A. Zmenšení databáze a zadání procenta volného místa

Následující příklad zmenšuje velikost dat a souborů protokolu v uživatelské databázi UserDB tak, aby umožňovala 10% volné místo v databázi.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Zkraťte databázi

Následující příklad zmenší data a soubory protokolu v ukázkové databázi AdventureWorks2022 do posledního přiřazeného rozsahu.

DBCC SHRINKDATABASE (AdventureWorks2022, TRUNCATEONLY);

C. Zmenšení databáze Azure Synapse Analytics

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

D. Zmenšení databáze pomocí WAIT_AT_LOW_PRIORITY

Následující příklad se pokusí zmenšit velikost dat a souborů protokolu v databázi AdventureWorks2022 tak, aby umožňovala 20% volného místa v databázi. Pokud se zámek nedá získat během jedné minuty, operace zmenšení se zastaví.

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

Související obsah