Monitorování protokolu transakcí

Za poslední rok jsem na SQLPerformance.com několikrát psal o problémech s výkonem transakčního protokolu (viz zde) a slíbil jsem, že budu diskutovat o monitorování transakčního protokolu, což udělám v tomto příspěvku. Uvedu některé metriky, které můžete sledovat, proč by vás to mělo zajímat a jakékoli rady, jak se vypořádat s uvedeným problémem.

DMV

Nejjednodušší způsob, jak sledovat I/O latence protokolu transakcí, je použít sys.dm_io_virtual_file_stats DMV. Abyste získali užitečné výsledky, budete muset provést nějaké výpočty a můžete získat nějaký příklad kódu ve skriptu VirtualFileStats.sql v tomto ukázkovém souboru zip. Opravdu chcete vidět latence zápisu menší než 5 ms pro protokol transakcí.

Začátkem listopadu jsem blogoval s výsledky průzkumu, který ukázal latence transakčního protokolu a datového souboru tempdb pro více než 25 000 databází po celém světě (viz zde), přičemž 80 % databází dosáhlo hranice 5 ms nebo méně pro latenci zápisu transakčního protokolu.

Pokud je vaše latence zápisu vyšší než 5 ms, můžete:

• Pracujte na snížení množství generovaného protokolu a/nebo množství vyprázdnění protokolu, ke kterému dochází z malých transakcí, jak jsem popsal v předchozích příspěvcích.
• Postupujte podle některých kroků pro odstraňování problémů, které popisuji v příspěvku na blogu průzkumu výše.
• Přejděte na rychlejší I/O subsystém a mějte na paměti, že pokud se rozhodnete použít SSD, musíte použít dva v konfiguraci RAID-1.

Další věc, kterou můžete sledovat, abyste se ujistili, že nenarazíte na pevný limit 32 nevyřízených zápisů I/O pro každý protokol transakcí databáze v roce 2008 R2 a dříve (od SQL Serveru 2012 zvýšeno na rok 2012). Můžete to zkusit udělat pohledem na fyzický disk/prům. Délka fronty zápisu na disk, ale to platí pro celý svazek, nikoli pro soubor, takže pokud je na svazku něco jiného kromě souboru protokolu, který vás zajímá, neposkytne vám to platné číslo. Lepším způsobem je agregovat výsledky sys.dm_io_pending_io_requests DMV, který uvádí všechny zbývající I/O. Zde je nějaký kód, jak to udělat:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Toto můžete snadno upravit tak, aby se zobrazovaly pouze výsledky pro soubory protokolu (filtr na type_desc ='LOG' ) a pouze pro ID databáze, které vás zajímá.

Pokud zjistíte, že pro konkrétní databázi narážíte na limit 32, můžete:

• Snižte množství vyprázdnění protokolu snížením počtu malých transakcí a sledováním věcí, jako je rozdělení stránek a nepoužívané/duplicitní indexy, které se změní během operací úpravy dat. Více o optimalizaci vyplachování logu si můžete přečíst v tomto příspěvku na blogu
• Zkuste použít rychlejší I/O subsystém
• Upgradujte na SQL Server 2012 nebo vyšší, kde je limit 112
• Vyzkoušejte delayed durability feature DMV, který byl přidán do SQL Server 2014
• Jako poslední možnost rozdělte zátěž na více databází nebo serverů

Pokud vás zajímá, kolik protokolu transakcí generují vaše transakce, můžete použít sys.dm_tran_database_transactions DMV, v kódu podobném níže:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Možná budete velmi překvapeni, kolik protokolu se generuje, zejména v databázi tempdb pro kód, který využívá dočasné objekty. A samozřejmě, protokol transakcí tempdb může být úzkým hrdlem, stejně jako pro databázi uživatelů.

Počítadla sledování výkonu

Čítače výkonu související s protokolem jsou všechny v objektu výkonu databáze. Zde jsou některé z hlavních, které je třeba sledovat (buď pomocí samotného nástroje Performance Monitor, nebo pomocí výstrah SQL Agent, nebo pomocí sys.dm_os_performance_counters DMV nebo ve vašem oblíbeném monitorovacím nástroji třetí strany):

Zaznamenejte růst

Nechcete, aby se toto počítadlo zvětšovalo, protože to říká, že se v databázi děje něco, co způsobuje, že se generuje více protokolu transakcí, než je aktuální místo. To znamená, že transakční protokol není schopen vymazat, takže byste měli prozkoumat příčinu dotazem na pole log_reuse_wait_desc v sys.databases a provést jakoukoli požadovanou akci (další podrobnosti viz téma Books Online Faktory, které mohou zpozdit zkrácení protokolu). Nějaký příklad kódu by byl:

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Kdykoli dojde k nárůstu protokolu, nově přidělená část protokolu transakcí musí být vynulována a navíc jsou přidány další soubory virtuálních protokolů – obojí může způsobit problémy, jak jsem o tom psal dříve.

Protokol se zmenší

Pokud nejste osobou, která provádí operaci zmenšení, aby přivedla zpět pod kontrolu nekontrolovaný protokol transakcí, nechcete, aby se tento čítač zvyšoval. Pokud někdo jen zmenší transakční protokol bez dobrého důvodu, pravděpodobně se znovu rozroste a způsobí problémy, jak jsem o tom psal dříve.

Procento využití protokolu

Měli byste sledovat toto počítadlo a mít obavy, pokud hodnota překročí 90 %, protože to znamená, že může bezprostředně nastat nárůst protokolu a protokol transakcí není schopen správně vymazat, jak jsem diskutoval výše.

Zaznamenat proplach čekání/s

Chcete, aby tato hodnota zůstala stejná nebo se snížila. Pokud se zvýší, znamená to, že máte úzké místo I/O subsystému nebo úzké místo uvnitř mechanismu vyprázdnění protokolu, protože vyprázdníte mnoho malých částí protokolu. Nárůst zde může také korelovat se zásahem do 32 zbývajících I/O pro protokol. Podívejte se na diskusi o sys.dm_io_pending_io_requests výše, kde najdete další podrobnosti.

Vyprázdnění bajtů logu/s a vyprázdnění logu/s

Tyto dva čítače vám umožňují zjistit průměrnou velikost log flush vydělením prvního čítače druhým. Výsledkem bude hodnota mezi 512 a 61440 (minimální a maximální velikost log flush). Nižší hodnota bude pravděpodobněji korelovat se zvýšením Log Flush Waits/s. Znovu se podívejte na diskuzi o sys.dm_io_pending_io_requests výše, kde najdete další podrobnosti.

Rozšířené události

Pro pokročilejší z vás jsou k dispozici některé rozšířené události, které můžete použít ke sledování toho, co se děje s protokolem. Doporučuji, abyste začali s použitím šablony Sledování vstupu databázového souboru protokolu v SQL Server 2012 SSMS. Dostanete se k tomu tak, že přejdete do Průzkumníka objektů a poté do své instance -> Správa -> Rozšířené události a kliknutím pravým tlačítkem myši na položku Relace vyberte Průvodce novou relací. V okně, které se zobrazí, zadejte název relace a z rozbalovací nabídky vyberte měřicí šablonu. Poté stiskněte Ctrl+Shift+N a relace bude skriptována do okna dotazu. Podrobnosti o všem, co tam je, bohužel přesahují rámec tohoto příspěvku, ale popis šablony je docela vysvětlující:

V SQL Server 2012 je také nová Extended Event nazvaná Transakce_log, kterou lze použít k provádění nejrůznějších zajímavých analýz generovaných záznamů protokolu. To je určitě téma, kterému se budu věnovat v budoucím příspěvku.

Shrnutí

Vzhledem ke všem výše uvedeným informacím byste měli být schopni vymyslet docela dobrý systém monitorování transakčního protokolu. Stav protokolu transakcí má prvořadý význam pro zajištění toho, aby vaše pracovní zátěž fungovala tak, jak má, a doufám, že vám čtyři příspěvky v této sérii (a všechny ostatní odkazy) pomohly zlepšit celkový výkon vašeho prostředí SQL Server.