В последните ми две публикации обсъдих начини за намаляване на количеството генериран дневник на транзакциите и как да гарантирам, че дневникът на транзакциите винаги може да се изчисти правилно. В тази публикация искам да продължа с темата за ефективността на дневника на транзакциите и да обсъдя някои проблеми с конфигурацията на регистрационния файл на транзакциите, които могат да причинят проблеми.
Твърде много VLFs
Регистърът на транзакциите е разделен на парчета, наречени виртуални регистрационни файлове (VLF), така че системата за управление на регистрационни файлове може лесно да следи кои части от дневника на транзакциите са достъпни за повторна употреба. Има формула за това колко VLFs получавате, когато създадете своя регистър на транзакциите, ръчно го увеличите или той автоматично нараства:
| До 1MB | 2 VLFs, всеки приблизително 1/2 от общия размер |
|---|---|
| 1MB до 64MB | 4 VLFs, всеки приблизително 1/4 от общия размер |
| 64MB до 1GB | 8 VLFs, всеки приблизително 1/8 от общия размер |
| Повече от 1GB | 16 VLFs, всеки приблизително 1/16 от общия размер |
Например, ако създадете дневник на транзакциите да бъде 8GB, ще получите 16 VLF, всеки от които е приблизително 512MB. Ако след това увеличите дневника с още 4 GB, ще получите допълнителни 16 VLF, като всеки е приблизително 256 MB, за общо 32 VLF.
Забележка:този алгоритъм леко се промени за SQL Server 2014, за да облекчи проблемите с VLF фрагментацията – вижте тази публикация в блога за подробности
Обща най-добра практика е да зададете автоматичното нарастване на регистрационния файл на нещо различно от 10%, за да можете да контролирате паузата, която е необходима при нулева инициализация на ново пространство в регистъра на транзакциите. Да кажем, че създавате дневник на транзакциите от 256 MB и задавате автоматичното нарастване на 32 MB, а след това дневникът нараства до стабилен размер от 16 GB. Като се има предвид формулата по-горе, това ще доведе до регистрационния ви файл на транзакции с повече от 2000 VLF.
Тези много VLF вероятно ще доведат до някои проблеми с производителността за операции, които обработват дневника на транзакциите (например възстановяване при сривове, изчистване на регистрационни файлове, архивиране на регистрационни файлове, репликация на транзакции, възстановяване на база данни). Тази ситуация се нарича VLF фрагментация. По принцип всеки брой VLF, повече от хиляда, ще бъде проблематичен и трябва да бъде разгледан (най-много, за което съм чувал, е 1,54 милиона VLF в регистър на транзакциите, който е бил повече от 1TB!).
Начинът да разберете колко VLF имате е да използвате недокументирания (и напълно безопасен) DBCC LOGINFO команда. Броят на изходните редове е броят на VLF във вашия регистър на транзакциите. Ако смятате, че имате твърде много, начинът да ги намалите е:
- Позволете на дневника да се изчисти
- Ръчно свиване на дневника
- Повтаряйте стъпки 1 и 2, докато дневникът достигне малък размер (което може да е трудно при натоварена производствена система)
- Ръчно увеличете регистрационния файл до размера, който трябва да бъде, на стъпки до 8GB, така че всеки VLF да не е по-голям от около 0,5GB
Можете да прочетете повече за проблемите с VLF фрагментацията и процеса за отстраняването им на:
- Статия на Microsoft KB, която препоръчва намаляване на VLF числата
- Може ли растежът на регистрационните файлове да повлияе на DML?
- 8 стъпки за по-добра пропускателна способност на регистъра на транзакциите
Tempdb
Tempdb трябва да има конфигуриран дневник на транзакциите като всяка друга база данни и може да се разраства като всяка друга база данни. Но също така има някакво коварно поведение, което може да ви създаде проблеми.
Когато екземпляр на SQL Server се рестартира по някаква причина, данните и регистрационните файлове на tempdb ще се върнат към размера, който са били настроени последно. Това е различно от всички други бази данни, които остават в текущия си размер след рестартиране на екземпляр.
Това поведение означава, че ако дневникът на транзакциите на tempdb е нараснал, за да поеме нормалното работно натоварване, трябва да изпълните ALTER DATABASE за да зададете размера на регистрационния файл, в противен случай неговият размер ще спадне след рестартиране на екземпляр и ще трябва да нарасне отново. Всеки път, когато регистрационният файл нараства или нараства автоматично, новото пространство трябва да бъде инициализирано с нула и дейността по регистриране на журнала спира, докато това е направено. Така че, ако не управлявате правилно размера на регистрационния файл на tempdb, ще плащате неустойка за производителност, тъй като тя нараства след всяко рестартиране на екземпляра.
Редовно свиване на регистрационния файл
Доста често чувам хора да казват как обикновено свиват дневника на транзакциите на база данни, след като той нарасне от редовна операция (например седмично импортиране на данни). Това не е добро нещо.
Точно както обясних по-горе, когато регистрационният файл на транзакциите нараства или нараства автоматично, има пауза, докато новата част от регистрационния файл се инициализира с нула. Ако редовно свивате регистрационния файл на транзакциите, тъй като той нараства до размер X, това означава, че редовно страдате от проблеми с производителността, тъй като регистърът на транзакциите автоматично нараства отново до размер X.
Ако вашият регистър на транзакциите продължава да нараства до размер X, оставете го на мира! Проактивно го задайте на размер X, като управлявате вашите VLF, както обясних по-горе, и приемете размер X като размер, който е необходим за нормалното ви работно натоварване. По-голям регистър на транзакциите не е проблем.
Множество регистрационни файлове
Няма печалба от производителност от създаването на множество регистрационни файлове за база данни. Добавянето на втори регистрационен файл може да е необходимо обаче, ако съществуващият регистрационен файл свърши без място и не желаете да принудите регистрационния файл на транзакциите да се изчисти, като преминете към обикновен модел за възстановяване и извършите контролна точка (тъй като това прекъсва архивирането на регистрационния файл верига).
Често ме питат дали има неотложна причина за премахване на втория регистрационен файл или е добре да го оставите на място. Отговорът е, че трябва да го премахнете възможно най-скоро.
Въпреки че вторият регистрационен файл не причинява проблеми с производителността на вашето работно натоварване, той засяга възстановяването при бедствие. Ако вашата база данни е унищожена по някаква причина, ще трябва да я възстановите от нулата. Първата фаза на всяка последователност за възстановяване е да създадете данните и регистрационните файлове, ако те не съществуват.
Можете да направите създаването на файл с данни почти мигновено, като активирате незабавна инициализация на файл, която пропуска нулевата инициализация, но това не се отнася за регистрационните файлове. Това означава, че възстановяването трябва да създаде всички регистрационни файлове, които са съществували, когато е направено пълното архивиране (или са създадени през периода от време, обхванат от архивиране на регистрационния файл на транзакциите) и да ги инициализира с нула. Ако създадете втори регистрационен файл и забравите да го пуснете отново, инициализирането му с нула по време на операция за възстановяване при бедствие ще добави към общия престой. Това не е проблем с производителността на работното натоварване, но засяга наличността на сървъра като цяло.
Връщане от моментна снимка на базата данни
Последният проблем в моя списък всъщност е грешка в SQL Server. Ако използвате моментна снимка на базата данни като начин за бързо възстановяване обратно до известен момент във времето, без да се налага да възстановявате резервни копия (известно като връщане от моментната снимка), тогава можете да спестите много време. Има обаче голям недостатък.
Когато базата данни се върне от моментната снимка на базата данни, регистрационният файл на транзакциите се пресъздава с два 0,25MB VLF. Това означава, че ще трябва да увеличите своя дневник на транзакциите обратно до оптималния му размер и брой VLF (или той ще нарасне автоматично), с всички паузи за нулева инициализация и работно натоварване, които обсъдих по-рано. Очевидно не е желаното поведение.
Резюме
Както можете да видите от тази публикация и от предишните ми две публикации, има много неща, които могат да доведат до лоша производителност на регистрационния файл на транзакциите, което впоследствие оказва влияние върху производителността на цялостното ви работно натоварване.
Ако можете да се погрижите за всички тези неща, ще имате здрави дневници на транзакциите. Но това не свършва дотук, тъй като трябва да се уверите, че наблюдавате вашите регистрационни файлове за транзакции, така че да бъдете предупредени за неща като автоматично нарастване и прекомерни латентности за четене и запис на входно/изходно устройство. Ще обясня как да го направя в следваща публикация.
