Problemer med SQL Server Transactional Replikation

Vi begyndte at tale om SQL Server Transactional Replication-problemer tidligere. Nu vil vi fortsætte med et par flere praktiske demoer for at forstå hyppigt forekommende problemer med replikeringsydelse, og hvordan man fejlfinder dem korrekt.

Vi har allerede diskuteret problemer som konfigurationsproblemer, tilladelsesproblemer, forbindelsesproblemer og dataintegritetsproblemer sammen med fejlfinding og løsning af dem. Nu vil vi fokusere på forskellige præstationsproblemer og korruptionsproblemer, der påvirker SQL Server-replikering.

Da korruptionsspørgsmål er et enormt emne, vil vi kun diskutere, hvordan deres virkninger i denne artikel og vil ikke gå i detaljer. Jeg har valgt flere scenarier, der kan falde ind under problemer med ydeevne og korruption baseret på min erfaring:

Ydeevneproblemer
- Langevarende aktive transaktioner i udgiverdatabase
- Masse INSERT/UPDATE/DELETE operationer på artikler
- Enorme dataændringer inden for en enkelt transaktion
- Blokeringer i distributionsdatabasen
Korruptionsrelaterede problemer
- Korruption af udgiverdatabase
- Korruption af distributionsdatabase
- Korruption af abonnentdatabase
- MSDB-databasekorruption

Ydeevneproblemer

SQL Server Transactional Replication er en kompliceret arkitektur, der involverer adskillige parametre som Publisher-databasen, Distributor-(distributions-)databasen, Subscriber-databasen og adskillige replikeringsagenter, der udføres som SQL Server Agent-job.

Da vi har diskuteret alle disse elementer i detaljer på tværs af vores tidligere artikler, kender vi vigtigheden af hver enkelt for replikeringsfunktionaliteten. Alt, der påvirker disse komponenter, kan påvirke SQL Server-replikeringsydelsen.

For eksempel rummer Publisher-databaseinstansen en kritisk database med mange transaktioner pr. sekund. Serverressourcerne har dog en flaskehals som det konsekvente CPU-forbrug over 90 % eller hukommelsesforbrug over 90 %. Det vil helt sikkert have en indvirkning på Log Reader Agent Job-ydelsen, som læser ændringsdataene fra Transactional logs i Publisher-databasen.

På samme måde kan sådanne scenarier på tværs af distributør- eller abonnentdatabaseinstanser påvirke Snapshot Agent eller Distribution Agent. Så som en DBA skal du sikre dig, at serverressourcerne som CPU, fysisk hukommelse og netværksbåndbredde er effektivt konfigureret til udgiver-, distributør- og abonnentdatabaseforekomsterne.

Hvis vi antager, at udgiver-, abonnent- og distributørdatabaseserverne er konfigureret korrekt, kan vi stadig have problemer med replikeringsydelsen, når vi støder på nedenstående scenarier.

Langevarende aktive transaktioner i udgiverdatabase

Som navnet indikerer, viser langvarige aktive transaktioner, at der er et applikationskald eller en brugerhandling inden for transaktionsomfanget, der udføres i lang tid.

At finde en langvarig aktiv transaktion betyder, at transaktionen endnu ikke er forpligtet og enten kan rulles tilbage eller forpligtes af applikationen. Dette forhindrer transaktionsloggen i at blive afkortet, hvilket resulterer i, at størrelsen på transaktionslogfilen øges konstant.

Log Reader Agent scanner for alle Committed records, der er markeret til replikering fra Transactional Logs i en serialiseret rækkefølge baseret på Log Sequence Number (LSN), og springer alle andre ændringer over for artikler, der ikke er replikeret. Hvis de langvarige aktive transaktionskommandoer endnu ikke er forpligtet, vil Replikering springe over at sende disse kommandoer og sende alle andre forpligtede transaktioner til distributionsdatabasen. Når den langvarige aktive transaktion er begået, vil poster blive sendt til distributionsdatabasen, og indtil det tidspunkt vil den inaktive del af Transaktionslogfilen i Publisher DB ikke blive ryddet, hvilket medfører, at Transaktionslogfilen for Publisher-databasen øges.

Vi kan teste scenariet med langvarig aktiv transaktion ved at udføre nedenstående trin:

Som standard rydder Distribution Agent op i alle forpligtede ændringer i abonnentdatabasen og beholder den sidste post for at overvåge de nye ændringer baseret på Log Sequence Number (LSN).

Vi kan udføre nedenstående forespørgsler for at kontrollere status for de tilgængelige poster i MSRepl_Commands tabeller eller ved at bruge sp_browsereplcmds procedure i distributionsdatabasen:

exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands

Åbn nu et nyt forespørgselsvindue og udfør nedenstående script for at oprette en langvarig aktiv transaktion på AdventureWorks database. Bemærk, at nedenstående script ikke indeholder nogen ROLLBACK- eller COMMIT TRANSACTION-kommandoer. Derfor anbefaler vi ikke at køre denne slags kommandoer på produktionsdatabasen.

BEGIN TRANSACTION 

SET IDENTITY_INSERT Person.ContactType ON;
insert into person.ContactType (ContactTypeId, Name, ModifiedDate) values ( 22, 'Test New Position', GETDATE());
SET IDENTITY_INSERT Person.ContactType OFF;

Vi kan bekræfte, at denne nye registrering ikke er blevet replikeret til abonnentdatabasen. Til det udfører vi SELECT-sætningen på Person.ContactType tabel i abonnentdatabasen:

Lad os kontrollere, om ovenstående INSERT-kommando blev læst af Log Reader Agent og skrevet ind i distributionsdatabasen.

Udfør scripts fra delen af trin 1 igen. Resultaterne viser stadig den samme gamle status, hvilket bekræfter, at posten ikke blev læst fra udgiverdatabasens transaktionslogfiler.

Åbn nu en Ny forespørgsel vinduet og udfør nedenstående UPDATE-script for at se, om Log Reader Agent var i stand til at springe den langvarige aktive transaktion over og læse ændringerne udført af denne UPDATE-sætning.

UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

Tjek distributionsdatabasen, om Log Reader Agent kunne fange denne ændring. Kør scriptet som en del af trin 1:

Da ovenstående UPDATE-sætning blev begået i Publisher-databasen, kunne Log Reader Agent scanne denne ændring og indsætte den i distributionsdatabasen. Efterfølgende anvendte den denne ændring på abonnentdatabasen som vist nedenfor:

INSERT på Person.ContactType vil først blive replikeret til abonnentdatabasen, efter at INSERT-transaktionen er begået i Publisher-databasen. Før vi forpligter os, kan vi hurtigt kontrollere, hvordan man identificerer en langvarig aktiv transaktion, forstår den og håndterer den effektivt.

Identificer en langvarig aktiv transaktion

Åbn et nyt Forespørgselsvindue for at kontrollere, om der er langvarige aktive transaktioner i en database. og opret forbindelse til den respektive database, som vi skal tjekke. Udfør DBCC OPENTRAN console-kommando – det er en Database Console-kommando til at se de transaktioner, der er åbne i databasen på tidspunktet for udførelse.

USE AdventureWorks
GO
DBCC OPENTRAN

Nu ved vi, at der var en SPID (serverproces-id ) 69 kører i lang tid. Lad os kontrollere, hvilken kommando der blev udført på den pågældende transaktion ved hjælp af DBCC INPUTBUFFER console-kommando (en databasekonsolkommando, der bruges til at identificere den kommando eller handling, der finder sted på det valgte serverproces-id).

Af hensyn til læsbarheden kopierer jeg EventInfo feltværdi og formatering for at vise den kommando, vi har udført tidligere.

Hvis der ikke er nogen langvarige aktive transaktioner på den valgte database, får vi nedenstående meddelelse:

Svarende til DBCC OPENTRAN konsolkommando, kan vi VÆLG fra DMV navngivet sys.dm_tran_database_transactions for at få mere detaljerede resultater (se MSDN-artiklen for flere data).

Nu ved vi, hvordan vi identificerer den langvarige transaktion. Vi kan forpligte transaktionen og se, hvordan INSERT-sætningen bliver replikeret.

Gå til vinduet, hvor vi har indsat posten i Person.ContactType tabel inden for Transaktionsomfanget, og udfør COMMIT TRANSACTION som vist nedenfor:

Udførelse af COMMIT TRANSACTION begåede posten i Publisher-databasen. Derfor bør den være synlig i distributionsdatabasen og abonnentdatabasen:

Hvis du har bemærket, blev de ældre poster fra distributionsdatabasen ryddet op af distributionsagentoprydningsjobbet. Den nye rekord for INSERT på Person.ContactType tabellen var synlig i MSRepl_cmds tabel.

Fra vores test har vi lært følgende ting:

Loglæseragentjobbet i SQL Server Transactional Replication scanner kun for Committed records fra Transactional Logs of Publisher-databasen og INSERT i Subscriber-databasen.
Rækkefølgen af ændrede data på Publisher-databasen, der sendes til Abonnenten, vil være baseret på Committed-status og tidspunkt i Publisher-databasen, selvom de replikerede data vil have samme tid som Publisher-databasen.
Identifikation af langvarige aktive transaktioner kan hjælpe med at løse transaktionslogfilvækst for udgiver eller distributør eller abonnent eller enhver database.

Masse SQL INSERT/OPDATERING/DELETE-handlinger på artikler

Med enorme data, der findes i Publisher-databasen, ender vi ofte med krav om at INDSÆTTE eller OPDATERE eller SLETTE enorme poster til replikerede tabeller.

Hvis INSERT-, UPDATE- eller DELETE-operationerne udføres i en enkelt transaktion, vil den helt sikkert ende i replikeringen, der sidder fast i lang tid.

Lad os sige, at vi skal INDSÆTTE 10 millioner poster i en replikeret tabel. Indsættelse af disse poster i et enkelt skud vil forårsage præstationsproblemer.

INSERT INTO REplicated_table
SELECT * FROM Source_table

I stedet kan vi INDSÆTTE poster i batcher på 0,1 eller 0,5 millioner poster på MENS løkke eller CURSOR loop , og det vil sikre hurtigere replikering. Vi modtager muligvis ikke større problemer for INSERT-sætninger, medmindre ellers den involverede tabel har mange indekser. Dette vil dog have et kæmpe præstationshit for UPDATE- eller DELETE-udsagn.

Antag, at vi har tilføjet en ny kolonne til den replikerede tabel, der har omkring 10 millioner poster. Vi ønsker at opdatere denne nye kolonne med en standardværdi.

Ideelt set fungerer nedenstående kommando fint til at OPDATERE alle 10 millioner poster med standardværdien Abc :

-- UPDATE 10 Million records on Replicated Table with some DEFAULT values
UPDATE Replicated_table
SET new_column = 'Abc'

For at undgå indvirkning på replikering bør vi dog udføre ovenstående OPDATERING i batches på 0,1 eller 0,5 millioner poster for at undgå ydeevneproblemer.

-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
	UPDATE TOP(100000) Replicated_Table
	SET new_Column = 'Abc'
	WHERE new_column is NULL

	IF @@ROWCOUNT = 0
	BREAK
END

På samme måde, hvis vi har brug for at SLETTE omkring 10 millioner poster fra en replikeret tabel, kan vi gøre det i batches:

-- DELETE 10 Million records on Replicated Table with some DEFAULT values
DELETE FROM Replicated_table

-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
	DELETE TOP(100000) Replicated_Table

	IF @@ROWCOUNT = 0
	BREAK
END

Effektiv håndtering af BULK INSERT, UPDATE eller DELETE kan hjælpe med at løse replikeringsproblemerne.

Prof Tip :For at INDSÆTTE enorme data i en replikeret tabel i Publisher-databasen skal du bruge IMPORT/EXPORT-guiden i SSMS, da den vil indsætte poster i batches på 10.000 eller baseret på poststørrelsen hurtigere beregnet af SQL Server.

Enorme dataændringer inden for en enkelt transaktion

For at bevare dataintegriteten fra applikations- eller udviklingsperspektivet har mange applikationer eksplicitte transaktioner defineret for kritiske operationer. Men hvis mange operationer (INSERT, UPDATE eller DELETE) udføres inden for et enkelt transaktionsområde, vil Log Reader Agent først vente på, at transaktionen er fuldført, som vi har set tidligere.

Når transaktionen er begået af applikationen, skal Log Reader Agent scanne de enorme dataændringer, der udføres på Publisher-databasens transaktionslogfiler. Under denne scanning kan vi se advarslerne eller informationsmeddelelserne i Log Reader Agent som

Loglæseragenten scanner transaktionsloggen for kommandoer, der skal replikeres. Cirka xxxxxx logposter er blevet scannet i pass # xxxx, hvoraf blev markeret til replikering, forløbet tid xxxxxxxxx (ms)

Før vi identificerer løsningen til dette scenarie, skal vi forstå, hvordan loglæseragenten scanner poster fra transaktionsloggene og indsætter poster i distributionsdatabasen MSrepl_transactions og MSrepl_cmds tabeller.

SQL Server har internt et Log Sequence Number (LSN) inde i Transactional Logs. Log Reader Agent gør brug af LSN-værdierne til at scanne ændringer, der er markeret for SQL Server-replikering i rækkefølge.

Log Reader Agent udfører sp_replcmds udvidet lagret procedure til at hente kommandoerne markeret til replikering fra udgiverdatabasens transaktionslogs.

Sp_replcmds accepterer en inputparameter ved navn @maxtrans for at hente det maksimale antal transaktioner. Standardværdien vil være 1, hvilket betyder, at den vil scanne uanset antallet af tilgængelige transaktioner fra logfiler, der skal sendes til distributionsdatabasen. Hvis der er 10 INSERT-operationer udført via en enkelt transaktion og begået i Publisher-databasen, kan en enkelt batch indeholde 1 transaktion med 10 kommandoer.

Hvis der identificeres mange transaktioner med mindre kommandoer, vil Log Reader Agent kombinere flere transaktioner eller XACT sekvensnummer til en enkelt replikeringsbatch. Men det gemmer som en anden XACT Sekvens nummer i MSRepl_transactions bord. Individuelle kommandoer, der hører til den pågældende transaktion, vil blive fanget i MSRepl_commands tabel.

For at bekræfte de ting, vi har diskuteret ovenfor, opdaterer jeg ModifiedDate kolonne i dbo.AWBuildVersion tabel til dagens dato og se, hvad der sker:

UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

Før vi udfører OPDATERING, verificerer vi registreringerne i MSrepl_commands og MSrepl_transactions tabeller:

Udfør nu ovenstående UPDATE-script og bekræft registreringerne i disse 2 tabeller:

En ny rekord med UPDATE-tiden blev indsat i MSrepl_transactions tabel med det nærliggende indgangstidspunkt . Kontrollerer kommandoen på denne xact_seqno vil vise listen over logisk grupperede kommandoer ved hjælp af sp_browsereplcmds procedure.

I replikeringsmonitoren kan vi se en enkelt UPDATE-sætning fanget under 1 transaktion(er) med 1 kommando(er) fra udgiveren til distributøren.

Og vi kan se den samme kommando blive leveret fra distributøren til abonnenten på en brøkdel af et sekunds forskel. Det indikerer, at replikeringen sker korrekt.

Hvis der nu er et stort antal transaktioner kombineret i en enkelt xact_seqno , kan vi se beskeder som 10 transaktion(er) med 5000 kommando(er) blev leveret .

Lad os tjekke dette ved at udføre UPDATE på 2 forskellige tabeller på samme tid:

Vi kan se to transaktionsposter i MSrepl_transactions tabel, der matcher de to UPDATE-operationer og derefter nr. af poster i den tabel, der matcher nr. af optegnelser opdateret.

Resultatet fra MSrepl_transactions tabel:

Resultatet fra MSrepl_commands tabel:

Vi har dog bemærket, at disse 2 transaktioner er logisk grupperet af Log Reader Agent og kombineret i en enkelt batch som 2 transaktioner med 109225 kommandoer.

Men før det kan vi måske se meddelelser som Levering af replikerede transaktioner, xact count:1, command count 46601 .

Dette vil ske, indtil Log Reader-agenten scanner det komplette sæt ændringer og identificerer, at 2 OPDATERING-transaktioner blev læst fuldt ud fra transaktionsloggene.

Når kommandoerne er fuldt læst fra transaktionsloggene, ser vi, at 2 transaktioner med 109225 kommandoer blev leveret af Log Reader-agenten:

Da distributionsagenten venter på, at en stor transaktion bliver replikeret, ser vi muligvis en meddelelse som Leverer replikerede transaktioner hvilket indikerer, at der var en enorm transaktion, der blev replikeret, og vi er nødt til at vente på, at den bliver replikeret fuldstændigt.

Når den er replikeret, kan vi også se nedenstående meddelelse i distributionsagenten:

Flere måder er nyttige til at løse disse problemer.

Måde 1:OPRET ny SQL Stored Procedure

Du skal oprette en ny lagret procedure og indkapsle applikationslogikken i den inden for rammerne af Transaktion.

Når den er oprettet, skal du tilføje den Stored Procedure-artikel til Replikering og ændre artikelegenskaben Replicate til Udførelse af den Stored Procedure mulighed.

Det vil hjælpe med at udføre Stored Procedure-artiklen på abonnenten i stedet for at replikere alle individuelle dataændringer, der foregik.

Lad os gennemgå, hvordan udførelsen af den lagrede procedure mulighed for Repliker reducerer belastningen på replikering. For at gøre det kan vi oprette en test Lagret Procedure som vist nedenfor:

CREATE procedure test_proc
AS
BEGIN
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

UPDATE TOP(10) Production.TransactionHistoryArchive
SET ModifiedDate  = GETDATE()

UPDATE TOP(10) Person.Person
SET ModifiedDate  = GETDATE()
END

Ovenstående procedure vil OPDATERE en enkelt post på AWBuildVersion tabel og 10 poster hver på Production.TransactionHistoryArchive og Person.Person tabeller med i alt op til 21 registreringsændringer.

Når du har oprettet denne nye procedure på tværs af både udgiveren og abonnenten, skal du tilføje den til replikering. For det skal du højreklikke på Publikation og vælg procedureartiklen til replikering med standard kun lagret proceduredefinition mulighed.

Når det er gjort, kan vi bekræfte de tilgængelige poster i MSrepl_transactions og MSrepl_commands tabeller.

Lad os nu udføre proceduren i Publisher-databasen for at se, hvor mange poster der er sporet.

Vi kan se følgende på distributionstabellerne MSrepl_transactions og MSrepl_commands :

Tre xact_seqno blev oprettet til tre OPDATERINGS-operationer i MSrepl_transactions tabel, og 21 kommandoer blev indsat i MSrepl_commands tabel.

Åbn Replikeringsmonitor og se, om de sendes som 3 forskellige replikeringsbatches eller en enkelt batch med 3 transaktioner sammen.

Vi kan se, at tre xact_seqno blev konsolideret som et enkelt replikeringsbatch. Derfor kan vi se, at 3 transaktioner med 21 kommandoer blev leveret med succes.

Lad os fjerne proceduren fra replikering og tilføje den igen med den anden udførelse af den lagrede procedure mulighed. Udfør nu proceduren og se, hvordan posterne bliver replikeret.

Kontrol af poster fra distributionstabeller viser nedenstående detaljer:

Udfør nu proceduren på Publisher-databasen og se, hvor mange poster der bliver logget i distributionstabeller. Udførelse af en procedure opdaterede 21 poster (1 post, 10 poster og 10 poster) som tidligere.

Bekræftelse af distributionstabeller viser nedenstående data:

Lad os tage et hurtigt kig på sp_browsereplcmds for at se den faktiske modtagne kommando:

Kommandoen er “{ring “dbo”.”test_proc” }” som vil blive udført på abonnentdatabasen.

I replikeringsmonitoren kan vi se, at kun 1 transaktion(er) med 1 kommando(er) blev leveret via replikering:

I vores testcase har vi brugt en procedure med kun 21 dataændringer. Men hvis vi gør det for en kompliceret procedure, der involverer millioner af ændringer, så er Stored Procedure-tilgangen med Udførelse af den Stored Procedure mulighed vil være effektiv til at reducere replikeringsbelastningen.

Vi er nødt til at validere denne tilgang ved at kontrollere, om proceduren har logikken til kun at opdatere det samme sæt poster i Publisher- og Subscriber-databaserne. Ellers vil dette skabe problemer med datainkonsistens på tværs af udgiveren og abonnenten.

Måde 2:Konfiguration af MaxCmdsInTran, ReadBatchSize og ReadBatchThreshold Log Reader Agent parametre

MaxCmdsInTran – angiver det maksimale antal kommandoer, der logisk kan grupperes i en transaktion, mens data læses fra udgiverens transaktionslogs og skrives til distributionsdatabasen.

I vores tidligere test har vi bemærket, at omkring 109225 kommandoer blev akkumuleret i en enkelt replikeringssekvens, hvilket resulterede i en lille langsomhed eller latens. Hvis vi indstiller MaxCmdsInTran parameter til 10000, den enkelte nøjagtige sekvens nummeret opdeles i 11 xact-sekvenser, der resulterer i hurtigere levering af kommandoer fra udgiver til distributør . Selvom denne mulighed hjælper med at reducere striden i distributionsdatabasen og replikere dataene hurtigere fra udgiveren til abonnentdatabasen, skal du være forsigtig, mens du bruger denne mulighed. Det kan ende med at levere dataene til abonnentdatabasen og få adgang til dem fra abonnentdatabasetabellerne inden udløbet af det oprindelige transaktionsomfang.

ReadBatchSize – Denne parameter er muligvis ikke nyttig for et enkelt stort transaktionsscenarie. Det hjælper dog, når der er mange og masser af mindre transaktioner, der sker i Publisher-databasen.

Hvis antallet af kommandoer pr. transaktion er færre, vil Log Reader Agent kombinere flere ændringer til et enkelt replikeringskommando transaktionsomfang. Læs batchstørrelsen angiver, hvor mange transaktioner der kan læses i transaktionsloggen, før ændringer sendes til distributionsdatabasen. Værdierne kan være mellem 500 og 10.000.

ReadBatchThreshold – angiver antallet af kommandoer, der skal læses fra transaktionsloggen i Publisher-databasen, før de sendes til abonnenten med en standardværdi på 0 for at scanne hele logfilen. Vi kan dog reducere denne værdi for at sende data hurtigere ved at begrænse den til 10000 eller 100000 kommandoer på den måde.

Måde 3:Konfiguration af de bedste værdier for SubscriptionStreams-parameteren

Abonnementsstrømme – angiver antallet af forbindelser, som en distributionsagent kan udføre parallelt for at hente data fra distributionsdatabasen og udbrede dem til abonnentdatabasen. Standardværdien er 1, hvilket kun antyder én strøm eller forbindelse fra distributionen til abonnentdatabasen. Værdier kan være mellem 1 og 64. Hvis der tilføjes flere abonnementsstrømme, kan det ende med CXPACKET-overbelastning (med andre ord parallelisme). Derfor bør du være forsigtig, mens du konfigurerer denne mulighed i produktion.

For at opsummere, prøv at undgå enorme INSERT, UPDATE eller DELETE i en enkelt transaktion. Hvis det er umuligt at eliminere disse operationer, ville den bedste mulighed være at teste ovenstående måder og vælge den, der passer bedst til dine specifikke forhold.

Blokeringer i distributionsdatabasen

Distributionsdatabasen er hjertet i SQL Server Transactional Replication, og hvis den ikke vedligeholdes ordentligt, vil der være masser af ydeevneproblemer.

For at opsummere alle anbefalede fremgangsmåder for distributionsdatabasekonfigurationen skal vi sikre, at nedenstående konfigurationer udføres korrekt:

Datafiler i distributionsdatabaserne skal placeres på høje IOPS-drev. Hvis Publisher-databasen vil have mange dataændringer, skal vi sikre, at distributionsdatabasen placeres på et drev med høj IOPS. Den vil løbende modtage data fra Log Reader-agenten og sende data til abonnentdatabasen via distributionsagenten. Alle replikerede data bliver slettet fra distributionsdatabasen hvert 10. minut via distributionsoprydningsjobbet.
Konfigurer egenskaberne for den oprindelige filstørrelse og autovækst for distributionsdatabasen med de anbefalede værdier baseret på aktivitetsniveauerne for Publisher-databasen. Ellers vil det føre til fragmentering af data og logfiler, der forårsager ydeevneproblemer.
Inkluder distributionsdatabaser i de almindelige indeksvedligeholdelsesjob, der er konfigureret på de servere, hvor distributionsdatabasen er placeret.
Inkluder distributionsdatabaser i tidsplanen for fuld backupjob for at fejlfinde eventuelle specifikke problemer.
Sørg for, at Distributionsoprydning:distributionen jobbet kører hvert 10. minut i henhold til standardplanen. Ellers bliver distributionsdatabasens størrelse ved med at stige og fører til ydeevneproblemer.

Som vi hidtil har bemærket, er de involverede nøgletabeller i distributionsdatabasen MSrepl_transactions og MSrepl_commands . Posterne indsættes der af Log Reader Agent-jobbet, valgt af Distributionsagent-jobbet, anvendt i abonnentdatabasen og derefter slettet eller ryddet op af Distribution Clean-up-agentjobbet.

Hvis distributionsdatabasen ikke er konfigureret korrekt, kan vi støde på sessionsblokeringer på tværs af disse 2 tabeller, hvilket vil resultere i problemer med SQL Server-replikering.

Vi kan udføre nedenstående forespørgsel på tværs af enhver database for at se de tilgængelige blokeringssessioner i den aktuelle forekomst af SQL Server:

SELECT * 
FROM sys.sysprocesses
where blocked > 0
order by waittime desc

Hvis ovenstående forespørgsel returnerer resultater, kan vi identificere kommandoer på de blokerede sessioner ved at udføre DBCC INPUTBUFFER(spid) konsolkommando og foretag handlinger i overensstemmelse hermed.

Korruptionsrelaterede problemer

En SQL Server-database bruger sin algoritme eller logik til at gemme data i tabeller og holde dem i omfang eller sider. Databasekorruption er en proces, hvorved den fysiske tilstand af de databaserelaterede filer/udvidelser/sider ændres fra normal til ustabil eller ikke-hentningstilstand, hvilket gør datahentning sværere eller umulig.

Alle SQL Server-databaser er tilbøjelige til databasekorruption. Årsagerne kan være:

Hardwarefejl som disk-, lager- eller controllerproblemer;
Server OS-fejl som patchproblemer;
Strømsvigt, der resulterer i en brat lukning af servere eller forkert lukning af databasen.

Hvis vi kan gendanne eller reparere databaser uden tab af data, vil SQL Server-replikeringen ikke blive påvirket. Men hvis der er datatab under gendannelse eller reparation af korrupte databaser, vil vi begynde at modtage en masse dataintegritetsproblemer, som vi har diskuteret i vores tidligere artikel.

Korruption kan ske ved forskellige komponenter, såsom:

Udgiverdata/logfilkorruption
Abonnentdata/logfilkorruption
Distributionsdatabasedata/logfilkorruption
Msdb-databasedata/logfilkorruption

If we receive a lot of data integrity issues after fixing up Corruption issues, it is recommended to remove the Replication completely, fix all Corruption issues in the Publisher, Subscriber, or Distributor database and then reconfigure Replication to fix it. Otherwise, data integrity issues will persist and lead to data inconsistency across the Publisher and Subscriber. The time required to fix the Data integrity issues in case of Corrupted databases will be much more compared to configuring Replication from scratch. Hence identify the level of Corruption encountered and take optimal decisions to resolve the Replication issues faster.

Wondering why msdb database corruption can harm Replication? Since msdb database hold all details related to SQL Server Agent Jobs including Replication Agent jobs, any corruption on msdb database will harm Replication. To recover quickly from msdb database corruptions, it is recommended to restore msdb database from the last Full Backup of msdb database. This also signifies the importance of taking Full Backups of all system databases including msdb database.

Konklusion

Thanks for successfully going through the final power-packed article about the Performance issues in the SQL Server Transactional Replication. If you have gone through all articles carefully, you should be able to troubleshoot almost any Transactional Replication-based issues and fix them out efficiently.

If you need any further guidance or have any Transactional Replication-related issues in your environment, you can reach out to me for consultation. And if I missed anything essential in this article, you are welcome to point to that in the Comments section.