В предишната си публикация за рационализиране на операциите на дневника на транзакциите обсъдих две от най-честите причини за генериране на допълнителни записи в дневника:мъртва тежест от неизползвани неклъстерирани индекси и операции за разделяне на страници (които причиняват фрагментация на индекса). Ако приемем, че сте прочели тази публикация, споменах, че има по-фини проблеми, които могат да бъдат вредни за производителността на регистрационния файл на транзакциите, и ще ги разгледам тук.
Много, много малки транзакции
От време на време SQL Server изтрива част от дневника на транзакциите на диск. Изтриване на регистрационни файлове се извършва винаги, когато:
- Генерира се регистрационен запис на транзакциите.
- Запис в дневника за прекратяване на транзакция се генерира в края на връщане назад.
- 60 КБ регистрационни записи са генерирани от предишното изтриване на дневника.
Най-малкият възможен дневник е единичен 512-байтов дневник. Ако всички транзакции в работното натоварване са много малки (например вмъкване на единичен, малък ред на таблица), тогава ще има много изтривания на журнал с минимален размер. Изтриването на регистрационни файлове се извършва асинхронно, за да се позволи прилична пропускателна способност на дневника на транзакциите, но има фиксирано ограничение от 32 едновременни I/O изтриване на регистрационни файлове във всеки един момент (повишено до 112 на SQL Server 2012).
Това може да има два възможни ефекта:
- При бавно работеща входно-изходна подсистема обемът на малки записвания в регистрационния файл на транзакции може да претовари I/O подсистемата, което води до запис с висока латентност и последващо влошаване на пропускателната способност на регистрационния файл на транзакциите. Тази ситуация може да бъде идентифицирана чрез големи латентности при запис за регистрационния файл на транзакциите в изхода на sys.dm_io_virtual_file_stats (вижте демонстрационните връзки в горната част на предишната публикация)
- На високопроизводителна I/O подсистема записите могат да завършат изключително бързо, но ограничението от 32 едновременни входно/изходни операции за изтриване на регистрационни файлове създава пречка, когато се опитвате да направите регистрационните записи трайни на диска. Тази ситуация може да бъде идентифицирана чрез ниски латентности при запис и почти постоянен брой записвания в регистъра на транзакциите близо до 32 в обобщения изход на sys.dm_io_pending_io_requests (вижте същите демонстрационни връзки).
И в двата случая удължаването на транзакциите (което е много противоинтуитивно!) може да намали честотата на изтриване на дневника на транзакциите и да повиши производителността. Освен това, в случай №1, преминаването към по-висока производителност I/O подсистема може да помогне, но може да доведе до случай №2. При случай №2, ако транзакциите не могат да бъдат направени по-дълго, единствената алтернатива е да се раздели натоварването върху множество бази данни, за да се заобиколи фиксираната граница от 32 едновременни I/O изтриване на регистрационни файлове или да се надстрои до SQL Server 2012 или по-нова версия.
Автоматичен растеж на дневника на транзакциите
Всеки път, когато се добавя ново пространство към регистъра на транзакциите, то трябва да бъде инициализирано с нула (изписване на нули, за да се презапише предишното използване на тази част от диска), без значение дали функцията за незабавна инициализация на файл е активирана или не. Това се отнася за създаване, ръчно нарастване и автоматично нарастване на регистъра на транзакциите. Докато се извършва нулевата инициализация, регистрационните записи не могат да бъдат прехвърлени в дневника, така че автоматичното нарастване по време на работно натоварване, което променя данните, може да доведе до забележим спад в пропускателната способност, особено ако размерът на автоматичното нарастване е настроен да бъде голям ( да речем гигабайти, или оставени по подразбиране 10%).
След това трябва да се избягва автоматичното нарастване, ако изобщо е възможно, като се позволи на дневника на транзакциите да се изчисти, така че винаги да има свободно пространство, което може да се използва повторно за нови записи в дневника. Изчистването на регистрационния файл на транзакциите (известно също като съкращаване на регистрационния файл на транзакциите, да не се бърка със свиване на регистрационния файл на транзакциите) се извършва чрез архивиране на регистрационния файл на транзакциите, когато се използват режимите за пълно възстановяване или с групово регистриране, и чрез контролни точки, когато се използва режим на просто възстановяване.
Изчистването на регистрационния файл може да се случи само ако нищо не изисква изчистването на регистрационните записи в секцията на регистъра на транзакциите. Един често срещан проблем, който предотвратява изчистването на регистрационните файлове, е наличието на дългосрочни транзакции. Докато транзакцията не бъде ангажирана или се върне назад, всички записи в регистрационния файл от началото на транзакцията нататък са необходими в случай, че транзакцията се върне назад – включително всички регистрационни записи от други транзакции, които са разпръснати с тези от дългосрочната транзакция. Дългосрочните транзакции могат да се дължат на лош дизайн, код, който изчаква човешко въвеждане, или неправилно използване на вложени транзакции, например. Всички те могат да бъдат избегнати, след като бъдат идентифицирани като проблем.
Можете да прочетете повече за това тук и тук.
Функции за висока достъпност
Някои функции с висока наличност също могат да забавят изчистването на регистъра на транзакциите:
- Огледалното копиране на базата данни и групите за наличност, когато се изпълняват асинхронно, могат да натрупат опашка от регистрационни записи, които все още не са изпратени до излишното копие на базата данни. Тези регистрационни записи трябва да се съхраняват, докато не бъдат изпратени, което забавя изчистването на регистъра на транзакциите.
- Транзакционната репликация (а също и улавянето на промяна на данни) разчита на задание на агент за четене на журнали, за да сканира периодично дневника на транзакциите за транзакции, които променят таблица, съдържаща се в публикация за репликация. Ако агентът за четене на журнали изостава по някаква причина или целенасочено е накаран да се изпълнява рядко, всички регистрационни записи, които не са били сканирани от заданието, трябва да се съхраняват, което забавя изчистването на регистрационния файл на транзакциите.
Когато работи в синхронен режим, дублирането на база данни и групите за достъпност могат да причинят други проблеми с механизма за регистриране. Използвайки синхронно дублиране на база данни като пример, всяка транзакция, която се извършва на принципала, всъщност не може да се върне към потребителя или приложението, докато всички генерирани от него регистрационни записи не бъдат успешно изпратени до огледалния сървър, добавяйки забавяне на записването на принципала. Ако средният размер на транзакцията е дълъг и забавянето е кратко, това може да не се забележи, но ако средната транзакция е много кратка и забавянето е доста голямо, това може да има забележим ефект върху пропускателната способност на работното натоварване. В този случай или целите за производителност на работното натоварване трябва да бъдат променени, технологията с висока достъпност да се промени в асинхронен режим, или трябва да се увеличат честотната лента и скоростта между основната и резервната база данни.
Между другото, същият вид проблем може да възникне, ако самата I/O подсистема е синхронно огледална – с потенциално забавяне за всички записи, които SQL Server извършва.
Резюме
Както можете да видите, ефективността на дневника на транзакциите не е само генериране на допълнителни записи в дневника на транзакциите – има много фактори на околната среда, които също могат да имат дълбок ефект.
Изводът е, че здравето и производителността на регистъра на транзакциите са от първостепенно значение за поддържане на цялостната производителност на работното натоварване. В тези две публикации описах подробно основните причини за проблеми с производителността на регистрационния файл на транзакциите, така че се надяваме, че ще можете да идентифицирате и отстраните всички, които имате.
Ако искате да научите много повече за операциите в регистъра на транзакциите и настройката на производителността, препоръчвам ви да разгледате моя 7,5-часов онлайн курс за обучение за регистриране, възстановяване и регистър на транзакциите, достъпен чрез Pluralsight.
