Дневниците на транзакциите са жизненоважен и важен компонент на архитектурата на базата данни. В тази статия ще обсъдим регистрационните файлове на транзакциите на SQL Server, важността и тяхната роля в миграцията на базата данни.
Въведение
Нека поговорим за различни опции за вземане на резервни копия на SQL Server. SQL Server поддържа три различни типа архивиране.
1. Пълен
2. Диференциал
3. Дневник на транзакциите
Преди да преминем към концепциите за регистрационни файлове на транзакциите, нека обсъдим други основни типове архивиране в SQL Server.
Пълното архивиране е копие на всичко. Както подсказва името, той ще архивира всичко. Той ще архивира всички данни, всеки обект от базата данни, като файл, файлова група, таблица и т.н.:– Пълното архивиране е основа за всеки друг тип архивиране.
Диференциално архивиране ще архивира данни, които са променени след последното пълно архивиране.
Третата опция е резервно копие на регистрационния файл на транзакциите, което ще регистрира всички изявления, които издаваме в базата данни в регистъра на транзакциите. Регистраторът на транзакциите е механизъм, известен като „WAL“ (Write-Ahead-Logging). Той записва всяка информация първо в дневника на транзакциите и след това в базата данни. С други думи, процесът обикновено не актуализира директно базата данни. Това е единствената пълна налична опция с модел за пълно възстановяване на базата данни. В други модели за възстановяване данните са или частични, или няма достатъчно данни в регистрационния файл. Например регистрационният запис при записване на началото на нова транзакция (записът в регистрационния файл LOP_BEGIN_XACT) ще съдържа времето, когато транзакцията е започнала, а LOP_COMMIT_XACT (или LOP_ABORT_XACT) записите ще записват времето, когато транзакцията е била задействана (или прекратена).
За да намерите вътрешни елементи на онлайн дневника на транзакциите, можете да потърсите функцията sys.fn_dblog.
Системната функция sys.fn_dblog приема два параметъра, първо, начало LSN и крайно LSN на транзакцията. По подразбиране е настроен на NULL. Ако е зададен на NULL, той ще върне всички регистрационни записи от регистрационния файл на транзакциите.
USE WideWorldImporters GO SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], [Log Record Fixed Length], [Log Record Length] [Transaction SID], [SPID], [Begin Time], * FROM fn_dblog(null,null)
Както всички знаем, транзакциите се съхраняват в двоичен формат и не е в четим формат. За да прочетете регистрационния файл на офлайн транзакциите, можете да използвате fn_dump_dblog.
Нека да потърсим регистрационния файл на транзакциите, за да видим кой е изпуснал обект, използвайки fn_dump_dblog.
SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'
Ще използваме функцията fn_dblog(), за да прочетем активната част от регистъра на транзакциите за намиране на дейност, която се извършва върху данните. След като регистрационният файл на транзакциите бъде изчистен, трябва да потърсите данните от лог файл с помощта на fn_dump_dblog().
Тази функция предоставя същия набор от редове като fn_dblog(), но има някои интересни функции, които я правят полезна, са някои сценарии за отстраняване на неизправности и възстановяване. По-конкретно, той може да чете не само регистрационния файл на транзакциите на текущата база данни, но и резервни копия на регистрационните копия на транзакциите на диск или лента.
За да получите списъка на обектите, които са изпуснати с помощта на файл на транзакция, изпълнете следната заявка. Първоначално данните се изхвърлят във временната таблица. В някои случаи изпълнението на fun_dump_dblog() отнема малко повече време. Така че е по-добре да заснемате данните във временната таблица.
За да получите идентификатор на обект от колоната Информация за заключване, изпълнете следната заявка.
SELECT * INTO TEMP FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction ID] in( SELECT DISTINCT [Transaction ID] FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction Name] LIKE '%DROP%') and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'
За да получите идентификатор на обект от колоната Информация за заключване, изпълнете следната заявка.
SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp
object_id може да бъде намерен чрез манипулиране на стойността на колоната Информация за заключване. За да намерите името на обекта за съответния идентификатор на обекта, възстановете базата данни от архива точно преди таблицата да бъде изпусната. След възстановяването можете да направите заявка в системния изглед, за да получите името на обекта.
USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';
Сега, нека видим различните форми на едни и същи подробности за транзакцията, използвайки sys.dn_dblog, sys.fn_full_dblog. Системната функция fn_full_dblog работи само със SQL Server 2017.
Заявка за извличане на първите 10 транзакции с помощта на fn_dblog.
SELECT TOP 10 * FROM sys.fn_dblog(null,null)
От SQL Server 2017 нататък можете да използвате fn_full dblog.
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)
Можете допълнително да се задълбочите в системните функции, като използвате sp_helptext fn_full_dblog.
След това потърсете архивния файл, като използвате системната функция, като използвате fn_full_dblog. Отново, това е приложимо само от SQL Server 2017 нататък.
Възстановяване в определен момент
Да приемем, че имате списъка с цялото архивиране на регистрационните файлове и след това, когато възнамерявате да възстановите регистрационните файлове, имате възможност да извършите възстановяване на данните в даден момент. Така че, в процеса на възстановяване на регистрационния файл, не е задължително да възстановявате всички данни, можете да ги възстановите точно до, преди или след всяка отделна транзакция. Така че, ако базата данни се срине в определено време и имаме както пълно архивиране, така и архивиране на регистрационни файлове, би трябвало да можем първо да възстановим пълното архивиране и след това да възстановим архива на регистрационния файл и в процеса да възстановим последния регистрационен файл до определено време , и това ще остави базата данни в точното състояние, в което е била преди да възникне този проблем.
Архивирането на регистрационни файлове са доста често срещани VLDB (много голяма база данни) и най-критичните бази данни. Винаги се препоръчва да тествате процеса на възстановяване. Винаги, когато правите резервни копия на база данни, се препоръчва да мислите добре за процеса на възстановяване и винаги трябва да тествате процеса на възстановяване по-често.
Винаги е добре да облекчите тестването на процеса на възстановяване от време на време, така че просто се уверете, че процесът преминава през архивирането нормално.
Сценарии
Позволява ни да поговорим за сценарий, когато трябва да възстановите много голяма база данни и всички знаем, че обикновено може да отнеме няколко часа и това е нещо, което всеки трябва да знае. Ако планирате миграция на база данни с нулева загуба на данни и по-малки прозорци на прекъсване, това все още може да бъде доста голям проблем. Така че не забравяйте да разчитате на архивиране на регистрационния файл на транзакциите, за да ускорите процеса.
Нека разгледаме друг сценарий, при който извършвате успоредна миграция на база данни между две различни версии на SQL Server; участвате в мигрирането на базата данни към същата версия на софтуера на целта и това включва прехвърляне на операционна система, база данни, приложение и мрежа и т.н.:-; мигриране на базата данни от един хардуер към друг; смяна както на софтуер, така и на хардуер. Процесът на миграция на база данни винаги е предизвикателство, когато загубата на данни винаги е възможна и е подложена на околната среда.
Най-добри практики за миграция на база данни
Нека обсъдим стандартните практики за управление на миграцията на база данни.
Миграцията трябва да се извършва по транзакционен начин, за да се избегнат несъответствия в данните. Обичайните стъпки на процеса на миграция обикновено са следните:
- Спрете услугата за приложения – тук започва престоя
- Започнете архивиране на регистрационни файлове, зависи от вашите изисквания
- Поставете базата данни в режим на възстановяване, така че да не се правят допълнителни промени в базата данни
- Преместете регистрационните файлове
- Възстановете регистрационния файл(и) на базата данни за транзакции – при условие, че вече сте възстановили пълното архивиране на базата данни в целевата точка и оставите базата данни в състояние на възстановяване.
- Клонирайте данните за вход и коригирайте потребителите сираци
- Създаване на работни места
- Инсталирайте приложението
- Конфигуриране на мрежа – Променете DNS записи
- Преконфигурирайте настройките на приложението
- Стартирайте услугата за приложения
- Тествайте приложението
Първи стъпки
В тази статия ще обсъдим как да се справим с миграцията на много голяма OLTP база данни. Ще обсъдим стратегии за използване на техники на SQL сървър и инструменти на трети страни за безопасност на данните, заедно с нулево или минимално нарушаване на наличността на производствената система. По време на процеса винаги има шанс да загубите данните. Смятате ли, че безпроблемното управление на транзакциите е добра стратегия? Ако „да“, кои са любимите ви опции?
Нека се потопим дълбоко в наличните опции:
- Архивиране и възстановяване
- Доставка на дневници
- Огледално копиране на база данни
- Инструменти на трети страни
Архивиране и възстановяване
Техниката на база данни за архивиране и възстановяване е най-жизнеспособната опция за всяка миграция на база данни. Ако е планирано и тествано правилно, ще избегнем много непредвидени грешки при миграция. Всички знаем, че архивирането е онлайн процес, лесно е да инициирате архивиране на регистрационния файл на транзакции своевременно, за да стесните броя на транзакциите, които трябва да бъдат предоставени на новата база данни. По време на прозореца за миграция можем да ограничим достъпа на потребителите до базата данни и да инициираме едно последно архивиране на регистрационните файлове и да го прехвърлим до местоназначението. По този начин времето за престой може да бъде съкратено значително.
Доставка на дневници
Всички разбираме важността на лог файловете в света на базата данни. Техниката за доставка на регистрационни файлове предлага добро решение за възстановяване при бедствия и поддържа ограничен достъп само за четене до вторични бази данни по време на интервала между задачите за възстановяване. По същество това е концепция за архивиране на дневника на транзакциите и се възпроизвежда при пълно архивиране на още една вторична база данни. Тези вторични бази данни са дублиращи се копия на първичната база данни и непрекъснато възстановяват резервните копия на регистрационния файл на транзакциите в собственото си копие, за да го поддържат в синхрон с основната база данни. Тъй като вторичната база данни е на отделен хардуер, в случай на повреда на основния по някаква причина, напълно архивираното копие на системата е незабавно достъпно за използване и мрежовият трафик може просто да бъде пренасочен към вторичния сървър, без никой потребител да знае, че е възникнала грешка. Доставката на дневници осигурява лесен и ефективен начин за управление на миграцията в по-голяма степен в повечето случаи.
Огледално
Дублирането на база данни също е опция за миграция на база данни, при условие че и източникът, и целта са с едни и същи версии и издания. По същество дублирането създава две дублиращи се копия на база данни на два хардуерни екземпляра. Транзакциите ще се извършват и в двете бази данни едновременно. Имате възможността да изведете производствена база данни офлайн, да преминете към огледалната версия на тази база данни и да позволите на потребителите да продължат да осъществяват достъп до данните, сякаш нищо не се е случило. По отношение на прилагането му, ние се занимаваме с основен сървър, огледален сървър и свидетел. Но това ще бъде остаряла функция и ще бъде премахната от бъдещите версии на SQL Server.
Резюме
В тази статия обсъдихме видовете резервни копия, архивиране на регистрационни файлове на транзакции в детайли, стандартите за миграция на данни, процес и стратегия, научихме се да използваме SQL техники за ефективно боравене със стъпките за миграция на данни.
Механизмът за писане на регистрационни файлове на транзакции WAL гарантира, че транзакциите винаги се записват първо в регистрационния файл. По този начин SQL Server гарантира, че ефектите от всички извършени транзакции в крайна сметка ще бъдат записани във файловете с данни (на диска) и че всякакви модификации на данни на диска, които произлизат от непълни транзакции, ще бъдат ВРЪЩАНЕ и няма да бъдат отразени във файловете с данни.
В повечето случаи забавянето на синхронизирането на данните е непредвидено и загубата на данни е постоянна. По-често всичко зависи от размера на базата данни и наличната инфраструктура. Като препоръчителна практика е по-добре да изпълнявате миграциите ръчно, отколкото като част от внедряването, за да запазите нещата разделени, така че изходът да може да бъде по-предвидим.
Лично аз бих предпочел доставката на регистрационни файлове по различни причини:Можете да направите пълно архивиране на данните от стария сървър доста предварително, да го прехвърлите на новия сървър, да го възстановите и след това да приложите остатъчните транзакции (t-log архивиране ) от точката до момента на прекъсване. Процесът всъщност е доста прост.
Миграцията на база данни не е трудна, ако се извършва по правилния начин. Надявам се тази публикация да ви помогне да изпълнявате миграциите на базата данни по-плавно.
