V mých posledních dvou příspěvcích jsem diskutoval o způsobech, jak snížit množství generovaného protokolu transakcí a jak zajistit, aby se protokol transakcí mohl vždy správně vymazat. V tomto příspěvku chci pokračovat v tématu výkonu protokolu transakcí a probrat některé problémy s konfigurací protokolu transakcí, které mohou způsobit problémy.
Příliš mnoho VLF
Transakční protokol je rozdělen do částí nazývaných virtuální soubory protokolu (VLF), takže systém správy protokolů může snadno sledovat, které části protokolu transakcí jsou k dispozici pro opětovné použití. Existuje vzorec pro to, kolik VLF získáte, když vytvoříte svůj transakční protokol, ručně jej zvětšíte nebo automaticky naroste:
| Až 1 MB | 2 VLF, každý zhruba 1/2 celkové velikosti |
|---|---|
| 1 MB až 64 MB | 4 VLF, každý zhruba 1/4 celkové velikosti |
| 64 MB až 1 GB | 8 VLF, každý zhruba 1/8 celkové velikosti |
| Více než 1 GB | 16 VLF, každý zhruba 1/16 celkové velikosti |
Pokud například vytvoříte protokol transakcí o velikosti 8 GB, získáte 16 VLF, z nichž každý má zhruba 512 MB. Pokud poté protokol zvětšíte o další 4 GB, získáte dalších 16 VLF, z nichž každý bude mít zhruba 256 MB, celkem tedy 32 VLF.
Poznámka:Tento algoritmus se pro SQL Server 2014 mírně změnil, aby se zmírnily problémy s fragmentací VLF – podrobnosti naleznete v tomto příspěvku na blogu
Obecným osvědčeným postupem je nastavit automatický růst protokolu na něco jiného než výchozích 10 %, abyste mohli ovládat pauzu, která je vyžadována při nulové inicializaci nového prostoru protokolu transakcí. Řekněme, že vytvoříte transakční protokol o velikosti 256 MB a nastavíte automatický růst na 32 MB, a poté protokol naroste na velikost 16 GB v ustáleném stavu. Vzhledem k výše uvedenému vzorci to bude mít za následek, že váš transakční protokol bude mít více než 2 000 VLF.
Toto mnoho VLF pravděpodobně povede k určitým problémům s výkonem u operací, které zpracovávají transakční protokol (např. zotavení po havárii, vymazání protokolu, zálohy protokolů, transakční replikace, obnovení databáze). Tato situace se nazývá fragmentace VLF. Obecně jakýkoli počet VLF větší než tisíc nebo tak bude problematický a je třeba je řešit (nejvíce, o čem jsem kdy slyšel, je 1,54 milionu VLF v transakčním protokolu, který měl velikost větší než 1 TB!).
Způsob, jak zjistit, kolik VLF máte, je použít nezdokumentovaný (a zcela bezpečný) DBCC LOGINFO příkaz. Počet řádků výstupu je počet VLF ve vašem protokolu transakcí. Pokud si myslíte, že jich máte příliš mnoho, způsob, jak je snížit, je:
- Povolit vymazání protokolu
- Protokol ručně zmenšit
- Opakujte kroky 1 a 2, dokud protokol nedosáhne malé velikosti (což může být na vytíženém produkčním systému složité)
- Ručně zvětšete protokol na velikost, kterou by měl mít, v krocích až 8 GB, takže každý VLF není větší než přibližně 0,5 GB
Další informace o problémech s fragmentací VLF a postupu jejich řešení si můžete přečíst na adrese:
- Článek znalostní báze Microsoft KB, který doporučuje snížit čísla VLF
- Může růst souborů protokolu ovlivnit DML?
- 8 kroků k lepší propustnosti protokolu transakcí
Tempdb
Tempdb potřebuje mít svůj transakční protokol nakonfigurován stejně jako jakákoli jiná databáze a může růst stejně jako jakákoli jiná databáze. Má ale také nějaké zákeřné chování, které vám může způsobit problémy.
Když se instance SQL Server z jakéhokoli důvodu restartuje, data a soubory protokolu databáze tempdb se vrátí na velikost, na kterou byly naposledy nastaveny. Tím se liší od všech ostatních databází, které po restartu instance zůstávají ve své aktuální velikosti.
Toto chování znamená, že pokud se protokol transakcí tempdb rozrostl tak, aby vyhovoval běžné zátěži, musíte provést ALTER DATABASE nastavit velikost souboru protokolu, jinak jeho velikost po restartu instance klesne a bude muset znovu narůst. Pokaždé, když se soubor protokolu zvětší nebo se automaticky zvětší, musí být nový prostor nulově inicializován a činnost protokolování se během toho pozastaví. Pokud tedy nespravujete velikost souboru protokolu tempdb správně, zaplatíte pokutu za výkon, jak bude růst po každém restartu instance.
Pravidelné zmenšování souboru protokolu
Poměrně často slyším lidi říkat, jak obvykle zmenšují transakční protokol databáze poté, co vyroste z běžné operace (např. týdenní import dat). To není dobrá věc.
Jak jsem vysvětlil výše, kdykoli protokol transakcí naroste nebo se automaticky rozroste, dojde k pauze, zatímco nová část souboru protokolu je nulově inicializována. Pokud pravidelně zmenšujete protokol transakcí, protože narůstá do velikosti X, znamená to, že pravidelně trpíte problémy s výkonem, protože protokol transakcí znovu automaticky narůstá zpět na velikost X.
Pokud váš protokol transakcí neustále roste do velikosti X, nechte to být! Proaktivně jej nastavte na velikost X, spravujte své VLF, jak jsem vysvětlil výše, a přijměte velikost X jako velikost, která je potřebná pro vaše běžné pracovní zatížení. Větší protokol transakcí není problém.
Více souborů protokolu
Vytvořením více souborů protokolu pro databázi nedojde k žádnému zvýšení výkonu. Přidání druhého souboru protokolu však může být nezbytné, pokud v existujícím souboru protokolu dojde místo a vy nechcete vynutit vymazání protokolu transakcí přepnutím na jednoduchý model obnovy a provedením kontrolního bodu (protože to přeruší zálohu protokolu řetěz).
Často se mě ptají, zda existuje nějaký naléhavý důvod k odstranění druhého souboru protokolu nebo zda je v pořádku jej ponechat na místě. Odpověď zní, že byste jej měli co nejdříve odstranit.
Přestože druhý soubor protokolu nezpůsobuje problémy s výkonem pro vaši pracovní zátěž, ovlivňuje obnovu po havárii. Pokud je vaše databáze z nějakého důvodu zničena, budete ji muset obnovit od začátku. První fází jakékoli sekvence obnovy je vytvoření dat a souborů protokolu, pokud neexistují.
Vytvoření datového souboru můžete učinit téměř okamžitým povolením okamžité inicializace souboru, která přeskočí nulovou inicializaci, ale to neplatí pro soubory protokolu. To znamená, že obnovení musí vytvořit všechny soubory protokolu, které existovaly při pořízení úplné zálohy (nebo jsou vytvořeny během období pokrytého zálohou protokolu transakcí) a neinicializovat je. Pokud jste vytvořili druhý soubor protokolu a zapomněli jste jej znovu zahodit, jeho nulová inicializace během operace zotavení po havárii přispěje k celkovému výpadku. Nejedná se o problém s výkonem zátěže, ale ovlivňuje to dostupnost serveru jako celku.
Návrat ze snímku databáze
Posledním problémem v mém seznamu je ve skutečnosti chyba v SQL Server. Pokud používáte snímek databáze jako způsob rychlého obnovení zpět do známého bodu v čase, aniž byste museli obnovovat zálohy (známé jako návrat ze snímku), můžete ušetřit spoustu času. Má to však velkou nevýhodu.
Když se databáze vrátí ze snímku databáze, protokol transakcí se znovu vytvoří pomocí dvou 0,25 MB VLF. To znamená, že budete muset zvětšit svůj transakční protokol zpět na jeho optimální velikost a počet VLF (nebo se automaticky rozroste) se všemi nulovými inicializačními a pracovními pauzami, o kterých jsem hovořil dříve. Zjevně to není žádoucí chování.
Shrnutí
Jak můžete vidět z tohoto příspěvku a mých předchozích dvou příspěvků, existuje mnoho věcí, které mohou vést ke špatnému výkonu protokolu transakcí, což má pak dominový efekt na výkon vaší celkové pracovní zátěže.
Pokud se o všechny tyto věci dokážete postarat, budete mít zdravé protokoly transakcí. Tím to ale nekončí, protože se musíte ujistit, že sledujete své transakční protokoly, abyste byli upozorněni na věci, jako je automatický růst a nadměrné I/O latence čtení a zápisu. Jak to udělat, popíšu v budoucím příspěvku.