Във втората част на тази серия описах структурната йерархия на дневника на транзакциите. Тъй като тази публикация се занимава основно с виртуалните регистрационни файлове (VLF), които описах, препоръчвам ви да прочетете втората част, преди да продължите.
Когато всичко е наред, дневникът на транзакциите ще се повтаря безкрайно, използвайки повторно съществуващите VLF. Това поведение е това, което наричам кръгов характер на дневника . Понякога обаче ще се случи нещо, което да предотврати това и регистрационният файл на транзакциите расте и расте, добавяйки все повече и повече VLF. В тази публикация ще обясня как всичко това работи или понякога не.
VLF и съкращаване на журнал
Всички VLF имат заглавна структура, съдържаща метаданни за VLF. Едно от най-важните полета в структурата е състоянието на VLF, а стойностите, които ни интересуват, са нула, което означава, че VLF е неактивен и две, което означава, че VLF е активен . Важно е, защото неактивен VLF може да се използва повторно, но активен не може. Имайте предвид, че VLF е напълно активен или напълно неактивен.
VLF ще остане активен, докато необходимите регистрационни записи са в него, така че не може да бъде използван повторно и презаписан (следващия път ще покрия самите регистрационни записи). Примери за причини, поради които може да са необходими записи в регистрационните файлове, включват:
- Има продължителна транзакция, от която са част от записите в регистрационния файл, така че те не могат да бъдат освободени, докато транзакцията не бъде ангажирана или завърши връщането назад
- Архивирането на регистрационни файлове все още не е архивирало тези регистрационни записи
- Тази част от регистрационния файл все още не е обработена от агента за четене на журнали за репликация на транзакции или заснемане на промяна на данни
- Тази част от регистрационния файл все още не е изпратена до огледало на асинхронна база данни или реплика на група за наличност
Важно е да се отбележи, че ако няма причини VLF да остане активен, той няма да премине към неактивен отново, докато не започне процес, наречен съкращаване на дневника се случва – повече за това по-долу.
Използвайки прост хипотетичен дневник на транзакциите със само пет VLF и VLF последователни номера, започващи от 1 (не забравяйте от последния път, че в действителност те никога не го правят), когато регистрационният файл на транзакциите е създаден, VFL 1 веднага се маркира като активен, както винаги има да бъде поне един активен VLF в регистъра на транзакциите – VLF, в който в момента се записват блокове на регистрационни файлове. Нашият примерен сценарий е показан на фигура 1 по-долу.
Фигура 1:Хипотетичен, чисто нов регистър на транзакциите с 5 VLF, последователни номера 1 до 5.
Тъй като се създават повече регистрационни записи и повече регистрационни блокове се записват в дневника на транзакциите, VLF 1 се запълва, така че VLF 2 трябва да стане активен, за да бъдат записани още блокове от регистрационни файлове, както е показано на Фигура 2 по-долу.
Фигура 2:Дейността се движи през регистъра на транзакциите.
SQL Server проследява началото на най-старата незаети (активна) транзакция и този LSN се запазва на диска всеки път, когато се случи операция на контролна точка. LSN на най-новия регистрационен запис, записан в дневника на транзакциите, също се проследява, но се проследява само в паметта, тъй като няма начин да се запази на диска, без да се сблъскате с различни условия на състезание. Това няма значение, тъй като се използва само по време на възстановяване при срив и SQL Server може да изработи LSN на „края“ на регистрационния файл на транзакциите по време на възстановяване при срив. Контролните точки и възстановяването при срив са теми за бъдещи публикации от поредицата.
В крайна сметка VLF 2 ще се запълни, а VLF 3 ще стане активен и т.н. Същността на кръговия характер на регистрационния файл на транзакциите е, че по-ранните VLF в регистъра на транзакциите стават неактивни, за да могат да бъдат използвани повторно. Това се извършва чрез процес, наречен срязване на дневник , което също обикновено се нарича изчистване на регистрационни файлове . За съжаление и двата термина са ужасно погрешни наименования, защото всъщност нищо не е съкратено или изчистено.
Съкращаването на регистрационни файлове е просто процесът на проверка на всички VLF в регистъра на транзакциите и определяне кои активни VLF вече могат да бъдат маркирани като неактивни отново, тъй като нито едно от съдържанието им все още не се изисква от SQL Server. Когато се извършва съкращаване на регистрационните файлове, няма гаранция, че активните VLF могат да бъдат направени неактивни – това изцяло зависи от това, което се случва с базата данни.
Има две често срещани погрешни схващания относно съкращаването на журнала:
- Регистраторът на транзакциите става по-малък (погрешното схващане за „отрязването“). Не, не е – няма промяна в размера от съкращаването на дневника. Единственото нещо, което може да намали дневника на транзакциите, е изричен DBCC SHRINKFILE.
- Неактивните VLF се нулират по някакъв начин („изчистващата“ погрешна представа). Не – нищо не се записва във VLF, когато е направен неактивен, освен няколко полета в заглавката на VLF.
Фигура 3 по-долу показва нашия регистър на транзакциите, където VLF 3 и 4 са активни, а съкращаването на регистрационните файлове е в състояние да маркира VLF 1 и 2 като неактивни.
Фигура 3:Съкращаването на журнала маркира по-ранните VLF като неактивни.
Когато възникне съкращаване на журнала зависи от това кой модел за възстановяване се използва за базата данни:
- Прост модел:съкращаването на регистрационния файл се случва, когато операцията на контролна точка завърши
- Пълен модел или модел с групово регистриран регистрационен файл:съкращаването на регистрационния файл се случва, когато архивирането на регистрационните файлове завърши (стига да не се изпълнява едновременно пълно или диференциално архивиране, в който случай съкращаването на регистрационните файлове се отлага, докато архивирането на данните завърши)
Няма изключения от това.
Кръгов характер на дневника
За да избегнете необходимостта от нарастване на регистрационния файл на транзакциите, съкращаването на регистрационните файлове трябва да може да маркира VLFs като неактивни. Първият физически VLF в регистрационния файл трябва да е неактивен, за да има кръгов характер на регистъра на транзакциите.
Помислете за фигура 4 по-долу, която показва, че VLF 4 и 5 се използват и съкращаването на регистрационния файл е маркирало VLF от 1 до 3 като неактивни. Генерират се повече регистрационни записи, повече регистрационни блокове се записват във VLF 5 и в крайна сметка той се запълва.
Фигура 4:Дейността запълва най-високия физически VLF в регистъра на транзакциите.
В този момент мениджърът на лог за базата данни разглежда състоянието на първия физически VLF в регистъра на транзакциите, който в нашия пример е VLF 1, с пореден номер 1. VLF 1 е неактивен, така че регистърът на транзакциите може да се обвива и започнете да пълните отново от самото начало. Мениджърът на журнала променя първия VLF на активен и увеличава неговия пореден номер, за да бъде един по-висок от текущия най-висок пореден номер на VLF. Така става VLF 6 и регистрирането продължава с запис на лог блок в този VLF. Това е кръговият характер на дневника, както е показано по-долу на фигура 5.
Фигура 5:Кръглият характер на регистъра на транзакциите и повторното използване на VLF.
Когато нещо се обърка
Когато първият физически VLF в регистрационния файл на транзакциите не е неактивен, дневникът на транзакциите не може да се обвие, така че ще расте (стига да е конфигуриран да прави това и да има достатъчно дисково пространство). Това често се случва, защото има нещо, което пречи на съкращаването на регистрационните файлове да деактивира VLF. Ако установите, че регистърът на транзакциите за база данни нараства, можете да потърсите SQL Server, за да разберете дали има проблем с отрязването на регистрационния файл, като използвате този прост код по-долу:
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Ако съкращаването на регистрационните файлове е могло да деактивира един или повече VLF, тогава резултатът ще бъде НИЩО. В противен случай , ще ви бъде дадена причина, поради която съкращаването на журнала не може да деактивира никакви VLF. Има дълъг списък с възможни причини, описани тук в раздела Фактори, които могат да забавят съкращаването на регистрационните файлове.
Важно е да разберете семантиката на резултата:това е причината, поради която съкращаването на дневника не може да направи нищо последния път, когато се опита да се изпълни . Например резултатът може да бъде ACTIVE_BACKUP_OR_RESTORE, но знаете, че това дългогодишно пълно архивиране приключи. Това просто означава, че при последния опит за съкращаване на регистрационния файл, архивирането все още се изпълняваше.
Според моя опит най-честата причина за предотвратяване на съкращаването на регистрационните файлове е LOG_BACKUP; т.е. извършете архивиране на дневника! Но има и интересно, странно поведение с LOG_BACKUP . Ако непрекъснато виждате резултата LOG_BACKUP но знаете, че архивирането на регистрационни файлове се случва успешно, защото има много малко активност в базата данни и текущият VLF е същият като последния път, когато е извършено архивиране на регистрационни файлове. И така, LOG_BACKUP означава „извършете архивиране на регистрационни файлове“ или „всички архивирани регистрационни записи са от текущия VLF, така че не може да бъде деактивиран“. Когато се случи последното, това може да бъде объркващо.
Обръщане назад...
Поддържането на кръговия характер на регистрационния файл на транзакциите е много важно, за да се избегне скъпоструващ дневник и необходимостта от предприемане на коригиращи действия. Обикновено това означава да се гарантира, че архивирането на регистрационни файлове се извършва редовно, за да се улесни съкращаването на регистрационните файлове и оразмеряването на регистрационния файл на транзакциите, за да може да задържи всякакви големи, продължителни операции като възстановяване на индекси или ETL операции, без да се наблюдава растеж на регистрационните файлове.
В следващата част от поредицата ще разгледам регистрационните записи, как работят и някои интересни примери.
