През цялата си кариера като специалист по данни, както в Microsoft, така и като консултант, открих, че една от най-неразбраните части на база данни на SQL Server е дневникът на транзакциите. Липсата на познания за това как работи дневникът на транзакциите и трябва да се управлява, или просто прости погрешни схващания, може да доведе до всички видове производствени проблеми, включително:
- Регистърът на транзакциите става извън контрол и потенциално остава без място
- Проблеми с производителността поради многократно свиване на регистрационния файл на транзакциите
- Проблеми с производителността поради проблем, известен като VLF фрагментация , който обсъдих в тази публикация
- Невъзможност за възстановяване до желан момент от време с помощта на резервни копия на регистрационните файлове на транзакциите
- Невъзможност за извършване на архивиране на tail-log по време на възстановяване при бедствие (вижте тук за обяснение на архивирането на tail-log)
- Различни проблеми около отказите и възстановяването на производителността
С тази публикация започвам от време на време серия за дневника на транзакциите и как работи и трябва да се управлява, и ще се докосна до всички проблеми по-горе в хода му. В тази публикация ще обясня какво е регистриране и защо е необходимо.
Основна терминология около регистрирането
Когато говоря за някакъв механизъм в SQL Server, откривам, че има проблем с пиле и яйце, при който трябва да използвам дума или фраза, преди да го обясня. За да избегна този проблем в тази поредица, ще започна с обяснение на терминология, която трябва да се използва, когато обсъждаме регистрирането, и ще разширя много от тези термини с напредването на серията.
Транзакция, ангажимент и връщане назад
Транзакцията включва промяна или набор от промени в база данни. Има определено начало и определен край. Началото е, когато се използва израз BEGIN TRANSACTION или SQL Server автоматично започва транзакция вместо вас. Краят може да бъде едно от четирите неща:
- Транзакцията се извършва, когато се изпълни оператор COMMIT TRANSACTION
- Транзакцията се извършва, когато SQL Server автоматично извършва транзакцията в случай на транзакция за автоматично извършване
- Транзакцията завършва връщането назад след изпълнение на оператор ROLLBACK TRANSACTION
- Транзакцията завършва връщането назад след възникнал проблем и SQL Server автоматично връща обратно транзакцията
Когато транзакция се ангажира, направените промени се финализират в базата данни и са трайни в регистъра на транзакциите на SQL Server на диска. Имайте предвид, че казах „в регистъра на транзакциите“. Действителните промени в страниците на файловете с данни в паметта *не* се записват на диска, когато транзакцията се извършва. Не е необходимо те да бъдат направени трайни във файловете с данни, тъй като промените вече са трайни в регистъра на транзакциите. В крайна сметка страниците с файлове с данни ще бъдат записани на диск чрез операция на контролна точка.
Обратно, когато транзакция се върне назад, промените в данните, направени от транзакцията, вече не присъстват в базата данни. Все още ще има някои физически промени в базата данни, тъй като връщането назад на транзакция означава извършване на повече промени, но можете да мислите за връщана транзакция като че не е засегнала данните в базата данни.
Контролните точки и операциите за връщане са теми, достойни за собствени публикации, така че ще ги обясня по-късно в поредицата.
Обсъждам тези три термина много по-задълбочено в урока Въведение в транзакциите на SQL Server в блога SentryOne.
Регистриране, регистрационни записи и регистър на транзакциите на SQL Server
Регистрирането просто означава създаване на трайно описание на промяна в база данни, почти винаги в контекста на транзакция. Когато се направи промяна, промяната се описва в дневник. Записът в дневника обикновено съдържа достатъчно информация, за да позволи промяната да бъде възпроизведена в базата данни или да се върне обратно в базата данни, ако е необходимо.
Този регистрационен запис първоначално ще бъде в паметта и може да бъде записан на диска, преди транзакцията да се извърши, но определено трябва да бъде записан на диск преди транзакцията може да завърши извършването, в противен случай транзакцията няма да бъде трайна. Изключение от това правило е, когато отложена издръжливост функцията е активирана, която Аарон Бертран обсъжда в тази публикация.
Регистрационните записи се съхраняват в регистъра на транзакциите (един или повече регистрационни файлове на диска), който има донякъде сложна вътрешна архитектура и ще обсъдя това и много повече за регистрационните записи в следващата публикация от поредицата.
Възстановяване при срив
Сривът е, когато SQL Server се изключва неочаквано и различните променени бази данни не могат да бъдат изключени правилно (уверявайки се, че всички променени страници на файлове с данни са записани на диск и базата данни е маркирана като чисто изключена).
Когато SQL Server се стартира, той проверява всички бази данни, за да види дали някоя не е маркирана като чисто изключена. Ако намери такъв, тази база данни трябва да премине през възстановяване при срив. Това гарантира следното:
- За всяка транзакция, която е била извършена преди срива, уверете се, че всички промени в транзакцията са отразени в базата данни (т.е. повторете транзакцията)
- За всяка транзакция, която не е била извършена преди срива, уверете се, че нито една от промените в транзакцията не е отразена в базата данни (т.е. върнете транзакцията обратно)
С други думи, възстановяването при срив прави база данни последователна на транзакциите към момента на възникване на катастрофата. Използва се възстановяване при срив:
- Когато SQL Server стартира и намери база данни, която трябва да бъде възстановена
- По време на преминаване към вторично копие на база данни
- В края на последователност за възстановяване, включваща архивиране (вижте тук)
Възстановяването при срив е сложен процес и изисква още няколко публикации от поредицата, преди да мога да го обясня задълбочено.
Защо се изисква регистриране?
Най-основната причина за регистриране е да се позволи на базата данни на SQL Server да направи транзакциите трайни, така че да могат да бъдат възстановени по време на възстановяване при срив или връщане назад, ако е необходимо по време на нормални операции с базата данни. Ако нямаше регистриране, базата данни щеше да бъде непоследователна по отношение на транзакциите и вероятно структурно повредена след срив.
Без регистриране обаче множество други функции в SQL Server не биха били възможни, включително:
- Архивни копия на данни, които могат да бъдат възстановени последователно
- Архивни копия на регистрационни файлове за транзакции на SQL Server, които могат да се използват по време на операция по възстановяване и за внедряване на доставка на регистрационни файлове
- Репликация, която разчита на възможността за събиране на транзакции от регистъра на транзакциите
- Change Data Capture, който използва агента за четене на регистрационни файлове за репликация на транзакции, за да събира промени от регистрационния файл на транзакциите
- Огледални групи от база данни и наличност, които разчитат на изпращане на регистрационни записи към вторични копия на базата данни за повторно възпроизвеждане.
SQL Server (и всички подобни сървъри на бази данни) използва това, което се нарича записване напред . Това означава, че описанията на промените трябва да бъдат записани на диск преди самите промени, за да се гарантира възможността за правилно възстановяване на база данни при срив. Ако промяната е била записана във файл с данни преди описващите го записи в дневника и SQL Server се срине, няма да има начин да се знае какво да се върне назад и базата данни ще бъде непоследователна. Това подреждане е инвариантно, без значение какво ниво на изолация, тип транзакция или дали се използва функцията за отложена издръжливост. Първо регистрационните записи, по-късно страниците с данни.
Просто върхът на айсберга
Както можете да видите от тази въвеждаща публикация, огромно количество влиза в регистъра на транзакциите и влизането в база данни на SQL Server и всичко, което направих досега, е да дефинирам някаква терминология на високо ниво и да обясня защо се изисква регистриране. Надявам се, че ще се присъедините към мен, докато се разклонявам и навлизам по-дълбоко с напредването на поредицата!
