Мониторинг на регистъра на транзакциите

През последната година писах няколко пъти в блог на SQLPerformance.com относно проблеми с производителността на регистрационните файлове на транзакциите (вижте тук) и обещах да обсъдя наблюдението на регистрационния файл на транзакциите, което ще направя в тази публикация. Ще ви представя някои от показателите, които можете да проследявате, защо трябва да ви е грижа и всякакви съвети за справяне с посочения проблем.

DMV

Най-лесният начин да наблюдавате латентностите на входно/изходния регистър на транзакциите е да използвате sys.dm_io_virtual_file_stats DMV. Ще трябва да извършите малко математика, за да получите полезни резултати и можете да получите някакъв примерен код в скрипта VirtualFileStats.sql в този демонстрационен zip файл. Наистина искате да видите закъснения за запис от по-малко от 5 ms за регистъра на транзакциите.

По-рано през ноември публикувах в блог резултатите от проучване, показващо забавяне на регистрационния файл на транзакциите и tempdb на файлове с данни за повече от 25 000 бази данни по целия свят (вижте тук), като 80% от базите данни достигат 5 ms или по-малко за забавяне при запис на регистрационни файлове.

Ако забавянето ви при запис е по-голямо от 5 мс, можете:

• Работете за намаляване на количеството генериран дневник и/или количеството изтриване на регистрационни файлове, възникващи от малки транзакции, както описах в по-ранни публикации.
• Следвайте някои от стъпките за отстраняване на неизправности, които описвам в публикацията в блога на анкетата по-горе.
• Преместете се към по-бърза I/O подсистема, като не забравяйте, че ако решите да използвате SSD, трябва да използвате два в конфигурация RAID-1.

Друго нещо, което можете да наблюдавате, е да се уверите, че не достигате твърдия лимит от 32 неизпълнени входа/изхода за запис за регистрационния файл на транзакциите на всяка база данни през 2008 R2 и преди (повишено до 2012 от SQL Server 2012 нататък). Можете да опитате да направите това, като погледнете Physical Disk/Avg. Дължина на опашката за запис на диск, но това е за цял том, а не за файл, така че ако има нещо друго в тома освен регистрационния файл, който ви интересува, това няма да ви даде валиден номер. По-добър начин е да обобщите резултатите от sys.dm_io_pending_io_requests DMV, който изброява всички неизпълнени I/O. Ето код за това:

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];

Можете лесно да промените това, за да се показват само резултати за регистрационни файлове (филтър върху type_desc ='LOG' ) и само за идентификатора на базата данни, който ви интересува.

Ако установите, че достигате ограничението от 32 за конкретна база данни, можете:

• Намалете количеството изтриване на регистрационни файлове, като намалите броя на малките транзакции и внимавате за неща като разделяне на страници и неизползвани/дублирани индекси, които се променят по време на операции за промяна на данни. Можете да прочетете повече за оптимизирането на изтриване на регистрационни файлове в тази публикация в блога
• Опитайте да използвате по-бърза I/O подсистема
• Надстройте до SQL Server 2012 или по-нова версия, където ограничението е 112
• Изпробвайте delayed durability feature DMV, който беше добавен в SQL Server 2014
• В краен случай разделете натоварването върху множество бази данни или сървъри

Ако се интересувате да видите колко дневник на транзакциите се генерира от вашите транзакции, можете да използвате sys.dm_tran_database_transactions DMV, в код, подобен на този по-долу:

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

Може да сте много изненадани от това колко дневник се генерира, особено в tempdb за код, който използва временни обекти. И разбира се, дневникът на транзакциите на tempdb може да бъде пречка, точно както за потребителска база данни.

Броячи за монитор на производителността

Свързаните с регистрационни файлове броячи на производителност са всички в обекта за производителност на бази данни. Ето някои от основните, които трябва да гледате (или със самия монитор на производителността, или с помощта на сигнали на SQL агент, или с помощта на sys.dm_os_performance_counters DMV, или в любимия ви инструмент за наблюдение на трети страни):

Регистрационни нараствания

Не искате да видите този брояч да се увеличава, тъй като това казва, че нещо се случва в базата данни, което причинява генериране на повече регистрационен файл на транзакциите, отколкото има текущо пространство. Това означава, че регистрационният файл на транзакциите не може да се изчисти, така че трябва да проучите причината, като направите заявка в полето log_reuse_wait_desc на sys.databases и предприемете каквото се изисква (вижте темата Books Online Фактори, които могат да забавят съкращаването на журнала за повече подробности). Примерен код би бил:

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

Всеки път, когато настъпи нарастване на регистрационния файл, новоразпределената част от регистъра на транзакциите трябва да бъде нулирана, плюс се добавят още виртуални регистрационни файлове – и двете могат да причинят проблеми, както писах в блога по-рано.

Регистърът се свива

Освен ако не сте човекът, който извършва операцията за свиване, за да върне под контрол дневник на транзакциите извън контрол, не искате този брояч да се увеличава. Ако някой просто свие регистъра на транзакциите без основателна причина, той вероятно ще нарасне отново, причинявайки проблеми, както писах в блога по-рано.

Процент на използван дневник

Трябва да наблюдавате този брояч и да се притеснявате, ако стойността надхвърли 90%, тъй като това показва, че нарастването на регистрационния файл може да е неизбежно и регистрационният файл на транзакциите не може да се изчисти правилно, както обсъдих по-горе.

Изчакване на изтриване на дневник/сек

Искате тази стойност да остане същата или да намалее. Ако се увеличи, това означава, че имате затруднено място на входно/изходна подсистема или тесно място в механизма за измиване на дневници, защото промивате много малки части от дневника. Увеличението тук може също да корелира с достигането на 32-те изключителни I/O за регистрационния файл. Вижте обсъждането на sys.dm_io_pending_io_requests по-горе за повече подробности.

Изчистени байтове на регистрационни файлове/сек и изтриване на регистрационни файлове/сек

Тези два брояча ви позволяват да определите средния размер на дънера, като разделите първия брояч на втория. Резултатът ще бъде стойност между 512 и 61440 (съответно минималните и максималните размери на дънера). По-ниска стойност е по-вероятно да корелира с увеличаването на изчаквания за изтриване на журнала/сек. Отново вижте обсъждането на sys.dm_io_pending_io_requests по-горе за повече подробности.

Разширени събития

За по-напредналите сред вас има някои разширени събития, които можете да използвате, за да наблюдавате какво се случва с дневника. Препоръчвам ви да започнете с използването на шаблона за проследяване на IO на регистрационния файл на база данни в SQL Server 2012 SSMS. Можете да стигнете до това, като отидете в Object Explorer и след това вашият екземпляр -> Управление -> Разширени събития и щракнете с десния бутон на мишката върху Сесии, за да изберете Съветник за нова сесия. В прозореца, който се показва, въведете име на сесия и изберете шаблона за проследяване от падащото меню. След това натиснете Ctrl+Shift+N и сесията ще бъде скриптирана към прозорец за заявка. Подробностите за всичко там са извън обхвата на тази публикация, за съжаление, но описанието на шаблона е доста обяснително:

Има и ново разширено събитие в SQL Server 2012, наречено транзакция_лог, което може да се използва за извършване на всякакви интересни анализи на това какви регистрационни записи се генерират. Това определено е тема, която ще разгледам в следваща публикация.

Резюме

Като се има предвид цялата информация по-горе, би трябвало да сте в състояние да измислите доста добра система за наблюдение на дневника на транзакциите. Здравето на регистрационния файл на транзакциите е от първостепенно значение, за да се гарантира, че работното ви натоварване се изпълнява както трябва и се надявам, че четирите публикации в тази серия (плюс всички други връзки) са ви помогнали да подобрите цялостната производителност на вашата среда на SQL Server.