Transactielogboeken zijn een essentieel en belangrijk onderdeel van de database-architectuur. In dit artikel bespreken we SQL Server-transactielogboeken, het belang en hun rol bij de databasemigratie.
Inleiding
Laten we het hebben over verschillende opties voor het maken van back-ups van SQL Server. SQL Server ondersteunt drie verschillende soorten back-ups.
1. Volledig
2. Differentieel
3. Transactielogboek
Laten we, voordat we ingaan op transactielogboekconcepten, andere basisback-uptypen in SQL Server bespreken.
Een volledige back-up is een kopie van alles. Zoals de naam al aangeeft, maakt het een back-up van alles. Het maakt een back-up van alle gegevens, elk object van de database, zoals een bestand, bestandsgroep, tabel, enz.:– Een volledige back-up is de basis voor elk ander type back-up.
Een differentiële back-up maakt een back-up van gegevens die zijn gewijzigd sinds de laatste volledige back-up.
De derde optie is een transactielogboekback-up, die alle verklaringen die we uitgeven in de database in het transactielogboek logt. Het transactielogboek is een mechanisme dat bekend staat als "WAL" (Write-Ahead-Logging). Het schrijft elk stukje informatie eerst naar het transactielogboek en vervolgens naar de database. Met andere woorden, het proces werkt de database doorgaans niet rechtstreeks bij. Dit is de enige volledig beschikbare optie met het volledige herstelmodel van de database. In andere herstelmodellen zijn de gegevens gedeeltelijk of zijn er niet genoeg gegevens in het logboek. Het logrecord bij het vastleggen van de start van een nieuwe transactie (het LOP_BEGIN_XACT-logrecord) zal bijvoorbeeld de tijd bevatten waarop de transactie is gestart, en de LOP_COMMIT_XACT (of LOP_ABORT_XACT) logrecords zullen het tijdstip waarop de transactie is gepleegd (of afgebroken) vastleggen.
Om de inhoud van het online transactielogboek te vinden, kunt u de functie sys.fn_dblog opvragen.
De systeemfunctie sys.fn_dblog accepteert twee parameters, ten eerste begin LSN en eind LSN van de transactie. Standaard is deze ingesteld op NULL. Als het is ingesteld op NULL, worden alle logrecords uit het transactielogbestand geretourneerd.
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)
Zoals we allemaal weten, worden de transacties opgeslagen in binair formaat en niet in een leesbaar formaat. Om het offline transactielogbestand te lezen, kunt u fn_dump_dblog gebruiken.
Laten we het transactielogbestand opvragen om te zien wie het object heeft laten vallen met behulp van de 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%'
We zullen de functie fn_dblog() gebruiken om het actieve gedeelte van het transactielogboek te lezen voor het vinden van activiteit die op de gegevens wordt uitgevoerd. Zodra het transactielogboek is gewist, moet u de gegevens uit een logbestand opvragen met fn_dump_dblog().
Deze functie biedt dezelfde rijenset als fn_dblog(), maar heeft een aantal interessante functionaliteit die het handig maakt, zoals enkele probleemoplossings- en herstelscenario's. Het kan met name niet alleen het transactielogboek van de huidige database lezen, maar ook back-ups van transactielogboeken op schijf of tape.
Voer de volgende query uit om de lijst te krijgen van de objecten die zijn verwijderd met het transactiebestand. In eerste instantie worden de gegevens naar de tijdelijke tabel gedumpt. In sommige gevallen duurt de uitvoering van fun_dump_dblog() iets langer om uit te voeren. Het is dus beter om de gegevens in de tijdelijke tabel vast te leggen.
Voer de volgende query uit om een object-ID uit de kolom Vergrendelingsinformatie te krijgen.
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%'
Voer de volgende query uit om een object-ID uit de kolom Vergrendelingsinformatie te krijgen.
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
De object_id kan worden gevonden door de kolomwaarde Lock Information te manipuleren. Om de objectnaam voor het corresponderende object-ID te vinden, herstelt u de database vanaf de back-up net voordat de tabel werd verwijderd. Na het terugzetten kunt u de systeemweergave opvragen om de objectnaam te krijgen.
USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';
Laten we nu de verschillende vormen van dezelfde transactiedetails bekijken met sys.dn_dblog, sys.fn_full_dblog. De systeemfunctie fn_full_dblog werkt alleen met SQL Server 2017.
Vraag om de top 10 transacties op te halen met fn_dblog.
SELECT TOP 10 * FROM sys.fn_dblog(null,null)
Vanaf SQL Server 2017 kunt u fn_full dblog gebruiken.
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)
U kunt zich verder verdiepen in de systeemfunctie met behulp van de sp_helptext fn_full_dblog.
Vraag vervolgens het back-upbestand op met behulp van de systeemfunctie met fn_full_dblog. Nogmaals, dit is alleen van toepassing vanaf SQL Server 2017.
Tijdsherstel
Laten we aannemen dat u de lijst met de volledige logback-up hebt, en wanneer u van plan bent de logbestanden te herstellen, hebt u de mogelijkheid om de gegevens op een bepaald tijdstip te herstellen. Tijdens het proces van logherstel hoeft u dus niet per se alle gegevens te herstellen, u kunt deze herstellen tot, voor of na een individuele transactie. Dus als de database op een bepaald tijdstip crasht en we zowel volledige back-up als logback-ups hebben, moeten we eerst de volledige back-up kunnen herstellen en vervolgens de logback-up kunnen herstellen, en daarbij het laatste logbestand kunnen herstellen tot een bepaalde tijd , en dat zou de database in de exacte staat achterlaten waarin deze zich bevond voordat dit probleem zich voordeed.
Logboekback-ups zijn vrij algemeen VLDB (Very Large Database) en de meest kritieke databases. Het wordt altijd aanbevolen om het herstelproces te testen. Wanneer u databaseback-ups maakt, is het raadzaam om goed na te denken over het herstelproces, en u moet het herstelproces altijd vaker testen.
Het is altijd goed om af en toe het testen van het herstelproces te verlichten, dus zorg ervoor dat het proces de back-ups normaal doorloopt.
Scenario's
Laten we het hebben over een scenario waarin u een zeer grote database moet herstellen en we weten allemaal dat dit normaal gesproken enkele uren kan duren, en dat is iets waar iedereen zich bewust van moet zijn. Als u databasemigratie plant zonder gegevensverlies en kleinere uitvalperiodes, kan dat nog steeds een behoorlijk groot probleem zijn. Zorg er dus voor dat u vertrouwt op de back-up van transactielogboeken om het proces te versnellen.
Laten we een ander scenario bekijken waarin u een databasemigratie naast elkaar uitvoert tussen twee verschillende versies van SQL Server; je bent betrokken bij het migreren van de database naar dezelfde softwareversie op het doel en dat omvat de overdracht van het besturingssysteem, de database, de applicatie en het netwerk, enz.:-; het migreren van de database van het ene stuk hardware naar het andere; het wijzigen van zowel software als hardware. Het proces van databasemigratie is altijd de uitdaging waarbij gegevensverlies altijd mogelijk is en onderhevig is aan de omgeving.
Best practices voor databasemigratie
Laten we de standaardpraktijken van databasemigratiebeheer bespreken.
Migratie moet op een transactionele manier worden uitgevoerd om inconsistenties in de gegevens te voorkomen. De gebruikelijke stappen van het migratieproces zijn gewoonlijk de volgende:
- Stop de applicatieservice:hier begint de uitvaltijd
- Start logboekback-up, dit hangt af van uw vereisten
- Zet de database in de herstelmodus zodat er geen verdere wijzigingen aan de database worden aangebracht
- Verplaats de logfile(s)
- Herstel de database Transactielogboekbestand(en):op voorwaarde dat u de volledige back-up van de database al op het doel hebt hersteld en de database in de herstelstatus hebt gelaten.
- Kloon de aanmeldingen en herstel de weesgebruikers
- Vacatures maken
- Installeer de applicatie
- Netwerk configureren – DNS-vermeldingen wijzigen
- App-instellingen opnieuw configureren
- Start applicatieservice
- Test de applicatie
Aan de slag
In dit artikel bespreken we hoe u omgaat met zeer grote OLTP-databasemigratie. We zullen strategieën bespreken om SQL-servertechnieken en tools van derden te gebruiken voor gegevensveiligheid, samen met nul of minimale verstoring van de beschikbaarheid van het productiesysteem. Tijdens het proces is er altijd een kans om de gegevens te verliezen. Vindt u het naadloos afhandelen van transacties een goede strategie? Zo "ja", wat zijn uw favoriete opties?
Laten we dieper ingaan op de beschikbare opties:
- Back-up maken en terugzetten
- Log verzending
- Database spiegelen
- Hulpprogramma's van derden
Back-up en herstel
De back-up-en-herstel-databasetechniek is de meest haalbare optie voor elke databasemigratie. Als het goed is gepland en getest, zullen we veel onvoorziene migratiefouten voorkomen. We weten allemaal dat de back-up een online proces is, het is gemakkelijk om tijdig een back-up van het transactielogboek te starten om het aantal transacties te beperken dat aan de nieuwe database moet worden geleverd. Tijdens het migratievenster kunnen we de toegang van gebruikers tot de database beperken en een laatste logback-up starten en deze naar de bestemming overbrengen. Op deze manier kan de uitvaltijd aanzienlijk worden verkort.
Log verzending
We begrijpen allemaal het belang van de logbestanden in de databasewereld. Logboekverzendingstechniek biedt een goede oplossing voor noodherstel en ondersteunt beperkte alleen-lezen toegang tot secundaire databases tijdens het interval tussen hersteltaken. Het is in wezen een concept van het maken van een back-up van het transactielogboek en wordt afgespeeld op een volledige back-up op nog een secundaire database. Deze secundaire databases zijn dubbele kopieën van de primaire database en herstellen de back-ups van het transactielogboek voortdurend naar hun eigen kopie, om deze synchroon te houden met de primaire database. Aangezien de secundaire database op aparte hardware staat, is de volledig geback-upte kopie van het systeem, in het geval van een storing in de primaire server om welke reden dan ook, onmiddellijk beschikbaar voor gebruik en kan het netwerkverkeer eenvoudig worden omgeleid naar de secundaire server, zonder dat gebruikers weten dat een storing is opgetreden. Logboekverzending biedt in de meeste gevallen een gemakkelijke en effectieve manier om migratie in grotere mate te beheren.
Spiegelen
Database Mirroring is ook een optie voor databasemigratie, op voorwaarde dat zowel de bron als het doel van dezelfde versies en edities zijn. In wezen creëert mirroring twee dubbele kopieën van een database op twee hardware-instanties. Transacties zouden gelijktijdig plaatsvinden op beide databases. U hebt de mogelijkheid om een productiedatabase offline te halen, over te schakelen naar de gespiegelde versie van die database en gebruikers toegang te geven tot de gegevens alsof er niets is gebeurd. In termen van implementatie hebben we te maken met een hoofdserver, een spiegelserver en een getuige. Maar het wordt een verouderde functie en wordt verwijderd uit toekomstige versies van SQL Server.
Samenvatting
In dit artikel hebben we de soorten back-ups besproken, Transactielogboekback-up in detail, gegevensmigratiestandaarden, proces en strategie, geleerd SQL-technieken te gebruiken voor een effectieve afhandeling van gegevensmigratiestappen.
Het transactielogboekschrijfmechanisme WAL zorgt ervoor dat transacties altijd eerst naar het logbestand worden geschreven. Op deze manier garandeert SQL Server dat de effecten van alle vastgelegde transacties uiteindelijk in de gegevensbestanden (naar schijf) worden geschreven en dat eventuele gegevenswijzigingen op schijf die afkomstig zijn van onvolledige transacties ROLLBACK worden en niet worden weerspiegeld in de gegevensbestanden.
In de meeste gevallen is de vertraging in de gegevenssynchronisatie onvoorzien en is gegevensverlies permanent. Meestal hangt het allemaal af van de grootte van de database en de beschikbare infrastructuur. Als aanbevolen praktijk is het beter om migraties handmatig uit te voeren dan als onderdeel van de implementatie om dingen gescheiden te houden, zodat de uitvoer voorspelbaarder kan zijn.
Persoonlijk zou ik om verschillende redenen de voorkeur geven aan Log-verzending:u kunt ruim van tevoren een volledige back-up van de gegevens van de oude server maken, deze naar de nieuwe server overbrengen, deze herstellen en vervolgens de resterende transacties toepassen (t-log-back-up ) vanaf het punt tot aan het moment van omschakelen. Het proces is eigenlijk vrij eenvoudig.
Databasemigratie is niet moeilijk als het op de juiste manier gebeurt. Ik hoop dat dit bericht je helpt om de databasemigraties soepeler uit te voeren.