SQL Server transaktionsreplikeringsproblem

Vi började prata om SQL Server Transactional Replication-problem tidigare. Nu kommer vi att fortsätta med några fler praktiska demos för att förstå vanliga replikeringsprestandaproblem och hur man felsöker dem på rätt sätt.

Vi har redan diskuterat sådana problem som konfigurationsproblem, behörighetsproblem, anslutningsproblem och dataintegritetsproblem tillsammans med felsökning och åtgärdande av dem. Nu kommer vi att fokusera på olika prestandaproblem och korruptionsproblem som påverkar SQL Server-replikering.

Eftersom korruptionsfrågor är ett stort ämne, kommer vi bara att diskutera hur de påverkar i den här artikeln och kommer inte att gå in i detalj. Jag har valt flera scenarier som kan falla under Prestanda- och korruptionsproblem baserat på min erfarenhet:

Prestandaproblem
- Långa aktiva transaktioner i utgivarens databas
- MassINFOGA/UPPDATERA/RADERA operationer på artiklar
- Enorma dataförändringar inom en enda transaktion
- Blockeringar i distributionsdatabasen
Korruptionsrelaterade frågor
- Korruption av utgivarens databas
- Korruption av distributionsdatabasen
- Korruption av prenumerantdatabas
- MSDB-databaskorruption

Prestandaproblem

SQL Server Transactional Replication är en komplicerad arkitektur som involverar flera parametrar som Publisher-databasen, Distributor-databasen (distributörsdatabasen), Subscriber-databasen och flera replikeringsagenter som körs som SQL Server Agent-jobb.

Eftersom vi har diskuterat alla dessa artiklar i detalj i våra tidigare artiklar, vet vi vikten av var och en för replikeringsfunktionen. Allt som påverkar dessa komponenter kan påverka SQL Server-replikeringsprestanda.

Till exempel innehåller Publisher-databasinstansen en kritisk databas med många transaktioner per sekund. Serverresurserna har dock en flaskhals som den konsekventa CPU-användningen över 90 % eller minnesanvändningen över 90 %. Det kommer definitivt att ha en inverkan på Log Reader Agent Jobs prestanda som läser ändringsdata från Transaktionsloggar i Publisher-databasen.

På liknande sätt kan alla sådana scenarier i distributörs- eller abonnentdatabasinstanser påverka Snapshot Agent eller Distribution Agent. Så som DBA måste du se till att serverresurserna som CPU, fysiskt minne och nätverksbandbredd är effektivt konfigurerade för databasinstanserna Publisher, Distributor och Subscriber.

Om vi antar att databasservrarna för utgivare, prenumeranter och distributörer är korrekt konfigurerade kan vi fortfarande ha problem med replikeringsprestanda när vi stöter på scenarierna nedan.

Långvariga aktiva transaktioner i utgivardatabasen

Som namnet indikerar visar långvariga aktiva transaktioner att det finns ett applikationsanrop eller en användaroperation inom transaktionsomfånget som körs under lång tid.

Att hitta en långvarig aktiv transaktion innebär att transaktionen ännu inte är genomförd och kan antingen återställas eller genomföras av applikationen. Detta kommer att förhindra att transaktionsloggen trunkeras, vilket resulterar i att storleken på transaktionsloggfilen ökar kontinuerligt.

Log Reader Agent söker efter alla Committed-poster som är markerade för replikering från transaktionsloggar i en seriell ordning baserat på Log Sequence Number (LSN), och hoppar över alla andra ändringar som sker för artiklar som inte replikeras. Om de långvariga aktiva transaktionskommandona ännu inte har konfigurerats, kommer Replikering att hoppa över att skicka dessa kommandon och skicka alla andra committerade transaktioner till distributionsdatabasen. När den långvariga aktiva transaktionen har begåtts kommer poster att skickas till distributionsdatabasen och tills dess kommer den inaktiva delen av Transaktionsloggfilen i Publisher DB inte att rensas vilket gör att storleken på Transaktionsloggfilen för Publishers databas ökar.

Vi kan testa scenariot med långvarig aktiv transaktion genom att utföra stegen nedan:

Som standard rensar Distribution Agent upp alla bekräftade ändringar i abonnentdatabasen och behåller den sista posten för att övervaka de nya ändringarna baserat på Log Sequence Number (LSN).

Vi kan köra frågorna nedan för att kontrollera statusen för de poster som är tillgängliga i MSRepl_Commands tabeller eller använda sp_browsereplcmds procedur i distributionsdatabasen:

exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands

Öppna nu ett nytt frågefönster och kör skriptet nedan för att skapa en långvarig aktiv transaktion på AdventureWorks databas. Observera att skriptet nedan inte innehåller några kommandon för ROLLBACK eller COMMIT TRANSACTION. Därför rekommenderar vi att du inte kör den här typen av kommandon 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 verifiera att denna nya post inte har replikerats till prenumerantdatabasen. För det utför vi SELECT-satsen på Person.ContactType tabell i prenumerantdatabasen:

Låt oss verifiera om ovanstående INSERT-kommando lästes av Log Reader Agent och skrevs in i distributionsdatabasen.

Kör skripten från delen av steg 1 igen. Resultaten visar fortfarande samma gamla status, vilket bekräftar att posten inte lästes från transaktionsloggarna i utgivardatabasen.

Öppna nu en Ny fråga fönstret och kör nedanstående UPDATE-skript för att se om Log Reader Agent kunde hoppa över den långvariga aktiva transaktionen och läsa ändringarna som gjorts av denna UPDATE-sats.

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

Kontrollera distributionsdatabasen om Log Reader Agent kunde fånga denna ändring. Kör skriptet som en del av steg 1:

Eftersom ovanstående UPDATE-sats begicks i Publisher-databasen kunde Log Reader Agent skanna denna ändring och infoga den i distributionsdatabasen. Därefter tillämpade den denna ändring på prenumerantdatabasen enligt nedan:

INSERT på Person.ContactType kommer att replikeras till prenumerantdatabasen först efter att INSERT-transaktionen har genomförts i Publisher-databasen. Innan vi förbinder oss kan vi snabbt kontrollera hur man identifierar en långvarig aktiv transaktion, förstår den och hanterar den effektivt.

Identifiera en långvarig aktiv transaktion

Öppna ett nytt Frågefönster för att kontrollera om det finns några långvariga aktiva transaktioner i en databas. och anslut till respektive databas som vi behöver kontrollera. Kör DBCC OPENTRAN console-kommando – det är ett databaskonsolkommando för att se transaktionerna som är öppna i databasen vid tidpunkten för exekvering.

USE AdventureWorks
GO
DBCC OPENTRAN

Nu vet vi att det fanns en SPID (serverprocess-ID ) 69 igång länge. Låt oss verifiera vilket kommando som kördes på den transaktionen med DBCC INPUTBUFFER console-kommando (ett databaskonsolkommando som används för att identifiera kommandot eller operationen som sker på det valda serverprocess-ID).

För läsbarheten kopierar jag EventInfo fältvärdet och formatera det för att visa kommandot vi har utfört tidigare.

Om det inte finns några långvariga aktiva transaktioner i den valda databasen får vi följande meddelande:

Liknar DBCC OPENTRAN console-kommandot kan vi SELECT från DMV heter sys.dm_tran_database_transactions för att få mer detaljerade resultat (se MSDN-artikeln för mer information).

Nu vet vi hur vi identifierar den långvariga transaktionen. Vi kan utföra transaktionen och se hur INSERT-satsen replikeras.

Gå till fönstret där vi har infogat posten till Person.ContactType tabell inom transaktionsomfånget och verkställ COMMIT TRANSACTION som visas nedan:

Utförandet av COMMIT TRANSACTION överförde posten till Publisher-databasen. Därför bör den vara synlig i distributionsdatabasen och prenumerantdatabasen:

Om du har märkt, rensades de äldre posterna från Distributionsdatabasen upp av Distribution Agent Clean-up-jobbet. Det nya rekordet för INSERT på Person.ContactType tabellen var synlig i MSRepl_cmds bord.

Från våra tester har vi lärt oss följande saker:

Log Reader Agent-jobbet för SQL Server Transactional Replication kommer endast att söka efter Committed-poster från Transactional Logs of Publisher-databasen och INSERT in i Subscriber-databasen.
Ordningen av ändrade data i Publisher-databasen som skickas till Prenumeranten kommer att baseras på Committed-status och tid i Publisher-databasen även om de replikerade data kommer att ha samma tid som Publisher-databasen.
Att identifiera långvariga aktiva transaktioner kan hjälpa till att lösa transaktionsloggfilens tillväxt för utgivare eller distributör eller prenumerant eller andra databaser.

Mass-SQL-INSERT/UPDATE/DELETE-åtgärder för artiklar

Med enorma data som finns i Publisher-databasen slutar vi ofta med krav på att INFOGA eller UPPDATERA eller DELETE enorma poster till replikerade tabeller.

Om operationerna INSERT, eller UPDATE eller DELETE utförs i en enda transaktion, kommer det definitivt att hamna i replikeringen som har fastnat under lång tid.

Låt oss säga att vi måste INFOGA 10 miljoner poster i en replikerad tabell. Att infoga dessa poster i en enda tagning kommer att orsaka prestandaproblem.

INSERT INTO REplicated_table
SELECT * FROM Source_table

Istället kan vi INFOGA poster i partier om 0,1 eller 0,5 miljoner poster under en MED loop eller CURSOR loop , och det kommer att säkerställa snabbare replikering. Vi kanske inte får några större problem för INSERT-satser om inte annars den berörda tabellen har massor av index. Detta kommer dock att ha en enorm prestandaträff för UPDATE- eller DELETE-satserna.

Anta att vi har lagt till en ny kolumn i tabellen Replikerade som har cirka 10 miljoner poster. Vi vill uppdatera den här nya kolumnen med ett standardvärde.

Helst kommer kommandot nedan att fungera bra för att UPPDATERA alla 10 miljoner poster med standardvärdet Abc :

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

Men för att undvika effekter på replikering bör vi utföra ovanstående UPDATE-operation i omgångar på 0,1 eller 0,5 miljoner poster för att undvika prestandaproblem.

-- 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å samma sätt, om vi behöver RADERA omkring 10 miljoner poster från en replikerad tabell, kan vi göra det i omgångar:

-- 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

Att hantera BULK INSERT, eller UPDATE eller DELETE effektivt kan hjälpa till att lösa replikeringsproblemen.

Proffstips :För att INFOGA enorma data i en replikerad tabell i Publisher-databasen, använd IMPORT/EXPORT-guiden i SSMS, eftersom den kommer att infoga poster i batcher om 10 000 eller baserat på poststorleken som snabbare beräknas av SQL Server.

Enorma dataförändringar inom enskild transaktion

För att upprätthålla dataintegriteten ur applikations- eller utvecklingsperspektiv har många applikationer explicita transaktioner definierade för kritiska operationer. Men om många operationer (INSERT, UPDATE eller DELETE) utförs inom ett enda transaktionsomfång, kommer Log Reader Agent först att vänta på att transaktionen ska slutföras, som vi har sett tidigare.

När transaktionen har begåtts av applikationen måste Log Reader Agent skanna de enorma dataändringarna som utförs på Publishers databas transaktionsloggar. Under den genomsökningen kan vi se varningar eller informationsmeddelanden i Log Reader Agent som

Loggläsaragenten skannar transaktionsloggen efter kommandon som ska replikeras. Ungefär xxxxxx loggposter har skannats i pass # xxxx varav markerade för replikering, förfluten tid xxxxxxxxx (ms)

Innan vi identifierar lösningen för detta scenario måste vi förstå hur Log Reader Agent skannar poster från transaktionsloggarna och infogar poster i distributionsdatabasen MSrepl_transactions och MSrepl_cmds tabeller.

SQL Server har internt ett Log Sequence Number (LSN) i transaktionsloggarna. Log Reader Agent använder LSN-värdena för att skanna ändringar som är markerade för SQL Server-replikering i ordning.

Log Reader Agent kör sp_replcmds utökad lagrad procedur för att hämta kommandon som är markerade för replikering från utgivarens transaktionsloggar.

Sp_replcmds accepterar en indataparameter med namnet @maxtrans för att hämta det maximala antalet transaktioner. Standardvärdet skulle vara 1 vilket betyder att det kommer att skanna vilket antal transaktioner som är tillgängliga från loggar som ska skickas till distributionsdatabasen. Om det finns 10 INSERT-operationer som utförs via en enskild transaktion och committeras i Publisher-databasen, kan en enda batch innehålla 1 transaktion med 10 kommandon.

Om många transaktioner med mindre kommandon identifieras, kommer Log Reader Agent att kombinera flera transaktioner eller XACT sekvensnummer till en enda replikeringsbatch. Men det lagras som en annan XACT Sekvens nummer i MSRepl_transactions tabell. Individuella kommandon som hör till den transaktionen kommer att fångas i MSRepl_commands bord.

För att verifiera det vi har diskuterat ovan uppdaterar jag Ändrad datum kolumnen i dbo.AWBuildVersion tabell till dagens datum och se vad som händer:

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

Innan vi kör UPPDATERING verifierar vi posterna som finns i MSrepl_commands och MSrepl_transactions tabeller:

Kör nu ovanstående UPDATE-skript och verifiera posterna som finns i dessa två tabeller:

En ny post med UPDATE-tiden infogades i MSrepl_transactions tabell med den närliggande ingångstid . Kontrollera kommandot på denna xact_seqno kommer att visa listan över logiskt grupperade kommandon med sp_browsereplcmds förfarande.

I replikeringsmonitorn kan vi se en enda UPDATE-sats fångad under 1 transaktion(er) med 1 kommando(n) från utgivaren till distributören.

Och vi kan se samma kommando levereras från distributören till abonnenten på en bråkdel av en sekunds skillnad. Det indikerar att replikeringen sker korrekt.

Nu, om det finns ett stort antal transaktioner kombinerade i en enda xact_seqno , vi kan se meddelanden som 10 transaktion(er) med 5000 kommando(n) levererades .

Låt oss kontrollera detta genom att köra UPDATE på 2 olika tabeller samtidigt:

Vi kan se två transaktionsposter i MSrepl_transactions tabell som matchar de två UPDATE-operationerna och sedan no. av poster i den tabellen som matchar nr. av register uppdaterade.

Resultatet från MSrepl_transactions tabell:

Resultatet från MSrepl_commands tabell:

Vi har dock märkt att dessa 2 transaktioner är logiskt grupperade av Log Reader Agent och kombineras i en enda batch som 2 transaktioner med 109225 kommandon.

Men innan dess kan vi se meddelanden som Leverera replikerade transaktioner, antal exakt:1, antal kommandon 46601 .

Detta kommer att hända tills Log Reader Agent skannar hela uppsättningen av ändringar och identifierar att 2 UPPDATERINGStransaktioner lästes fullständigt från transaktionsloggarna.

När kommandona är fullständigt lästa från transaktionsloggarna ser vi att 2 transaktioner med 109225 kommandon levererades av Log Reader-agenten:

Eftersom distributionsagenten väntar på att en stor transaktion ska replikeras kan vi se ett meddelande som Levererar replikerade transaktioner vilket indikerar att det var en enorm transaktion som replikerades, och vi måste vänta på att den replikeras helt.

När de har replikerats kan vi även se meddelandet nedan i distributionsagenten:

Flera sätt är användbara för att lösa dessa problem.

Sätt 1:SKAPA ny lagrad SQL-procedur

Du måste skapa en ny lagrad procedur och kapsla in applikationslogiken i den inom ramen för Transaktion.

När den har skapats lägger du till den lagrade procedurartikeln till replikering och ändrar artikelegenskapen Replicate till exekvering av den lagrade proceduren alternativ.

Det hjälper till att exekvera artikeln om lagrad procedur på abonnenten istället för att replikera alla individuella dataändringar som ägde rum.

Låt oss granska hur exekveringen av den lagrade proceduren alternativet för Replicate minskar belastningen på replikering. För att göra det kan vi skapa en lagrad testprocedur enligt nedan:

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

Ovanstående procedur kommer att UPPDATERA en enda post på AWBuildVersion tabell och 10 poster vardera i Production.TransactionHistoryArchive och Person.Person tabeller med totalt upp till 21 poständringar.

När du har skapat den här nya proceduren för både utgivaren och prenumeranten, lägg till den i replikering. För det högerklickar du på Publikation och välj procedurartikeln till replikering med standardinställningen endast lagrad procedurdefinition alternativ.

När det är klart kan vi verifiera de poster som är tillgängliga i MSrepl_transactions och MSrepl_commands tabeller.

Låt oss nu köra proceduren i Publisher-databasen för att se hur många poster som spåras ut.

Vi kan se följande i distributionstabellerna MSrepl_transactions och MSrepl_commands :

Tre xact_seqno skapades för tre UPDATE-operationer i MSrepl_transactions tabell och 21 kommandon infogades i MSrepl_commands bord.

Öppna Repplication Monitor och se om de skickas som 3 olika replikeringsbatcher eller en enda batch med 3 transaktioner tillsammans.

Vi kan se att tre xact_seqno konsoliderades som en enda replikeringsbatch. Därför kan vi se att 3 transaktioner med 21 kommandon levererades framgångsrikt.

Låt oss ta bort proceduren från replikering och lägga till den igen med den andra exekveringen av den lagrade proceduren alternativ. Kör nu proceduren och se hur posterna replikeras.

Att kontrollera poster från distributionstabeller visar nedanstående detaljer:

Kör nu proceduren på Publisher-databasen och se hur många poster som loggas i distributionstabeller. Utförande av en procedur uppdaterade 21 poster (1 post, 10 poster och 10 poster) som tidigare.

Verifiering av distributionstabeller visar följande data:

Låt oss ta en snabb titt på sp_browsereplcmds för att se det faktiska kommandot som tas emot:

Kommandot är “{ringa “dbo”.”test_proc” }” som kommer att köras i prenumerantdatabasen.

I replikeringsmonitorn kan vi se att endast 1 transaktion(er) med 1 kommando(n) levererades via replikering:

I vårt testfall har vi använt en procedur med endast 21 dataändringar. Men om vi gör det för en komplicerad procedur som involverar miljontals ändringar, då är det lagrade förfarandet med exekvering av det lagrade förfarandet alternativet kommer att vara effektivt för att minska replikeringsbelastningen.

Vi måste validera detta tillvägagångssätt genom att kontrollera om proceduren har logiken att uppdatera endast samma uppsättning poster i Publisher- och Prenumerantdatabaserna. Annars kommer detta att skapa datainkonsekvensproblem för utgivaren och prenumeranten.

Sätt 2:Konfigurera MaxCmdsInTran, ReadBatchSize och ReadBatchThreshold Log Reader Agent Parametrar

MaxCmdsInTran – indikerar det maximala antalet kommandon som logiskt kan grupperas inom en transaktion när data läses från utgivarens transaktionsloggar och skrivas till distributionsdatabasen.

I våra tidigare tester märkte vi att cirka 109225 kommandon samlades i en enda replikeringssekvens, vilket resulterade i en liten långsamhet eller latens. Om vi ställer in MaxCmdsInTran parametern till 10000, den enda exakta sekvensen nummer kommer att delas upp i 11 xact-sekvenser som resulterar i snabbare leverans av kommandon från utgivare till distributör . Även om det här alternativet hjälper till att minska konflikten i distributionsdatabasen och replikera data snabbare från utgivaren till prenumerantdatabasen, var försiktig när du använder det här alternativet. Det kan sluta med att den levererar data till prenumerantdatabasen och får åtkomst till den från prenumerantdatabastabellerna före slutet av den ursprungliga transaktionsomfånget.

ReadBatchSize – Den här parametern kanske inte är användbar för ett enda stort transaktionsscenario. Det hjälper dock när det händer massor av mindre transaktioner i Publisher-databasen.

Om antalet kommandon per transaktion är färre, kommer Log Reader Agent att kombinera flera ändringar i ett transaktionsomfång för en enda replikeringskommando. Läs batchstorleken anger hur många transaktioner som kan läsas i transaktionsloggen innan ändringar skickas till distributionsdatabasen. Värdena kan vara mellan 500 och 10 000.

ReadBatchThreshold – indikerar antalet kommandon som ska läsas från transaktionsloggen för Publisher-databasen innan de skickas till abonnenten med ett standardvärde på 0 för att skanna hela loggfilen. Vi kan dock minska det här värdet för att skicka data snabbare genom att begränsa det till 10000 eller 100000 sådana kommandon.

Sätt 3:Konfigurera de bästa värdena för parametern SubscriptionStreams

Prenumerationsströmmar – indikerar antalet anslutningar som en distributionsagent kan utföra parallellt för att hämta data från distributionsdatabasen och sprida den till abonnentdatabasen. Standardvärdet är 1 och föreslår endast en ström eller anslutning från distributionen till abonnentdatabasen. Värdena kan vara mellan 1 och 64. Om fler prenumerationsströmmar läggs till kan det hamna i CXPACKET-stockning (med andra ord parallellism). Därför bör du vara försiktig när du konfigurerar det här alternativet i produktion.

För att sammanfatta, försök att undvika enorma INSERT, UPDATE eller DELETE i en enda transaktion. Om det är omöjligt att eliminera dessa operationer skulle det bästa alternativet vara att testa ovanstående sätt och välja den som passar dina specifika förhållanden bäst av alla.

Blockeringar i distributionsdatabasen

Distributionsdatabasen är hjärtat i SQL Server Transactional Replication och om den inte underhålls ordentligt kommer det att uppstå många prestandaproblem.

För att sammanfatta alla rekommenderade metoder för distributionsdatabasens konfiguration måste vi se till att nedanstående konfigurationer görs korrekt:

Datafiler för distributionsdatabaserna bör placeras på hög IOPS-enheter. Om Publisher-databasen kommer att ha många dataändringar måste vi se till att distributionsdatabasen placeras på en enhet med hög IOPS. Den kommer kontinuerligt att ta emot data från Log Reader-agenten och skicka data till abonnentdatabasen via distributionsagenten. All replikerad data rensas från distributionsdatabasen var tionde minut via distributionsrensningsjobbet.
Konfigurera egenskaperna för initial filstorlek och autotillväxt för distributionsdatabasen med de rekommenderade värdena baserat på aktivitetsnivåerna i Publisher-databasen. Annars kommer det att leda till fragmentering av data och loggfiler som orsakar prestandaproblem.
Inkludera distributionsdatabaser i de vanliga indexunderhållsjobben som konfigurerats på servrarna där distributionsdatabasen finns.
Inkludera distributionsdatabaser i schemat för fullständiga säkerhetskopieringar för att felsöka specifika problem.
Se till att Distribution Clean-up:distribution jobbet körs var tionde minut enligt standardschemat. Annars fortsätter storleken på distributionsdatabasen att öka och leder till prestandaproblem.

Som vi har märkt hittills är nyckeltabellerna i distributionsdatabasen MSrepl_transactions och MSrepl_commands . Posterna infogas där av Log Reader Agent-jobbet, väljs av Distributionsagent-jobbet, appliceras i abonnentdatabasen och raderas eller rensas sedan av Distribution Clean-up-agentjobbet.

Om distributionsdatabasen inte är korrekt konfigurerad kan vi stöta på sessionsblockeringar över dessa två tabeller, vilket kommer att resultera i prestandaproblem med SQL Server-replikering.

Vi kan köra frågan nedan i vilken databas som helst för att se de blockeringssessioner som är tillgängliga i den aktuella instansen av SQL Server:

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

Om ovanstående fråga returnerar några resultat kan vi identifiera kommandon på de blockerade sessionerna genom att köra DBCC INPUTBUFFER(spid) console kommandot och vidta åtgärder i enlighet med detta.

Korruptionsrelaterade frågor

En SQL Server-databas använder sin algoritm eller logik för att lagra data i tabeller och hålla dem i omfattningar eller sidor. Databaskorruption är en process genom vilken det fysiska tillståndet för de databasrelaterade filerna/utvidgningarna/sidorna ändras från normalt till instabilt eller icke-hämtande tillstånd vilket gör datahämtningen svårare eller omöjlig.

Alla SQL Server-databaser är benägna att korrupta databaser. Orsakerna kan vara:

Hårdvarufel som problem med disk, lagring eller styrenhet;
Server OS-fel som korrigeringsproblem;
Strömavbrott som resulterar i en abrupt avstängning av servrar eller felaktig avstängning av databasen.

Om vi kan återställa eller reparera databaser utan dataförlust kommer SQL Server-replikeringen inte att påverkas. Men om det uppstår några dataförluster när vi återställer eller reparerar korrupta databaser, kommer vi att börja ta emot många dataintegritetsproblem som vi har diskuterat i vår tidigare artikel.

Korruption kan inträffa på olika komponenter, såsom:

Korruption av utgivardata/loggfil
Skadad prenumerantdata/loggfil
Korruption av distributionsdatabasdata/loggfil
Msdb-databasdata/loggfilskorruption

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.

Slutsats

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.