Jak vymažete protokol transakcí SQL Server?

Zmenšení souboru protokolu by mělo být skutečně vyhrazeno pro scénáře, kde došlo k neočekávanému nárůstu, u kterého neočekáváte, že se bude opakovat. Pokud soubor protokolu znovu naroste na stejnou velikost, jeho dočasné zmenšení toho moc nedosáhne. Nyní, v závislosti na cílech obnovy vaší databáze, toto jsou akce, které byste měli provést.

Nejprve vytvořte úplnou zálohu

Nikdy neprovádějte žádné změny v databázi, aniž byste se ujistili, že ji můžete obnovit, pokud se něco pokazí.

Pokud vám záleží na obnovení v určitém okamžiku

(A obnovou v určitém okamžiku myslím, že vám záleží na tom, abyste mohli obnovit do čehokoli jiného než do úplné nebo rozdílové zálohy.)

Vaše databáze je pravděpodobně FULL režim obnovení. Pokud ne, ujistěte se, že je:

ALTER DATABASE testdb SET RECOVERY FULL;

I když provádíte pravidelné úplné zálohy, soubor protokolu se bude zvětšovat a narůstat, dokud neprovedete protokol zálohování - to je pro vaši ochranu, ne abyste zbytečně zabírali místo na disku. Tyto zálohy protokolů byste měli provádět poměrně často, podle vašich cílů obnovy. Například, pokud máte obchodní pravidlo, které říká, že si můžete dovolit ztratit maximálně 15 minut dat v případě katastrofy, měli byste mít úlohu, která zálohuje protokol každých 15 minut. Zde je skript, který vygeneruje názvy souborů s časovým razítkem na základě aktuálního času (ale můžete to udělat také pomocí plánů údržby atd., jen v plánech údržby nevybírejte žádné možnosti zmenšení, jsou hrozné).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Všimněte si, že \\backup_share\ by měl být na jiném počítači, který představuje jiné základní úložné zařízení. Zálohování na stejný počítač (nebo na jiný počítač, který používá stejné základní disky nebo jiný VM, který je na stejném fyzickém hostiteli) vám ve skutečnosti nepomůže, protože pokud počítač vybuchne, přijdete o databázi. a jeho zálohy. V závislosti na vaší síťové infrastruktuře může být smysluplnější zálohovat lokálně a poté je přenést na jiné místo v zákulisí; v obou případech je chcete co nejrychleji dostat z primárního databázového stroje.

Nyní, jakmile budete mít spuštěné pravidelné zálohy protokolů, mělo by být rozumné zmenšit soubor protokolu na něco rozumnějšího, než je to, co bylo doposud vyhozeno. To není znamená spuštění SHRINKFILE znovu a znovu, dokud soubor protokolu nebude mít 1 MB – i když protokol často zálohujete, stále musí pojmout součet všech souběžných transakcí, které mohou nastat. Události automatického růstu souborů protokolu jsou drahé, protože SQL Server musí soubory vynulovat (na rozdíl od datových souborů, když je povolena okamžitá inicializace souborů), a uživatelské transakce musí čekat, dokud se tak nestane. Chcete tuto rutinu růst-zmenšovat-růst-zmenšovat co nejméně a rozhodně nechcete, aby za to platili vaši uživatelé.

Pamatujte, že možná budete muset zálohovat protokol dvakrát, než bude možné zmenšení (díky Roberte).

Musíte tedy přijít s praktickou velikostí souboru protokolu. Nikdo vám zde nemůže říci, co to je, aniž by o vašem systému věděl mnohem více, ale pokud jste často zmenšovali soubor protokolu a znovu se zvětšoval, dobrý vodoznak je pravděpodobně o 10–50 % vyšší než největší, jaký kdy byl . Řekněme, že to přijde na 200 MB a chcete, aby všechny následné události automatického růstu měly 50 MB, pak můžete upravit velikost souboru protokolu tímto způsobem:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Všimněte si, že pokud je soubor protokolu aktuálně> 200 MB, možná budete muset nejprve spustit toto:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Pokud vám nezáleží na obnovení v určitém okamžiku

Pokud se jedná o testovací databázi a nezáleží vám na obnovení v určitém okamžiku, měli byste se ujistit, že vaše databáze je v SIMPLE režim obnovení.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Uvedení databáze do SIMPLE režim obnovy zajistí, že SQL Server znovu použije části souboru protokolu (v podstatě postupné vyřazování neaktivních transakcí) místo toho, aby se rozrůstal a uchovával záznamy o všech transakce (jako FULL obnova probíhá, dokud protokol nezazálohujete). CHECKPOINT události pomohou řídit protokol a zajistí, že se nebude muset zvětšovat, pokud mezi CHECKPOINT nevygenerujete mnoho aktivity t-log s.

Dále byste se měli absolutně ujistit, že tento nárůst protokolu byl skutečně způsoben abnormální událostí (řekněme každoroční jarní úklid nebo přestavba vašich největších indexů), a nikoli normálním každodenním používáním. Pokud zmenšíte soubor protokolu na směšně malou velikost a SQL Server jej musí znovu zvětšit, aby vyhovoval vaší běžné činnosti, co jste získali? Dokázali jste využít místo na disku, které jste uvolnili jen dočasně? Pokud potřebujete okamžitou opravu, můžete spustit následující:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

V opačném případě nastavte vhodnou velikost a rychlost růstu. Jako v příkladu v případě obnovení v určitém okamžiku můžete použít stejný kód a logiku k určení, jaká velikost souboru je vhodná, a nastavit rozumné parametry automatického růstu.

Některé věci, které nechcete dělat

• Zálohujte protokol pomocí TRUNCATE_ONLY a poté SHRINKFILE . Za prvé, toto TRUNCATE_ONLY možnost byla zastaralá a již není k dispozici v aktuálních verzích SQL Server. Za druhé, pokud jste v FULL obnovovací model, zničí to váš řetězec protokolů a bude vyžadovat novou plnou zálohu.

• Odpojte databázi, odstraňte soubor protokolu a znovu jej připojte . Nemohu zdůraznit, jak nebezpečné to může být. Vaše databáze se nemusí vrátit, může se objevit jako podezřelá, možná se budete muset vrátit k zálohě (pokud nějakou máte), atd. atd.

• Použijte možnost „zmenšit databázi“ . DBCC SHRINKDATABASE a možnost plánu údržby provést totéž jsou špatné nápady, zvláště pokud opravdu potřebujete vyřešit pouze problém s protokolem. Zacilte soubor, který chcete upravit, a upravte jej nezávisle pomocí DBCC SHRINKFILE nebo ALTER DATABASE ... MODIFY FILE (příklady výše).

• Zmenšete soubor protokolu na 1 MB . Vypadá to lákavě, protože, hej, SQL Server mi to v určitých scénářích dovolí a podívám se na veškerý prostor, který uvolní! Pokud vaše databáze není pouze pro čtení (a to je, měli byste ji jako takovou označit pomocí ALTER DATABASE ), povede to absolutně k mnoha zbytečným událostem růstu, protože protokol musí pojmout aktuální transakce bez ohledu na model obnovy. Jaký má smysl dočasně uvolnit tento prostor, aby jej SQL Server mohl pomalu a bolestivě vzít zpět?

• Vytvořte druhý soubor protokolu . To poskytne dočasnou úlevu pro jednotku, která zaplnila váš disk, ale je to jako snažit se opravit propíchnutou plíci náplastí. Problémový soubor protokolu byste měli řešit přímo, namísto pouhého přidávání dalšího potenciálního problému. Kromě přesměrování určité aktivity protokolu transakcí na jiný disk vám druhý soubor protokolu ve skutečnosti nic nedělá (na rozdíl od druhého datového souboru), protože najednou lze použít pouze jeden ze souborů. Paul Randal také vysvětluje, proč vás může později kousnout více souborů protokolu.

Buďte proaktivní

Místo toho, abyste zmenšili soubor protokolu na malé množství a nechali jej neustále samovolně růst malou rychlostí, nastavte jej na nějakou přiměřeně velkou velikost (takovou, která pojme součet vaší největší sady souběžných transakcí) a nastavte přiměřený automatický růst. nastavení jako záložní, takže nemusí růst několikrát, aby uspokojil jednotlivé transakce, a aby bylo relativně vzácné, aby někdy musel růst během normálních obchodních operací.

Nejhorší možná nastavení zde jsou 1 MB růst nebo 10% růst. Docela legrační je, že toto jsou výchozí hodnoty pro SQL Server (na který jsem si stěžoval a žádal o změny bez úspěchu) – 1 MB pro datové soubory a 10 % pro soubory protokolu. První je v dnešní době příliš malý a druhý vede pokaždé k delším a delším událostem (řekněme, že váš soubor protokolu má 500 MB, první nárůst je 50 MB, další růst je 55 MB, další růst je 60,5 MB , atd. atd. - a na pomalých I/O věřte, že této křivky opravdu zaznamenáte).

Další čtení

Prosím, nezastavujte se zde; zatímco většina rad, které tam vidíte o zmenšování souborů protokolů, je ze své podstaty špatná a dokonce potenciálně katastrofální, existují lidé, kteří se starají více o integritu dat než o uvolnění místa na disku.

Blogový příspěvek, který jsem napsal v roce 2009, když jsem viděl několik příspěvků „zde je návod, jak zmenšit soubor protokolu“

Blogový příspěvek, který Brent Ozar napsal před čtyřmi lety a poukázal na více zdrojů, v reakci na článek v SQL Server Magazine, který neměl byly zveřejněny.

Blogový příspěvek od Paula Randala vysvětlující, proč je údržba t-log důležitá a proč byste také neměli zmenšovat své datové soubory.

Mike Walsh má skvělou odpověď pokrývající některé z těchto aspektů, včetně důvodů, proč možná nebudete moci okamžitě zmenšit soubor protokolu.