Transakční protokoly jsou zásadní a důležitou součástí databázové architektury. V tomto článku probereme protokoly transakcí SQL Server, důležitost a jejich roli při migraci databáze.
Úvod
Pojďme si promluvit o různých možnostech zálohování SQL Serveru. SQL Server podporuje tři různé typy záloh.
1. Úplné
2. Diferenciál
3. Transakční protokol
Než se pustíme do konceptů transakčního protokolu, proberme další základní typy zálohování v SQL Server.
Úplná záloha je kopií všeho. Jak název napovídá, bude zálohovat vše. Zálohuje všechna data, každý objekt databáze, jako je soubor, skupina souborů, tabulka atd.:– Úplná záloha je základem pro jakýkoli jiný typ záloh.
Rozdílová záloha bude zálohovat data, která se od poslední plné zálohy změnila.
Třetí možností je Transaction-Log Backup, která zaznamená do transakčního protokolu všechny výpisy, které vystavíme do databáze. Transakční protokol je mechanismus známý jako „WAL“ (Write-Ahead-Logging). Nejprve zapíše každou informaci do transakčního protokolu a poté do databáze. Jinými slovy, proces obvykle neaktualizuje databázi přímo. Toto je jediná plně dostupná možnost s modelem úplné obnovy databáze. V jiných modelech obnovy jsou data buď částečná, nebo v protokolu není dostatek dat. Například záznam protokolu při záznamu začátku nové transakce (záznam protokolu LOP_BEGIN_XACT) bude obsahovat čas zahájení transakce a záznamy protokolu LOP_COMMIT_XACT (nebo LOP_ABORT_XACT) zaznamenají čas, kdy byla transakce potvrzena (nebo přerušena).
Chcete-li najít vnitřní části online protokolu transakcí, můžete se zeptat na funkci sys.fn_dblog.
Systémová funkce sys.fn_dblog přijímá dva parametry, první, počáteční LSN a koncové LSN transakce. Ve výchozím nastavení je nastavena na NULL. Pokud je nastavena na NULL, vrátí všechny záznamy protokolu ze souboru protokolu transakcí.
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)
Jak všichni víme, transakce jsou uloženy v binárním formátu a nejsou v čitelném formátu. Chcete-li číst soubor protokolu offline transakcí, můžete použít fn_dump_dblog.
Pojďme se dotázat na soubor protokolu transakcí, abychom viděli, kdo zahodil objekt pomocí 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%'
Použijeme funkci fn_dblog() k načtení aktivní části transakčního protokolu pro zjištění aktivity, která se provádí na datech. Jakmile je transakční protokol vymazán, musíte se dotazovat na data ze souboru protokolu pomocí fn_dump_dblog().
Tato funkce poskytuje stejnou sadu řádků jako fn_dblog(), ale má některé zajímavé funkce, díky kterým je užitečná, jsou některé scénáře řešení problémů a obnovy. Konkrétně může číst nejen transakční protokol aktuální databáze, ale také zálohy transakčního protokolu na disku nebo pásce.
Chcete-li získat seznam objektů, které byly odstraněny pomocí transakčního souboru, spusťte následující dotaz. Zpočátku jsou data uložena do dočasné tabulky. V některých případech trvá provedení fun_dump_dblog() trochu déle. Je tedy lepší zaznamenávat data do dočasné tabulky.
Chcete-li získat ID objektu ze sloupce Informace o zámku, spusťte následující dotaz.
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%'
Chcete-li získat ID objektu ze sloupce Informace o zámku, spusťte následující dotaz.
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 lze nalézt manipulací s hodnotou sloupce Informace o zámku. Chcete-li najít název objektu pro odpovídající ID objektu, obnovte databázi ze zálohy těsně předtím, než dojde k vypuštění tabulky. Po obnovení se můžete dotázat na systémový pohled a získat název objektu.
USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';
Nyní se podívejme na různé formy stejných podrobností transakce pomocí sys.dn_dblog, sys.fn_full_dblog. Systémová funkce fn_full_dblog funguje pouze se serverem SQL Server 2017.
Dotaz k načtení 10 nejlepších transakcí pomocí fn_dblog.
SELECT TOP 10 * FROM sys.fn_dblog(null,null)
Od SQL Server 2017 můžete používat fn_full dblog.
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)
Můžete se dále ponořit do systémové funkce pomocí sp_helptext fn_full_dblog.
Dále vyhledejte záložní soubor pomocí systémové funkce pomocí fn_full_dblog. Opět platí, že to platí pouze od SQL Server 2017 a novější.
Obnovení v určitém okamžiku
Předpokládejme, že máte seznam celé zálohy protokolu, a když máte v úmyslu protokoly obnovit, máte možnost provést obnovu dat v určitém okamžiku. V procesu obnovy protokolu tedy nemusíte nutně obnovit všechna data, můžete je obnovit až do, před nebo po jakékoli jednotlivé transakci. Pokud tedy databáze havaruje v určitou dobu a máme plnou zálohu i zálohy protokolů, měli bychom být schopni nejprve obnovit úplnou zálohu a poté obnovit zálohu protokolu a v tomto procesu obnovit poslední protokol do určité doby. , a to by ponechalo databázi v přesném stavu, v jakém byla předtím, než k tomuto problému došlo.
Zálohy protokolů jsou docela běžné databáze VLDB (Very Large Database) a nejdůležitější databáze. Vždy se doporučuje otestovat proces obnovy. Při každém zálohování databáze se doporučuje proces obnovy dobře promyslet a vždy byste měli proces obnovy testovat častěji.
Vždy je dobré čas od času zmírnit testování procesu obnovy, takže se jen ujistěte, že proces prochází zálohami normálně.
Scénáře
Pojďme si promluvit o scénáři, kdy potřebujete obnovit velmi rozsáhlou databázi a všichni víme, že to normálně může trvat několik hodin, a to je něco, co by si měl každý uvědomit. Pokud plánujete migraci databáze s nulovou ztrátou dat a menšími výpadky, může to být stále dost velký problém. Takže se ujistěte, že se spoléháte na zálohu protokolu transakcí, abyste proces urychlili.
Podívejme se na další scénář, kdy provádíte souběžnou migraci databáze mezi dvěma různými verzemi SQL Server; podílíte se na migraci databáze na stejnou verzi softwaru v cíli a to zahrnuje přenos operačního systému, databáze, aplikace a sítě atd.:-; migraci databáze z jednoho kusu hardwaru na druhý; změnou softwaru i hardwaru. Proces migrace databáze je vždy výzvou, kde je ztráta dat vždy možná a je vystavena okolnímu prostředí.
Osvědčené postupy migrace databáze
Pojďme diskutovat o standardních postupech správy migrace databází.
Migrace musí být provedena transakčním způsobem, aby se předešlo nesrovnalostem v datech. Obvyklé kroky procesu migrace jsou obvykle následující:
- Zastavte aplikační službu – zde začíná prostoj
- Spusťte zálohování protokolu, záleží na vašich požadavcích
- Uveďte databázi do režimu obnovy, aby v databázi nebyly provedeny žádné další změny
- Přesuňte soubor(y) protokolu
- Obnovte databázi Soubor(y) protokolu transakcí – za předpokladu, že jste již obnovili úplnou zálohu databáze v cíli a ponechali databázi ve stavu obnovy.
- Klonujte přihlašovací údaje a opravte osiřelé uživatele
- Vytvářejte úlohy
- Nainstalujte aplikaci
- Konfigurovat síť – Změňte záznamy DNS
- Znovu nakonfigurujte nastavení aplikace
- Spusťte službu aplikace
- Otestujte aplikaci
Začínáme
V tomto článku probereme, jak zvládnout migraci velmi rozsáhlé databáze OLTP. Probereme strategie využití technik SQL serveru a nástrojů třetích stran pro bezpečnost dat spolu s nulovým nebo minimálním narušením dostupnosti produkčního systému. Během procesu existuje vždy možnost ztráty dat. Myslíte si, že bezproblémové zpracování transakcí je dobrá strategie? Pokud „ano“, jaké jsou vaše oblíbené možnosti?
Pojďme se hluboce ponořit do dostupných možností:
- Zálohování a obnovení
- Zapsat zásilku
- Zrcadlení databáze
- Nástroje třetích stran
Zálohování a obnovení
Technika zálohování a obnovy databáze je nejschůdnější možností pro jakoukoli migraci databáze. Pokud to bude správně naplánováno a otestováno, vyhneme se mnoha nepředvídatelným chybám při migraci. Všichni víme, že zálohování je online proces, je snadné včas zahájit zálohování protokolu transakcí, aby se zúžil počet transakcí, které mají být dodány do nové databáze. Během okna migrace můžeme omezit přístup uživatelů k databázi a zahájit poslední zálohu protokolu a přenést jej do cíle. Tímto způsobem lze výrazně zkrátit prostoje.
Zapsat zásilku
Všichni chápeme důležitost souborů protokolu ve světě databází. Technika odesílání protokolů nabízí dobré řešení obnovy po havárii a podporuje omezený přístup pouze pro čtení k sekundárním databázím během intervalu mezi úlohami obnovy. Je to v podstatě koncept zálohování protokolu transakcí a je přehrán v plné záloze v jedné další sekundární databázi. Tyto sekundární databáze jsou duplicitní kopie primární databáze a neustále obnovují zálohy protokolu transakcí do své vlastní kopie, aby byly synchronizovány s primární databází. Vzhledem k tomu, že sekundární databáze je na samostatném hardwaru, v případě selhání primární z jakéhokoli důvodu je plně zálohovaná kopie systému okamžitě k dispozici k použití a síťový provoz lze jednoduše přesměrovat na sekundární server, aniž by kdokoli věděl, že došlo k závadě. Odesílání protokolů poskytuje ve většině případů snadný a efektivní způsob, jak ve větší míře řídit migraci.
Zrcadlení
Zrcadlení databáze je také možností pro migraci databáze za předpokladu, že zdroj i cíl mají stejné verze a edice. Zrcadlení v podstatě vytváří dvě duplicitní kopie databáze na dvou instancích hardwaru. Transakce by probíhaly na obou databázích současně. Máte možnost převést produkční databázi do režimu offline, přepnout na zrcadlenou verzi této databáze a umožnit uživatelům pokračovat v přístupu k datům, jako by se nic nestalo. V rámci implementace se zabýváme hlavním serverem, zrcadlovým serverem a svědkem. Ale bude to zastaralá funkce a bude odstraněna z budoucích verzí SQL Server.
Shrnutí
V tomto článku jsme diskutovali o typech záloh, podrobně o zálohování protokolu transakcí, standardech migrace dat, procesu a strategii, naučili jsme se používat techniky SQL pro efektivní zpracování kroků migrace dat.
Mechanismus zápisu transakčního protokolu WAL zajišťuje, že transakce jsou vždy zapsány do souboru protokolu jako první. Tímto způsobem SQL Server zaručuje, že účinky všech potvrzených transakcí budou nakonec zapsány do datových souborů (na disk) a že jakékoli úpravy dat na disku, které pocházejí z neúplných transakcí, budou vráceny zpět a neprojeví se v datových souborech.
Ve většině případů je zpoždění v synchronizaci dat nepředvídatelné a ztráta dat je trvalá. Více často než ne, vše závisí na velikosti databáze a dostupné infrastruktuře. Jako doporučený postup je lepší spouštět migrace ručně než jako součást nasazení, aby byly věci odděleny, aby byl výstup předvídatelnější.
Osobně bych preferoval odesílání protokolu z různých důvodů:Můžete si udělat úplnou zálohu dat ze starého serveru s dostatečným předstihem, přenést je na nový server, obnovit je a poté použít zbývající transakce (záloha t-log ) od bodu až do okamžiku přerušení. Proces je vlastně docela jednoduchý.
Migrace databáze není obtížná, pokud je provedena správným způsobem. Doufám, že vám tento příspěvek pomůže spustit migraci databáze hladším způsobem.