Ve svém předchozím příspěvku o zefektivnění operací protokolu transakcí jsem diskutoval o dvou nejčastějších příčinách generování dalších záznamů protokolu:mrtvá váha z nepoužívaných neshlukovaných indexů a operace rozdělení stránky (které způsobují fragmentaci indexu). Za předpokladu, že jste si přečetli tento příspěvek, zmínil jsem se, že existují jemnější problémy, které mohou být škodlivé pro výkon protokolu transakcí, a zde se o nich budu věnovat.
Mnoho, mnoho drobných transakcí
Každý tak často SQL Server vyprázdní část protokolu transakcí na disk. K vyprázdnění protokolu dojde vždy, když:
- Vygeneruje se záznam protokolu potvrzení transakce.
- Na konci vrácení transakce se vygeneruje záznam protokolu o přerušení transakce.
- Od předchozího vyprázdnění protokolu bylo vygenerováno 60 kB záznamů protokolu.
Nejmenší možné vyprázdnění protokolu je jeden blok protokolu o velikosti 512 bajtů. Pokud jsou všechny transakce v pracovní zátěži velmi malé (např. vložení jednoho malého řádku tabulky), dojde k mnoha vyprázdněním protokolu o minimální velikosti. Vyprázdnění protokolů se provádí asynchronně, aby byla umožněna slušná propustnost protokolů transakcí, ale existuje pevný limit 32 souběžných vstupů/výstupů vyprázdnění protokolů v jednom okamžiku (zvýšeno na 112 na SQL Server 2012).
To může mít dva možné efekty:
- Na I/O subsystému s pomalým výkonem by objem malých zápisů transakčního protokolu mohl zahltit I/O subsystém, což by vedlo k zápisu s vysokou latencí a následnému snížení propustnosti transakčního protokolu. Tuto situaci lze identifikovat vysokou latencí zápisu pro soubor protokolu transakcí ve výstupu sys.dm_io_virtual_file_stats (viz odkazy na ukázku v horní části předchozího příspěvku)
- Na vysoce výkonném I/O subsystému mohou být zápisy dokončeny extrémně rychle, ale limit 32 souběžných log-flush I/O vytváří překážku při pokusu o to, aby byly záznamy protokolu na disku odolné. Tuto situaci lze identifikovat nízkou latencí zápisu a téměř konstantním počtem nevyřízených zápisů do protokolu transakcí téměř 32 v agregovaném výstupu sys.dm_io_pending_io_requests (viz stejné ukázkové odkazy).
V obou případech může prodlužování transakcí (což je velmi neintuitivní!) snížit frekvenci vyprázdnění protokolu transakcí a zvýšit výkon. Navíc v případě č. 1 může pomoci přechod na výkonnější I/O subsystém – ale může vést k případu č. 2. V případě č. 2, pokud transakce nelze provádět déle, jedinou alternativou je rozdělit pracovní zátěž na více databází, abyste se dostali kolem pevného limitu 32 souběžných vstupů/výstupů s logem nebo upgradovat na SQL Server 2012 nebo vyšší.
Automatický růst protokolu transakcí
Kdykoli je do transakčního protokolu přidáno nové místo, musí být inicializováno nulou (zapsáním nul pro přepsání předchozího použití dané části disku), bez ohledu na to, zda je funkce okamžité inicializace souboru povolena nebo ne. To platí pro vytváření, manuální růst a automatický růst protokolu transakcí. Zatímco probíhá nulová inicializace, záznamy protokolu nelze vyprázdnit do protokolu, takže automatický růst během pracovní zátěže, která mění data, může vést ke znatelnému poklesu propustnosti, zvláště pokud je velikost automatického růstu nastavena na velkou ( řekněme gigabajty nebo ponecháno na výchozích 10 %).
Pokud je to možné, pak by se mělo zabránit automatickému růstu tím, že umožníte vymazání protokolu transakcí, aby bylo vždy volné místo, které lze znovu použít pro nové záznamy protokolu. Vymazání transakčního protokolu (také známé jako zkrácení transakčního protokolu, nezaměňovat se zmenšením transakčního protokolu) se provádí zálohováním transakčního protokolu při použití režimu úplného nebo hromadného protokolování a kontrolními body při použití režimu jednoduchého obnovení.
K vymazání protokolu může dojít pouze v případě, že nic nevyžaduje vymazání záznamů protokolu v sekci protokolu transakcí. Jedním z běžných problémů, které brání vymazání protokolu, jsou dlouhotrvající transakce. Dokud transakce není potvrzena nebo vrácena zpět, jsou vyžadovány všechny záznamy protokolu od začátku transakce pro případ, že by se transakce vrátila zpět – včetně všech záznamů protokolu z jiných transakcí, které jsou proloženy záznamy z dlouhotrvající transakce. Dlouhotrvající transakce mohou být způsobeny například špatným návrhem, kódem, který čeká na lidský vstup, nebo nesprávným použitím vnořených transakcí. Všem těmto se lze vyhnout, jakmile jsou identifikovány jako problém.
Více si o tom můžete přečíst zde a zde.
Funkce vysoké dostupnosti
Některé funkce s vysokou dostupností mohou také zpozdit vymazání protokolu transakcí:
- Zrcadlení databáze a skupiny dostupnosti při asynchronním běhu mohou vytvořit frontu záznamů protokolu, které ještě nebyly odeslány do redundantní kopie databáze. Tyto záznamy protokolu je třeba uchovávat, dokud nejsou odeslány, což zdržuje vymazání protokolu transakcí.
- Transakční replikace (a také Change Data Capture) se spoléhá na úlohu Log Reader Agent, která pravidelně skenuje transakční protokol pro transakce, které mění tabulku obsaženou v publikaci replikace. Pokud se agent čtečky protokolů z jakéhokoli důvodu opozdí nebo se záměrně spustí zřídka, všechny záznamy protokolu, které nebyly naskenovány úlohou, musí být uchovávány, což zdržuje vymazání protokolu transakcí.
Při spuštění v synchronním režimu mohou zrcadlení databáze a skupiny dostupnosti způsobit další problémy s mechanismem protokolování. Při použití synchronního zrcadlení databáze jako příkladu se žádná transakce, která je potvrzena na principu, nemůže ve skutečnosti vrátit uživateli nebo aplikaci, dokud všechny záznamy protokolu, které vygenerovala, nebyly úspěšně odeslány na zrcadlový server, čímž se přidá zpoždění potvrzení na principu. Pokud je průměrná velikost transakce dlouhá a zpoždění je krátké, nemusí to být patrné, ale pokud je průměrná transakce velmi krátká a zpoždění je poměrně dlouhé, může to mít znatelný vliv na propustnost pracovní zátěže. V takovém případě je třeba buď změnit výkonnostní cíle pracovní zátěže, změnit technologii vysoké dostupnosti na asynchronní režim nebo zvýšit šířku pásma sítě a rychlost mezi hlavní a redundantní databází.
Mimochodem, stejný druh problému může nastat, pokud je samotný I/O subsystém synchronně zrcadlen – s potenciálním zpožděním pro všechny zápisy, které SQL Server provádí.
Shrnutí
Jak vidíte, výkon protokolu transakcí není jen o generování dalších záznamů protokolu transakcí – existuje mnoho faktorů prostředí, které mohou mít také hluboký vliv.
Sečteno a podtrženo je, že zdraví a výkon protokolu transakcí mají prvořadý význam pro udržení celkového výkonu zátěže. V těchto dvou příspěvcích jsem podrobně popsal hlavní příčiny problémů s výkonem protokolu transakcí, takže doufejme, že budete schopni identifikovat a napravit všechny, které máte.
Pokud se chcete dozvědět mnohem více o operacích transakčního protokolu a ladění výkonu, doporučuji vám podívat se na můj 7,5hodinový online školicí kurz o protokolování, obnově a protokolu transakcí, který je k dispozici prostřednictvím Pluralsight.