Reparation af datatab ved hjælp af logforsendelse med forsinket gendannelse

Introduktion

Transaction Log Shipping er en meget velkendt teknologi, der bruges i SQL Server til at vedligeholde en kopi af den levende database på Disaster Recovery Site. Teknologien afhænger af tre nøgleopgaver:sikkerhedskopieringsjobbet, kopijobbet og gendannelsesjobbet. Mens sikkerhedskopieringsjobbet kører på den primære server, kører kopierings- og gendannelsesjob på den sekundære server. I det væsentlige involverer processen periodiske sikkerhedskopiering af transaktionslogfiler til en share, hvorfra kopijobbet flyttes til den sekundære server; efterfølgende anvender gendannelsesjobbet log-sikkerhedskopierne på den sekundære server. Før alt dette starter, skal den sekundære database initialiseres med en fuld sikkerhedskopi fra den primære server gendannet med NORECOVERY-indstillingen.

Microsoft leverer et sæt lagrede procedurer, der kan bruges til at konfigurere logforsendelse ende til ende samt GUI-ækvivalenter startende fra egenskabselementet for hver database, du måske ønsker at konfigurere logforsendelse for. Det er værd at bemærke, at den sekundære database kan konfigureres i NORECOVERY-tilstand eller i STANDBY-tilstand. I NORECOVERY-tilstand er databasen aldrig tilgængelig for forespørgsler, men i STANDBY-tilstand kan den sekundære database forespørges, når ingen transaktionsloggendannelse er i gang.

Opsætning af miljøet

For at få bolden til at rulle opretter vi to SQL Server-instanser på AWS med et identisk Amazon EC2-billede. Denne Amazon EC2-instans kører SQL Server 2017 RTM-CU5 på Windows Server 2016. Derefter gendanner vi en kopi af WideWorldImporters-databasen ved hjælp af et backupsæt, der er erhvervet fra GitHub, til den første instans, vores primære instans. Vi bruger det samme backupsæt til at oprette to identiske databaser ved navn BranchDB og CorporateDB.

Fig. 1 SQL Server-version

Fig. 2 BranchDB og CorporateDB på primær instans (sekundær instans blank)

Liste 1:Gendannelse af WideWorldImporters eksempeldatabase

gendan filelistonly fra disk='WideWorldImporters-Full.bak'restore database CorporateDB fra disk='WideWorldImporters-Full.bak' med stats=10,recovery,flyt 'WWI_Primary' til 'M:\MSSQL\Data\WWI_Primary. mdf', flyt 'WWI_UserData' til 'M:\MSSQL\Data\WWI_UserData.ndf', flyt 'WWI_Log' til 'N:\MSSQL\Log\WWI_Log.ldf', flyt 'WWI_InMemory_Data_1' til 'M:\MSSQ Data\WWI_InMemory_Data_1.ndf'gendan database BranchDB fra disk='WideWorldImporters-Full.bak' med stats=10,recovery,flyt 'WWI_Primary' til 'M:\MSSQL\Data\WWI_Primary1.mdf' , flyt 'WWI_UserData'_User M:\MSSQL\Data\WWI_UserData1.ndf' , flyt 'WWI_Log' til 'N:\MSSQL\Log\WWI_Log1.ldf', flyt 'WWI_InMemory_Data_1' til 'M:\MSSQL\Data\WWI_Inpre>1_Data 

 Vi har nu to forekomster, den primære forekomst, der er vært for de to primære databaser (BranchDB og CorporateDB og den sekundære forekomst uden brugerdatabaser. Vi fortsætter med at konfigurere transaktionslogforsendelse på begge databaser, men adskiller dem ved at anvende en forsinkelse på gendannelseskonfigurationen af første database. Husk, at databaserne faktisk er identiske med hensyn til de data, de indeholder. Følgende grafik viser de nøgleindstillinger, der er valgt i logforsendelseskonfigurationen.
 

 
 
Fig. 3 Sikkerhedskopieringsindstillinger for BranchDB
 

 
 

 
 
Fig. 4 Kopier indstillinger for BranchDB
 

 
 

 
 
Fig. 5 Gendan indstillinger for BranchDB
 

 Hvert logforsendelsesjob er konfigureret til at køre hvert femte minut. For at behandle "Forsinket gendannelse af sikkerhedskopier" skal vi bruge standbygendannelsestilstanden i logforsendelseskonfigurationen. Det er logisk, da det har den sekundære database i standby-tilstand og indikerer, at vi kan forespørge i den sekundære database, når en gendannelse af transaktionslog ikke er i gang. Den værdi, vi angiver i denne indstilling (30 minutter i dette tilfælde) giver os et godt vindue, hvor vi kan køre rapporter fra den sekundære database bortset fra kernekravet i denne artikel, som er at kunne gendanne efter brugerfejl.
 

 Vi bør også nævne, at gendannelsen af ​​sikkerhedskopier af transaktionslog faktisk bliver forsinket. Dens tidsstempling er senere end forsinkelsesværdien. Det betyder, at alle sikkerhedskopier af transaktionslog vil blive kopieret til den sekundære server, som er baseret på tidsplanen og specificeret i kopijobbet. Faktisk vil gendannelsesjobbet stadig køre planmæssigt, men sikkerhedskopier af transaktionslogfiler (der ikke er op til 30 minutter gamle) vil ikke blive gendannet. I det væsentlige er BranchDB Standby-databasen 30 minutter efter den primære BranchDB-database. For at demonstrere denne forsinkelse skal vi i næste afsnit oprette en tabel i begge databaser og oprette et job, der indsætter en post hvert minut. Vi vil undersøge denne tabel i de sekundære databaser.
 

 Indstillingerne for CorporateDB-databasen er de samme som i fig. 3 til 5, undtagen gendannelsesjobbet, som IKKE er indstillet til at forsinke sikkerhedskopiering af transaktionslog.
 

 
 
Fig. 6 Gendan indstillinger for CorporateDB
 

 
 
Bekræftelse af konfigurationen
 

 Når konfigurationen er færdig, kan vi bekræfte, at konfigurationen er OK og begynde med at observere dens arbejde. Transaktionslogforsendelsesrapporten viser os, at Branch DB faktisk halter efter CorporateDB med hensyn til gendannelser:
 

 
 
Fig. 7a Transaktionslogforsendelsesrapport på primær server
 

 
 

 
 
Fig. 7b Transaktionslogforsendelsesrapport på sekundær server
 

 Derudover vil du bemærke meddelelsen nedenfor i Gendan jobhistorikken for BranchDB:
 

 
 

 
 
Fig. 8 Oversprunget transaktionslog gendannes på sekundær server
 

 
 

 Vi kan gå videre med denne verifikation ved at oprette en tabel og bruge et job til at udfylde denne tabel med rækker hvert minut. Jobbet er en enkel måde at simulere, hvad en applikation kan gøre ved en brugertabel. Dette kan vise os, at denne forsinkelse definitivt vises i brugerdata.
 

 
 
Liste 2 – Opret logsporingstabel
 
brug BranchDBgocreate tabel log_ship_tracker( ID int identitet (100,1), Database_Name sysname default db_name(), RecordTime datetime default getdate(),ServerName sysname default @@servername)use CorporateDBgocreate table log_ship_tracker( ID int identitet (100,1) ),Database_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)
 
 
Liste 3 – Opret job for at udfylde logsporingstabel
 
/* ==Scripting Parameters==Kildeserverversion:SQL Server 2017 (14.0.3023)Source Database Engine Edition:Microsoft SQL Server Standard EditionSource Database Engine Type:Standalone SQL ServerTarget Server Version:SQL Server 2017Target Database Engine Edition:Microsoft SQL Server Standard Edition Target Database Engine Type :Standalone SQL Server*/USE [msdb]GO/******** Objekt:Job [InsertRecords] Scriptdato:7/2/2018 3:32:00 PM **** **/BEGIN TRANSACTIONDECLARE @ReturnCode INTSELECT @ReturnCode =0/****** Objekt:JobCategory [[Ukategoriseret (Lokal)]] Scriptdato:7/2/2018 15:32:00 ****** /IF NOT EXISTS (VÆLG navn FRA msdb.dbo.syscategories WHERE name=N'[Ukategoriseret (Local)]' OG category_class=1)BEGINEXEC @ReturnCode =msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Ukategoriseret (Lokal)]'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollbackENDDECLARE @jobId BINARY(16)EXEC @ReturnCode =msdb.djo.b_add_ job_name=N'InsertRecords', @enabled=1 ,@notify_level_eventlog=0,@notify_level_email=0,@notify_level_netsend=0,@notify_level_page=0,@delete_level=0,@description=N'Ingen beskrivelse tilgængelig.',@category_name=N'[Uncategorized (Local)]', @owner_login_name=N'kairos\kigiri', @job_id =@jobId OUTPUTIF (@@ERROR <> 0 ELLER @ReturnCode <> 0) GOTO QuitWithRollback/****** Objekt:Trin [InsertRecords] Scriptdato:7/ 2/2018 3:32:00 PM ******/EXEC @ReturnCode =msdb.dbo.sp_add_jobstep @[email protected],@step_name=N'InsertRecords',@step_id=1,@cmdexec_success_code=0, @on_success_action=1,@on_success_step_id=0,@on_fail_action=2,@on_fail_step_id=0,@retry_attempts=0,@retry_interval=0,@os_run_priority=0, @subsystem=N'TSQL',@command=Ngoinsert intolog_ship_trackervalues(db_name(),getdate(),@@servername)use CorporateDBgoinsert intolog_ship_trackervalues(db_name(),getdate(),@@servername)GO',@database_name=N'master',@flags=0IF (@@ERROR <> 0 ELLER @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_update_job @job_id =@jobId, @start_step_id =1 HVIS (@@ERROR <> 0 ELLER @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_add_jobschedule @[email protected], @name=N'Schedule=1, @enable freq_type=4,@freq_interval=1,@freq_subday_type=4,@freq_subday_interval=1,@freq_relative_interval=0,@freq_recurrence_factor=0,@active_start_date=20180702,@active_end_date=9990_123_time=99909123_time=99909123_time=99909123_time schedule_uid=N'03e5f1b2-2e0b-4b30-8d60-3643c84aa08d' IF (@@ERROR <> 0 ELLER @ReturnCode <> 0) GÅ TIL AfslutWithRollbackEXEC @ReturnCode =@jod_server =@joad_server,Idb =msdb_job_idb =@joad_server,Idbo. (local)'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollbackCOMMIT TRANSACTIONGOTO EndSaveQuitWithRollback:IF (@@TRANCOUNT> 0) ROLLBACK TRANSACTIONEndSave:GO
 

 
 

 Når vi forespørger i tabellen på henholdsvis de primære databaser, kan vi bekræfte (ved at bruge kolonnen RecordTime), at rækkerne matcher i BranchDB og CorporateDB. Når vi undersøger tabellen i de sekundære databaser på samme måde, ser vi tydeligt, at vi har et 30-minutters mellemrum mellem BranchDB og CorporateDB.
 
 
Liste 4 – Forespørgsel i logsporingstabellen
 
vælg top 10 @@servernavn [Current_Server],* fra BranchDB.dbo.log_ship_tracker ordre efter RecordTime descselect top 10 @@servernavn [Current_Server], * fra CorporateDB.dbo.log_ship_tracker ordre efter RecordTime desc
 

 
 

 
 
Fig. 9 Log Tracker-tabeller matcher i primære databaser
 

 
 

 
 
Fig. 10 Log Tracker-tabeller har et hul på ~30 minutter i sekundære databaser
 

 
 
Gendannelse fra brugerfejl
 

 Lad os nu tale om den vigtigste fordel ved denne forsinkelse. I scenariet, hvor en bruger utilsigtet taber en tabel, kan vi gendanne dataene hurtigt fra den sekundære database, så længe forsinkelsesperioden ikke er udløbet. I dette eksempel dropper vi tabellen Sales.Orderlines på BEGGE databaser og verificerer, at tabellen ikke længere eksisterer i BEGGE databaser.
 
 
Liste 5 – Tab af ordrelinjer
 
drop-tabel BranchDB.Sales.Orderlinesdrop-tabel CorporateDB.Sales.OrderlinesGOuse BranchDBgoselect@@servernavn [Current_Server], db_name() [Database_Name], navn, skema_navn(skema_id) [skema], type_desc, create_date, modify_dates from where sys.tablesfrom name='Orderlines'GOuse CorporateDBgoselect@@servername [Current_Server], db_name() [Database_Name], name, schema_name(schema_id) [schema], type_desc, create_date, modify_datefrom sys.tables where name='Orderlines'GO
 

 
 

 
 
Fig. 11 Droptable Sales.Orderlines
 

 
 

 Når vi leder efter tabellen på den sekundære server, finder vi ud af, at tabellen stadig er tilgængelig i BEGGE databaser. For CorporateDB har vi således mindre end fem minutter til at gendanne dataene. (Fig. 12). Men når den næste gendannelsescyklus udføres, mister vi tabellen i Corporate DB-databasen. For at gendanne denne tabel skal vi udføre punkt-i-tidsgendannelse ved hjælp af en fuld sikkerhedskopi i et separat miljø og derefter udpakke denne specifikke tabel. Du er enig i, at det vil tage noget tid. Til BranchDB Orderlines-tabellen har vi lidt mere tid, og vi kan gendanne tabellen med en enkelt SQL-sætning over en linket server (se liste 6).
 
 
 
Fig. 12 Fem minutters nedtælling:Tabel findes i begge sekundære databaser
 

 
 

 
 
Fig. 13 Yderligere 25 minutter til at genoprette BranchDB-tabellen
 

 
 
Liste 6 – Gendan ordrelinjerstabel
 
BRUG [master]GO/****** Objekt:LinkedServer [10.2.1.84] Scriptdato:7/2/2018 4:14:59 PM ******/EXEC master.dbo.sp_addlinkedserver @server =N'10.2.1.84', @srvproduct=N'SQL Server'/* Af sikkerhedsmæssige årsager ændres adgangskoden til den linkede server til fjernlogin med ######## */EXEC master.dbo.sp_addlinkedsrvlogin@rmtsrvname =N'10.2.1.84',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpasswo rd=NULLGOselect * i BranchDB.Sales.Orderlines fra [10.2.1.84].BranchDB.Sales.Orderlines 
 

 
 

 
 
Fig. 14 Gendan BranchDB Sales.Orderlines-tabellen
 

 Derefter bekræfter vi den primære server (BranchDB-database), at tabellen er gendannet.
 

 
 
Fig. 15 Gendan BranchDB Sales.Orderlines-tabellen
 
Konklusion
 

 SQL Server giver en række måder at gendanne efter datatab fra en række rodårsager – diskfejl, korruption, brugerfejl osv. Point-in-time gendannelse fra sikkerhedskopier er nok den mest kendte af disse metoder. I visse simple tilfælde af brugerfejl eller lignende tilfælde, hvor et eller to objekter går tabt, er brugen af ​​Transaction Log Shipping med forsinket gendannelse en god tilgang at overveje. Det skal dog bemærkes, at en sekundær database, som er konfigureret strengt til DR-behov, skal vælges til lavere RPO'er.