Správa prostoru databázových souborů v Azure SQL Database

Platí pro:Azure SQL Database

• Azure SQL Database
• Spravovaná instance Azure SQL

Tento článek popisuje různé typy úložného prostoru pro databáze ve službě Azure SQL Database. Občas možná budete muset explicitně spravovat přidělený prostor souborů. Tento článek obsahuje kroky, jak toho dosáhnout.

Přehled

Některé vzorce pracovní zátěže mohou způsobit, že prostor přidělený datovým souborům přesáhne využitý prostor. Tato podmínka nastává, když se objem využitého prostoru zvětšuje kvůli růstu dat, ale později data smažete nebo komprimujete. Přidělený, ale nevyužitý prostor není automaticky získán zpět, protože rekultivace je náročná na zdroje a zpomalila by budoucí růst souborů.

V následujících scénářích možná budete muset zmenšit datové soubory a získat zpět nevyužité místo:

• Umožnit růst dat pro databáze v elastickém poolu, když velký přidělený prostor pro některé databáze způsobí, že pool se blíží své maximální velikosti.
• Umožnit snížení maximální velikosti jedné databáze nebo elastického poolu.
• Pro změnu databáze nebo elastického poolu na úroveň s nižším limitem maximální velikosti.
• Snížit náklady na úložiště při používání servisní vrstvy Hyperscale.

Upozornění

Nepovažujte zmenšovací operace za běžnou údržbu. Data a soubory protokolů, které se zvětšují kvůli pravidelným opakovaným obchodním operacím, nevyžadují operace zmenšení.

Monitorování využití místa na souborech

API Azure Resource Manager (ARM), včetně PowerShell get-metrics, vracejí použitý a přidělený prostor pro databáze a elastické pooly.

Následující systémové pohledy také vracejí velikost využitého a přiděleného prostoru pro databáze a elastické pooly:

• sys.resource_stats
• sys.elastic_pool_resource_stats
• sys.dm_elastic_pool_resource_stats

Pochopit typy úložného prostoru pro databázi

Pro správu prostoru souborů databáze je důležité porozumět následujícímu množství úložného prostoru.

Množství v databázi	Definice	Komentáře
Využité datové místo	Množství místa potřebného k ukládání dat.	Obecně platí, že se při vkládání (odstranění) zvyšuje využité místo (snižuje). V některých případech se využité místo při vkládání nebo odstraňování nemění v závislosti na množství a vzoru dat zahrnutých v operaci a jakékoli fragmentaci. Například odstranění jednoho řádku z každé datové stránky nemusí nutně snížit využité místo.
Přidělený datový prostor	Množství úložného prostoru zabíraného datovými soubory.	Množství přiděleného místa automaticky roste, ale po smazání se nikdy automaticky nezmenšuje. Toto chování zajišťuje, že budoucí vkládání bude rychlejší, protože není nutné znovu přidělovat místo.
Přidělený datový prostor, ale nevyužitý	Rozdíl mezi velikostí přiděleného datového prostoru a využitou velikostí datového prostoru.	Tato velikost představuje maximální objem volného prostoru, který je možné získat zpět zmenšením datových souborů databáze.
Maximální velikost dat	Maximální množství místa, které lze využít pro ukládání dat.	Množství přiděleného datového prostoru se nemůže zvětšit nad rámec maximální velikosti dat.

Následující diagram znázorňuje vztah mezi různými typy prostoru úložiště pro databázi.

Dotazování na jednoúčelovou databázi s informacemi o prostoru souborů

Pomocí následujícího dotazu na sys.database_files vrátíte přidělený prostor databázového souboru a přidělené množství nevyužitého místa.

-- Connect to a user database
SELECT file_id,
       type_desc,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS DECIMAL (19, 4)) * 8 / 1024. AS space_used_mb,
       CAST (size / 128.0 - CAST (FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS DECIMAL (19, 4)) AS space_unused_mb,
       CAST (size AS DECIMAL (19, 4)) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS DECIMAL (19, 4)) * 8 / 1024. AS max_size_mb
FROM sys.database_files;

Pochopit typy úložného prostoru pro elastický fond

Pochopení následujících hodnot úložného prostoru je důležité pro správu souborového prostoru elastického fondu.

Počet elastických poolů	Definice	Komentáře
Využité datové místo	Součet datového prostoru používaného všemi databázemi v elastickém fondu.
Přidělený datový prostor	Součet úložného prostoru zabíraného datovými soubory ve všech databázích v elastickém poolu.
Přidělený datový prostor, ale nevyužitý	Rozdíl mezi velikostí přiděleného datového prostoru a využitou velikostí datového prostoru používaného všemi databázemi v elastickém fondu.	Tato velikost představuje maximální objem prostoru přiděleného pro elastický fond, který je možné získat zpět zmenšením datových souborů databáze.
Maximální velikost dat	Maximální objem datového prostoru, který elastický fond používá pro všechny své databáze.	Prostor vyhrazený pro elastický bazén by neměl přesáhnout maximální velikost elastického bazénu. Pokud nastane tento stav, lze alokované, ale nevyužité datové soubory získat zpět zmenšováním datových souborů.

Chybová zpráva "Elastický pool dosáhl svého limitu úložiště" uvádí, že databázové objekty zabírají dostatek místa na splnění maximálního limitu velikosti úložiště elastického poolu. Zvažte zvýšení limitu úložiště nebo uvolnění datového prostoru, jak je popsáno v článku Získat nevyužitý přidělený prostor.

Dotazování elastického fondu na informace o prostoru úložiště

Použijte následující dotazy k určení množství úložného prostoru pro elastický pool.

Využitý datový prostor elastického fondu

Použijte následující příklad dotazu k vrácení množství použitého datového prostoru elastického poolu. Upravte parametr názvu elastického poolu tak, aby odpovídal názvu vašeho poolu.

-- Connect to master
SELECT TOP (1) avg_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS elastic_pool_space_used_mb,
               avg_allocated_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS elastic_pool_space_allocated_mb,
               elastic_pool_storage_limit_mb AS elastic_pool_maximum_size_mb
FROM sys.elastic_pool_resource_stats
WHERE elastic_pool_name = 'ep1'
ORDER BY end_time DESC;

Uvolnění nevyužitého přiděleného místa

Důležité

Operace zmenšování spotřebovávají zdroje a mohou ovlivnit výkon databáze během provozu. Pokud je to možné, během období nízkého používání spouštějte snižovací režim.

Zmenšení datových souborů

Protože zmenšování datových souborů může ovlivnit výkon databáze, Azure SQL Database automaticky nezmenšuje datové soubory. Pokud je to nutné, můžete datové soubory zmenšit podle svého výběru. Neprovádějte zmenšování jako pravidelně plánovanou činnost. Místo toho zvažte jeho použití až po výrazném snížení využitého prostoru.

Tip

Neplýtvejte výpočetními zdroji a časem na zmenšování datových souborů, pokud běžná zátěž aplikace způsobí, že soubory opět narostou na stejnou přidělenou velikost.

Ke zmenšení souborů použijte buď příkazy T-SQL DBCC SHRINKDATABASE, nebo DBCC SHRINKFILE:

• DBCC SHRINKDATABASE zmenší všechna data a logovací soubory v databázi jediným příkazem. Příkaz zmenší jeden datový soubor najednou, což může trvat delší dobu pro větší databáze. Také zmenší soubor protokolu, což je obvykle zbytečné, protože "Azure SQL Database" zmenšuje soubory protokolů automaticky podle potřeby.
• DBCC SHRINKFILE příkaz podporuje pokročilejší scénáře:
  • Podle potřeby může cílit na jednotlivé soubory místo zmenšení všech souborů v databázi.
  • Každý příkaz DBCC SHRINKFILE může běžet paralelně s ostatními příkazy DBCC SHRINKFILE, aby se zkrátila celková doba operace zmenšení, ovšem za cenu vyššího využití prostředků a vyšší pravděpodobnosti dočasného blokování uživatelských dotazů a souběžně spuštěných příkazů DBCC SHRINKFILE.
  • Pokud konec souboru neobsahuje data, můžete alokovanou velikost souboru snížit rychleji specifikací TRUNCATEONLY argumentu. TRUNCATEONLY Nevyžaduje pohyb dat v souboru, ale ani tolik nesnižuje alokovanou velikost.
• Další informace o těchto příkazech viz DBCC SHRINKDATABASE a DBCC SHRINKFILE.

Následující příklady spusťte připojené k cílové uživatelské databázi, nikoli k databázi master .

Použít DBCC SHRINKDATABASE ke zmenšení všech datových a protokolových souborů v dané databázi:

DBCC SHRINKDATABASE (N'database_name');

Databáze může obsahovat jeden nebo více datových souborů, které se automaticky vytvářejí s růstem dat. Pro určení rozložení souborů vaší databáze, včetně použité a přidělené velikosti každého souboru, dotazujte se do sys.database_files katalogového zobrazení pomocí následujícího ukázkového skriptu:

-- Review file properties, including the file_id and name values to use in shrink commands
SELECT file_id,
       name,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS BIGINT) * 8 / 1024. AS space_used_mb,
       CAST (size AS BIGINT) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS BIGINT) * 8 / 1024. AS max_file_size_mb
FROM sys.database_files
WHERE type_desc IN ('ROWS', 'LOG');

Pro zmenšení jednoho souboru použijte například příkaz:DBCC SHRINKFILE

-- Shrink database data file named 'data_0` by removing all unused at the end of the file, if any.
DBCC SHRINKFILE ('data_0', TRUNCATEONLY);

Zmenšení souboru transakčního protokolu

Služba Azure SQL Database, na rozdíl od datových souborů, automaticky zmenšuje soubor transakčního protokolu, aby zabránila nadměrnému zabírání místa, které vede k chybám způsobeným nedostatkem místa. Ve většině případů nemusíte zmenšovat soubor transakčního protokolu.

V úrovních služeb Premium a Business Critical může v případě, že se protokol transakcí zvětší, výrazně zvýšit využití místního úložiště až k limitu maximálního místního úložiště. Pokud je spotřeba lokálního úložiště blízko limitu, můžete zvolit zmenšení transakčního logu pomocí DBCC SHRINKFILE příkazu, jak je ukázáno v následujícím příkladu. Tím se uvolní místní úložiště, jakmile se příkaz dokončí, aniž byste čekali na pravidelnou automatickou operaci zmenšení.

Spusť následující příklad při připojení k cílové uživatelské databázi, nikoli k databázi master .

-- Shrink the database log file (always file_id 2), by removing all unused space at the end of the file, if any.
DBCC SHRINKFILE (2, TRUNCATEONLY);

Automatické zmenšení

Jako alternativu k ručnímu zmenšení datových souborů je možné pro databázi povolit automatické zmenšení. Automatické zmenšení však může být méně efektivní při uvolnění místa na souboru než DBCC SHRINKDATABASE a DBCC SHRINKFILE.

Ve výchozím nastavení je automatické zmenšení zakázané, což se doporučuje pro většinu databází. Pokud je nutné zapnout automatické zmenšování, doporučuje se ho vypnout po dosažení cílů správy prostoru, místo aby byl zapnutý trvale. Další informace najdete v části Důležité informace o možnosti AUTO_SHRINK.

Například automatické zmenšování může být užitečné, pokud elastický pool obsahuje mnoho databází, které neustále zaznamenávají výrazný růst a zmenšování využitého prostoru, což způsobuje, že se pool blíží svému maximálnímu limitu velikosti. Tento scénář není běžný.

Možnost automatického zmenšování databáze nemá v databázích Hyperscale žádný vliv.

Pokud chcete povolit automatické zmenšení, spusťte při připojení k databázi následující příkaz (ne databázi master ).

-- Enable auto-shrink for the current database.
ALTER DATABASE CURRENT
    SET AUTO_SHRINK ON;

Další informace o tomto příkazu naleznete v tématu MOŽNOSTI SADY DATABÁZE.

Údržba indexu po zmenšení

Po dokončení operace zmenšení se indexy mohou rozpadnout. U většiny pracovních zátěží na moderních platformách pravděpodobně fragmentace indexu výkon neovlivní. U pracovních zátěží využívajících velké indexové skenování může fragmentace snížit propustnost čtení I/O. Pokud po dokončení operace zmenšení dojde ke zhoršení výkonu, zvažte údržbu indexu za účelem obnovy nebo reorganizace indexů. Přestavby indexů vyžadují volné místo v databázi, takže mohou způsobit zvětšení přiděleného prostoru, čímž se vyrovná efekt zmenšení.

Další informace o údržbě indexů naleznete v tématu Optimalizace údržby indexů za účelem zlepšení výkonu dotazů a snížení spotřeby prostředků.

Zmenšení velkých databází

Když je přidělený prostor v databázi ve stovkách gigabajtů nebo více, zmenšování může trvat dlouho. Operace zmenšování mohou trvat hodiny, dny nebo týdny u databází o velikosti více terabajtů. Tato sekce popisuje optimalizace procesů a osvědčené postupy, které činí tento proces efektivnějším a méně dopadným na pracovní zátěž aplikací.

Tip

ShrinkDriver je PowerShell skript, který automatizuje a zjednodušuje proces zmenšování u velkých databází, čímž jej proměňuje v jedinou, pozorovatelnou a obnovovatelnou operaci. Skript zmenšuje více souborů paralelně, při přerušení se znovu pokusí a během běhu generuje podrobné hlášení o stavu.

Zachycení základního stavu využívání prostoru

Před zahájením zmenšení zachyťte aktuální využité a přidělené místo v každém databázovém souboru spuštěním následujícího dotazu na využití místa:

SELECT file_id,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS BIGINT) * 8 / 1024. AS space_used_mb,
       CAST (size AS BIGINT) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS BIGINT) * 8 / 1024. AS max_size_mb
FROM sys.database_files
WHERE type_desc = 'ROWS';

Po dokončení zmenšení můžete tento dotaz znovu spustit a porovnat výsledek s původním stavem.

Zkrácejte datové soubory pro rychlý, ale omezený zisk

Pokud chcete rychle snížit přidělený prostor, zvažte provedení DBCC SHRINKFILE s parametrem TRUNCATEONLY . Pokud je na konci souboru přidělené, ale nevyužité místo, operace toto místo rychle odstraní bez jakéhokoliv pohybu dat.

Nicméně je nepoužívejte TRUNCATEONLY pokud je vaším cílem maximalizovat snížení přiděleného prostoru. Abyste toho dosáhli, musíte provést celý proces smršťování, jak je popsán později v této části. Protože tento proces na konci soubory ořezává, samostatné zmenšení pomocí TRUNCATEONLY nepřináší žádný užitek.

Následující příklad příkazu zkracuje ID souboru 4:

DBCC SHRINKFILE (4, TRUNCATEONLY);

Po spuštění tohoto příkazu pro každý datový soubor znovu spusťte dotaz na využití prostoru, abyste viděli snížení přiděleného prostoru, pokud nějaké je. Přidělený prostor pro databázi si můžete také prohlédnout v portálu Azure.

Vyhodnotit hustotu indexové stránky

Jako volitelný, ale doporučený krok je určit průměrnou hustotu stránek indexů v databázi. Při stejném množství dat operace zmenšování dokončí rychleji, pokud je hustota stránek vysoká, protože operace přesune méně stránek v rámci každého souboru. Pokud je hustota stránky u některých indexů nízká, zvažte údržbu těchto indexů, abyste před zmenšením datových souborů zvýšili hustotu stránky. Vyšší hustota stránek umožňuje funkci shrink dosáhnout výraznějšího snížení přiděleného úložného prostoru.

Pokud chcete určit hustotu stránky pro všechny indexy v databázi, použijte následující dotaz. Hustota stránky se vyhlásí ve sloupci avg_page_space_used_in_percent .

SELECT OBJECT_SCHEMA_NAME(ips.object_id) AS schema_name,
       OBJECT_NAME(ips.object_id) AS object_name,
       i.name AS index_name,
       i.type_desc AS index_type,
       ips.avg_page_space_used_in_percent,
       ips.avg_fragmentation_in_percent,
       ips.page_count,
       ips.alloc_unit_type_desc,
       ips.ghost_record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), DEFAULT, DEFAULT, DEFAULT, 'SAMPLED') AS ips
     INNER JOIN sys.indexes AS i
         ON ips.object_id = i.object_id
        AND ips.index_id = i.index_id
ORDER BY page_count DESC;

Pokud existují indexy s vysokým počtem stran (jak je uvedeno ve sloupci page_count ), které mají hustotu stránek nižší než 60–70%, zvažte přestavbu nebo reorganizaci těchto indexů před zmenšením datových souborů.

U větších databází může dokončení dotazu na určení hustoty stránky trvat dlouhou dobu. Opětovné sestavení nebo změna uspořádání velkých indexů také vyžaduje značné množství času a využití prostředků. Údržba indexu před zmenšením ale může zkrátit dobu trvání a dosáhnout vyšších úspor místa.

Pokud existuje více indexů s nízkou hustotou stránky, můžete je paralelně znovu sestavit v několika databázových relacích, aby se proces urychlil. Nicméně se ujistěte, že tím nepřekračujete limity databázových zdrojů. Ponechte dostatečné prostředky pro aplikace, které mohou být spuštěné. Sledujte spotřebu prostředků (CPU, Data IO, Log IO) na portálu Azure nebo pomocí zobrazení sys.dm_db_resource_stats. Začněte další indexové operace pouze tehdy, pokud využití zdrojů na každé z těchto dimenzí zůstává výrazně nižší než 100%.

Příklad příkazu pro obnovení indexu

Následující příklad příkazu používá příkaz ALTER INDEX k obnovení indexu a zvýšení jeho hustoty stránky:

ALTER INDEX [index_name] ON [schema_name].[table_name]
REBUILD WITH (
    FILLFACTOR = 100, MAXDOP = 8, ONLINE = ON (
        WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = NONE)),
    RESUMABLE = ON
);

Tento příkaz zahájí online a obnovitelné opětovné sestavení indexu. Tato operace umožňuje souběžným úlohám pokračovat v používání tabulky, zatímco probíhá opětovné sestavení, a umožňuje obnovení opětovného sestavení, pokud se z nějakého důvodu přeruší. Tento typ opětovného sestavení je však pomalejší než offline opětovné sestavení, které blokuje přístup k tabulce. Pokud během opětovného sestavení nemusí k tabulce přistupovat žádné jiné úlohy, nastavte možnosti ONLINE a RESUMABLE na OFF a odeberte klauzuli WAIT_AT_LOW_PRIORITY.

Další informace o údržbě indexů najdete v tématu Optimalizace údržby indexů za účelem zlepšení výkonu dotazů a snížení spotřeby prostředků.

Reorganizujte indexy před zmenšením

Reorganizace indexů před zmenšením může operaci zmenšování výrazně zrychlit ve dvou scénářích.

1. Pokud databáze splňuje všechna následující kritéria:

   • Má velké množství datových souborů (více než 10).
   • Má velké množství tabulek v databázi (několik stovek a více), které společně využívají velké množství prostoru (stovky gigabajtů a více).
   • Z některých tabulek je odstraněno velké množství dat.

   U takových databází reorganizace indexů v tabulkách, kde jste data smazali, zkracuje dlouhou fázi procesu zmenšování.

2. Pokud databáze obsahuje:

   • Velké objektové (LOB) datové typy jako varchar(max),nvarchar(max),varbinary(max), xml nebo podobné datové typy uložené v alokační LOB_DATA jednotce.
   • Velké řádky uložené v ROW_OVERFLOW_DATA alokační jednotce
   • Indexy Columnstore.

   Aby zmenšování běželo rychleji a uvolnilo více místa v tomto případě, nezapomeňte při reorganizaci indexů zahrnout klauzuli LOB_COMPACTION . Komprimace LOB před zmenšením se doporučuje pro všechny indexy, které obsahují sloupce LOB nebo velké řádky.

   Změna uspořádání nebo opětovného sestavení indexů columnstore před zmenšením může podobně zvýšit rychlost a efektivitu zmenšení.

Následující příklad ukazuje příkaz pro reorganizaci indexu a provedení kompakace LOB:

ALTER INDEX [index_name] ON [schema_name].[table_name]
REORGANIZE WITH(LOB_COMPACTION = ON);

Zmenšujte více datových souborů paralelně

Operace zmenšování, která vyžaduje přesun dat, je dlouhodobý proces. Pokud databáze obsahuje více datových souborů, můžete proces urychlit zmenšením několika datových souborů paralelně. Otevřete více databázových relací a v každé relaci použijte DBCC SHRINKFILE s jinou hodnotou file_id. Podobně jako při opětovném sestavení indexů se ujistěte, že máte dostatečnou rezervu zdrojů (CPU, vstupně-výstupní operace dat, vstupně-výstupní operace protokolu) před zahájením každého nového příkazu paralelního zmenšení.

Následující příklad příkazu zmenšuje ID souboru 4 a snaží se zmenšit jeho přidělenou velikost na 52 000 MB:

DBCC SHRINKFILE (4, 52000);

Pro minimalizaci přiděleného prostoru pro soubor spusťte příkaz bez specifikace cílové velikosti:

DBCC SHRINKFILE (4);

Pokud spustíte příliš mnoho paralelních operací zmenšení, můžete zaznamenat vysoké využití prostředků a kolize zámků mezi operacemi zmenšení. Ve většině scénářů je optimální počet paralelních operací zmenšování v rozmezí čtyř až osm.

Zmenšujte po krocích

Pokud se operace zmenšení neočekávaně zastaví (například kvůli plánované nebo neplánované údržbě), může úloha začít využívat místo uvolněné operací zmenšení ještě předtím, než tato operace zkrátí soubor, a tím se může ztratit část dosavadního pokroku, kterého operace zmenšení dosáhla. Protože zmenšování často trvá dlouho, je větší pravděpodobnost přerušení.

Aby se tomuto problému vyhnuli, zkracujte každý soubor v menších, postupných krocích. V příkazu DBCC SHRINKFILE nastavte cíl, který je menší než aktuálně přidělený prostor pro soubor, ale větší než použitý prostor, který dotaz na využití prostoru na základní linii vrací.

Například pokud je vyhrazený prostor pro ID souboru 4 200 000 MB a chcete ho zmenšit na 100 000 MB, můžete nejprve nastavit cíl na 180 000 MB:

DBCC SHRINKFILE (4, 180000);

Po snížení přidělené velikosti na 180 000 MB můžete znovu spustit zmenšování, nastavit cíl nejprve na 160 000 MB, poté na 140 000 MB a pokračovat ve snižování cíle, dokud soubor nedosáhne požadované velikosti.

Zmenšování souborů po částech může trvat déle, ale snižuje riziko opakovaného zmenšování celého souboru kvůli neočekávanému přerušení.

Jako výchozí bod použijte přírůstek v rozmezí 10–20 gigabajtů. Můžete si nastavit přírůstek podle potřeby pro svůj scénář. Větší přírůstky vám mohou umožnit dokončit zmenšení souboru rychleji, zatímco menší přírůstky snižují riziko ztráty dosavadního postupu, pokud je zmenšování přerušeno.

Monitorování operací zmenšení

Pro sledování postupu zmenšování u všech současně běžících zmenšovacích relací použijte následující dotaz:

SELECT command,
       percent_complete,
       status,
       wait_resource,
       session_id,
       wait_type,
       blocking_session_id,
       cpu_time,
       reads,
       writes,
       CAST (((DATEDIFF(s, start_time, GETDATE())) / 3600) AS VARCHAR) + ' hour(s), '
               + CAST ((DATEDIFF(s, start_time, GETDATE()) % 3600) / 60 AS VARCHAR) + 'min, '
               + CAST ((DATEDIFF(s, start_time, GETDATE()) % 60) AS VARCHAR) + ' sec'
           AS running_time
FROM sys.dm_exec_requests AS r
     LEFT OUTER JOIN sys.databases AS d
         ON r.database_id = d.database_id
WHERE r.command IN ('DbccSpaceReclaim', 'DbccFilesCompact', 'DbccLOBCompact', 'DBCC');

Poznámka:

Pokrok při zmenšování může být nelineární a hodnota ve sloupci percent_complete může zůstat dlouhá období nezměněná, i když zmenšování stále probíhá. Zvýšení hodnot cpu_time, reads nebo writes u stejného session_id mezi dvěma spuštěními dotazu znamená, že operace shrink nadále postupuje.

Když se zmenšení všech datových souborů úspěšně dokončí, znovu spusťte dotaz na využití místa (nebo zkontrolujte v Azure portálu), abyste viděli výsledné snížení přidělené velikosti úložiště. Pokud je stále velký rozdíl mezi využitým a alokovaným prostorem, přetvořte nebo reorganizujte indexy. Přestavba indexu může dočasně zvýšit přidělený prostor. Nicméně opětovné zmenšení datových souborů po přebudování indexů často vede k hlubšímu snížení přiděleného prostoru.

Přechodné chyby během zmenšení

Občas může příkaz ke zmenšení selhat kvůli chybám, jako je vypršení časového limitu a uváznutí. Tyto chyby jsou často přechodné a už se neopakují, pokud opakujete stejný příkaz. Pokud zmenšení selže kvůli chybě, zachová se dosavadní průběh. Znovu spusťte stejný příkaz pro zmenšení souboru.

Skript PowerShell ShrinkDriver automaticky zopakuje pokus o zmenšení, když dojde k přechodné chybě. Použijte tento skript ke zmenšení velkých databází.

Následující příklad T-SQL skriptu ukazuje, jak spustit zmenšování pro jeden soubor v opakovaném pokusu. Smyčka automaticky opakuje operaci až do konfigurovatelného počtu pokusů, když dojde k chybě časového limitu nebo chybě uváznutí. Tento přístup k opakovanému pokusu platí i pro mnoho dalších chyb, které mohou nastat během zmenšování.

DECLARE @RetryCount AS INT = 3; -- adjust to configure desired number of retries
DECLARE @Delay AS CHAR (12);

-- Retry loop
WHILE @RetryCount >= 0
BEGIN
    BEGIN TRY
        DBCC SHRINKFILE (1); -- adjust file_id and other shrink parameters

        -- Exit retry loop on successful execution
        SELECT @RetryCount = -1;

    END TRY
    BEGIN CATCH
        -- Retry for the declared number of times without raising
        -- an error if deadlocked or timed out waiting for a lock
        IF ERROR_NUMBER() IN (1205, 49516) AND @RetryCount > 0
        BEGIN
            SELECT @RetryCount -= 1;

            PRINT CONCAT('Retry at ', SYSUTCDATETIME());

            -- Wait for a random period of time between 1 and 10 seconds before retrying
            SELECT @Delay = '00:00:0' + CAST (CAST (1 + RAND() * 8.999 AS DECIMAL (5, 3)) AS VARCHAR (5));

            WAITFOR DELAY @Delay;

        END
        ELSE -- Raise error and exit loop
        BEGIN
            SELECT @RetryCount = -1;

            THROW;

        END
    END CATCH
END

Kromě timeoutů a zablokování může shrink narazit na chyby způsobené určitými známými problémy.

Prostudujte chyby a kroky ke zmírnění v následujících částech.

Chyba číslo 49503

%.*ls: Page %d:%d could not be moved because it is an off-row persistent version store page. Page holdup reason: %ls. Page holdup timestamp: %I64d.

Tato chyba nastává, když dlouhodobě běžící aktivní transakce generují verze řádků v persistentním úložišti verzí (PVS). Při zmenšení nelze přesunout stránky obsahující verze řádků.

Pro zmírnění této chyby počkejte, až se dokončí dlouhodobě běžící transakce. Alternativně identifikujte a ukončete dlouhodobě běžící transakce, ale tato akce může ovlivnit vaši aplikaci, pokud neřeší selhání transakcí elegantně.

Další informace o řešení zpoždění při čištění PVS, která mohou ovlivnit shrink, naleznete v tématu Monitorování a řešení problémů se zrychlenou obnovou databáze.

Chyba číslo 5223

%.*ls: Empty page %d:%d could not be deallocated.

Tato chyba může nastat během probíhajících operací údržby indexu, jako je ALTER INDEX. Po dokončení těchto operací zkuste příkaz zmenšit znovu.

Pokud tato chyba přetrvává, možná budete muset přestavět příslušný index. Pokud chcete najít index, který se má znovu sestavit, spusťte následující dotaz ve stejné databázi, ve které jste spustili příkaz shrink:

SELECT OBJECT_SCHEMA_NAME(pg.object_id) AS schema_name,
       OBJECT_NAME(pg.object_id) AS object_name,
       i.name AS index_name,
       p.partition_number
FROM sys.dm_db_page_info(DB_ID(), <file_id>, <page_id>, default) AS pg
INNER JOIN sys.indexes AS i
ON pg.object_id = i.object_id
   AND
   pg.index_id = i.index_id
INNER JOIN sys.partitions AS p
ON pg.partition_id = p.partition_id;

Před spuštěním tohoto dotazu nahraďte zástupné symboly <file_id> a <page_id> skutečnými hodnotami uvedenými v chybové zprávě. Například pokud je zpráva: Empty page 1:62669 could not be deallocated, pak je <file_id>1 a <page_id> je 62669.

Znovu sestavte index identifikovaný dotazem a zkuste příkaz shrink zopakovat.

Chybové číslo 5201

DBCC SHRINKDATABASE: File ID %d of database ID %d was skipped because the file does not have enough free space to reclaim.

Tato chyba znamená, že datový soubor nelze dále zmenšit. Můžete přejít k dalšímu datovému souboru.

Související obsah

• Limity prostředků pro jednoúčelové databáze využívající nákupní model založený na virtuálních jádrech
• Limity prostředků pro izolované databáze využívající nákupní model DTU – Azure SQL Database
• Limity zdrojů pro elastické fondy při použití nákupního modelu vCore
• Limity prostředků pro elastické fondy využívající nákupní model založený na DTU