Transaktionsloggar är en viktig och viktig komponent i databasarkitekturen. I den här artikeln kommer vi att diskutera SQL Server-transaktionsloggar, betydelse och deras roll i databasmigreringen.
Introduktion
Låt oss prata om olika alternativ för att ta SQL Server-säkerhetskopior. SQL Server stöder tre olika typer av säkerhetskopior.
1. Full
2. Differential
3. Transaktionslogg
Innan vi går in i transaktionsloggkoncept, låt oss diskutera andra grundläggande säkerhetskopieringstyper i SQL Server.
En fullständig säkerhetskopia är en kopia av allt. Som namnet antyder kommer det att säkerhetskopiera allt. Den kommer att säkerhetskopiera all data, varje objekt i databasen som en fil, filgrupp, tabell, etc:– En fullständig säkerhetskopia är en bas för alla andra typer av säkerhetskopior.
En differentiell säkerhetskopiering kommer att säkerhetskopiera data som har ändrats sedan den senaste fullständiga säkerhetskopieringen.
Det tredje alternativet är en Transaction-Log Backup, som loggar alla uttalanden som vi utfärdar till databasen i transaktionsloggen. Transaktionsloggen är en mekanism som kallas "WAL" (Write-Ahead-Logging). Den skriver ut varje information till transaktionsloggen först och sedan till databasen. Med andra ord, processen uppdaterar vanligtvis inte databasen direkt. Detta är det enda tillgängliga alternativet med fullständig återställningsmodell av databasen. I andra återställningsmodeller är data antingen partiell eller så finns det inte tillräckligt med data i loggen. Till exempel kommer loggposten vid registrering av starten av en ny transaktion (LOP_BEGIN_XACT-loggposten) att innehålla tidpunkten då transaktionen startade, och loggposterna LOP_COMMIT_XACT (eller LOP_ABORT_XACT) kommer att registrera tiden då transaktionen genomfördes (eller avbröts).
För att hitta interna delar av transaktionslogg online kan du fråga efter sys.fn_dblog-funktionen.
Systemfunktionen sys.fn_dblog accepterar två parametrar, först börjar LSN och slutar LSN för transaktionen. Som standard är den inställd på NULL. Om den är inställd på NULL kommer den att returnera alla loggposter från transaktionsloggfilen.
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)
Som vi alla vet lagras transaktionerna i binärt format och det är inte i ett läsbart format. För att läsa offlinetransaktionsloggfilen kan du använda fn_dump_dblog.
Låt oss fråga transaktionsloggfilen för att se vem som har tappat objektet med hjälp av 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%'
Vi kommer att använda funktionen fn_dblog() för att läsa den aktiva delen av transaktionsloggen för att hitta aktivitet som utförs på data. När transaktionsloggen har rensats måste du fråga efter data från en loggfil med fn_dump_dblog().
Den här funktionen tillhandahåller samma raduppsättning som fn_dblog(), men har en del intressant funktionalitet som gör det användbart i vissa felsöknings- och återställningsscenarier. Specifikt kan den läsa inte bara transaktionsloggen för den aktuella databasen, utan även säkerhetskopior av transaktionsloggar på antingen disk eller band.
För att få listan över objekt som släpps med hjälp av transaktionsfil, kör följande fråga. Initialt dumpas data till temptabellen. I vissa fall tar exekveringen av fun_dump_dblog() lite längre tid att köra. Så det är bättre att fånga data i temptabellen.
För att få ett objekt-ID från kolumnen Låsinformation, kör följande fråga.
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%'
För att få ett objekt-ID från kolumnen Låsinformation, kör följande fråga.
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 kan hittas genom att manipulera kolumnvärdet för låsinformation. För att hitta objektnamn för motsvarande objekt-id, återställ databasen från säkerhetskopian precis innan tabellen släpptes. Efter återställningen kan du fråga systemvyn för att få objektnamnet.
USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';
Låt oss nu se de olika formerna av samma transaktionsdetaljer med sys.dn_dblog, sys.fn_full_dblog. Systemfunktionen fn_full_dblog fungerar endast med SQL Server 2017.
Fråga för att hämta de 10 bästa transaktionerna med fn_dblog.
SELECT TOP 10 * FROM sys.fn_dblog(null,null)
Från SQL Server 2017 och framåt kan du använda fn_full dblog.
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)
Du kan fördjupa dig i systemfunktionen ytterligare med sp_helptext fn_full_dblog.
Fråga sedan säkerhetskopian med hjälp av systemfunktionen med fn_full_dblog. Återigen, detta är endast tillämpligt från SQL Server 2017 och framåt.
Återställning vid tidpunkt
Låt oss anta att du har listan över hela loggbackupen, och när du sedan tänker återställa loggarna har du möjligheten att utföra en punkt-i-tid-återställning av data. Så i processen med loggåterställning behöver du inte nödvändigtvis återställa all data, du kan återställa den ända fram till, före eller efter en enskild transaktion. Så om databasen kraschar vid en viss tidpunkt, och vi har både fullständig säkerhetskopia och loggsäkerhetskopior, bör vi först kunna återställa den fullständiga säkerhetskopian och sedan återställa loggsäkerhetskopian, och i processen återställa den sista loggen till en viss tidpunkt , och det skulle lämna databasen i det exakta tillstånd den var i innan det här problemet uppstod.
Loggbackuper är ganska vanliga VLDB (Very Large Database) och de flesta kritiska databaser. Det rekommenderas alltid att testa återställningsprocessen. När du gör säkerhetskopior av databas, rekommenderas det att du tänker på återställningsprocessen väl, och du bör alltid testa återställningsprocessen oftare.
Det är alltid bra att lätta på att testa återställningsprocessen då och då, så se bara till att processen går igenom säkerhetskopiorna normalt.
Scenarier
Låt oss prata om ett scenario, när du behöver återställa en mycket stor databas och vi alla vet att det normalt kan ta flera timmar, och det är något som alla borde vara medvetna om. Om du planerar för databasmigrering med noll dataförlust och mindre avbrottsfönster kan det fortfarande vara ett ganska stort problem. Så du ser till att lita på säkerhetskopiering av transaktionsloggar för att påskynda processen.
Låt oss överväga ett annat scenario där du utför en databasmigrering sida vid sida mellan två olika versioner av SQL Server; du är involverad i att migrera databasen till samma programvaruversion på målet och det inkluderar överföring av operativsystem, databas, applikation och nätverk etc:-; migrera databasen från en maskinvara till en annan; ändra både mjukvara och hårdvara. Processen för databasmigrering är alltid utmaningen där dataförlust alltid är möjlig och den är utsatt för miljön.
Bästa metoder för databasmigrering
Låt oss diskutera standardpraxis för databasmigreringshantering.
Migrering måste ske på ett transaktionsmässigt sätt för att undvika inkonsekvenser i data. De vanliga stegen i migreringsprocessen är vanligtvis följande:
- Stoppa applikationstjänsten – det är här driftstoppet börjar
- Initiera loggsäkerhetskopiering, det beror på dina krav
- Sätt databasen i återställningsläge så att inga ytterligare ändringar i databasen görs
- Flytta loggfilen(erna)
- Återställ databasens transaktionsloggfil(er) – förutsatt att du redan har återställt databasens fullständiga säkerhetskopia på målet och lämnar databasen i återställningstillstånd.
- Klona inloggningarna och fixa de föräldralösa användarna
- Skapa jobb
- Installera programmet
- Konfigurera nätverk – Ändra DNS-poster
- Konfigurera om programinställningarna
- Starta applikationstjänst
- Testa applikationen
Komma igång
I den här artikeln kommer vi att diskutera hur man hanterar mycket stor OLTP-databasmigrering. Vi kommer att diskutera strategier för att använda SQL-servertekniker och tredjepartsverktyg för datasäkerhet tillsammans med noll eller minimal störning av produktionssystemets tillgänglighet. Under processen finns det alltid en chans att förlora data. Tycker du att sömlös hantering av transaktioner är en bra strategi? Om "ja", vilka är dina favoritalternativ?
Låt oss fördjupa oss i de tillgängliga alternativen:
- Säkerhetskopiera och återställa
- Loggleverans
- Databasspegling
- tredje parts verktyg
Säkerhetskopiera och återställa
Databastekniken Säkerhetskopiera och återställa är det mest genomförbara alternativet för all databasmigrering. Om det planeras och testas ordentligt kommer vi att undvika många oförutsedda migreringsfel. Vi vet alla att säkerhetskopieringen är en onlineprocess, det är lätt att initiera säkerhetskopiering av transaktionsloggar i tid för att minska antalet transaktioner som ska levereras till den nya databasen. Under migreringsfönstret kan vi begränsa användarnas åtkomst till databasen och initiera en sista loggsäkerhetskopiering och överföra den till destinationen. På så sätt kan stilleståndstiden förkortas avsevärt.
Loggleverans
Vi förstår alla vikten av loggfilerna i databasvärlden. Loggsändningsteknik erbjuder en bra katastrofåterställningslösning och stöder begränsad skrivskyddad åtkomst till sekundära databaser under intervallet mellan återställningsjobb. Det är i huvudsak ett koncept för att säkerhetskopiera transaktionsloggen och spelas upp på en fullständig säkerhetskopia på ytterligare en sekundär databas. Dessa sekundära databaser är dubbla kopior av den primära databasen och återställer kontinuerligt transaktionsloggens säkerhetskopior till sin egen kopia, för att hålla den synkroniserad med den primära databasen. Eftersom den sekundära databasen är på separat hårdvara, i händelse av fel på primär av någon anledning, är den fullständigt säkerhetskopierade kopian av systemet omedelbart tillgänglig för användning och nätverkstrafik kan helt enkelt omdirigeras till den sekundära servern, utan att någon användare vet att en fel har uppstått. Loggfrakt ger ett enkelt och effektivt sätt att hantera migrering i större utsträckning i de flesta fall.
Spegling
Databasspegling är också ett alternativ för databasmigrering förutsatt att både källan och målet är av samma versioner och utgåvor. I huvudsak skapar spegling två dubbletter av en databas på två hårdvaruinstanser. Transaktioner skulle ske på båda databaserna samtidigt. Du har möjligheten att ta en produktionsdatabas offline, byta över till den speglade versionen av den databasen och tillåta användare att fortsätta komma åt data som om ingenting hade hänt. När det gäller implementeringen har vi att göra med en huvudserver, en spegelserver och ett vittne. Men det kommer att vara en föråldrad funktion och den kommer att tas bort från framtida versioner av SQL Server.
Sammanfattning
I den här artikeln diskuterade vi typer av säkerhetskopior, säkerhetskopiering av transaktionsloggar i detalj, datamigreringsstandarder, process och strategi, lärt oss att använda SQL-tekniker för effektiv hantering av datamigreringssteg.
Skrivmekanismen för transaktionslogg WAL säkerställer att transaktioner alltid skrivs till loggfilen först. På detta sätt garanterar SQL Server att effekterna av alla genomförda transaktioner i slutändan kommer att skrivas in i datafilerna (till disken), och att alla dataändringar på disken som härrör från ofullständiga transaktioner kommer att återställas och inte återspeglas i datafilerna.
I de flesta fall är förseningen i datasynkroniseringen oförutsedd och dataförlusten är permanent. Oftare än inte beror allt på storleken på databasen och tillgänglig infrastruktur. Som en rekommenderad praxis är det bättre att köra migreringar manuellt än som en del av distributionen för att hålla saker åtskilda så att utdata kan bli mer förutsägbar.
Personligen skulle jag föredra loggfrakt av olika anledningar:Du kan ta en fullständig säkerhetskopia av data från den gamla servern i god tid, få över den till den nya servern, återställa den och sedan använda de återstående transaktionerna (t-log backup ) från punkten ända fram till ögonblicket för cutover. Processen är faktiskt ganska enkel.
Databasmigrering är inte svårt om det görs på rätt sätt. Jag hoppas att det här inlägget hjälper dig att köra databasmigreringarna på ett smidigare sätt.