SQL Server Transactional Replication är en av de vanligaste replikeringsteknikerna som används för att dela, kopiera eller distribuera data till flera destinationer. I den här artikeln kommer vi att diskutera replikering, olika replikeringstyper och ägna särskild uppmärksamhet åt transaktionsreplikeringsarbetet.
Vad är SQL-transaktionell replikering?
Replikering är SQL Server-tekniken för att kopiera eller distribuera data från en databas till en annan med bibehållen datakonsistens.
Replikering kan användas för att överföra data från en databas till en annan
- på samma instans eller en annan instans på samma server;
- eller över servrar på en enda plats eller flera platser.
Först bör vi gå igenom replikeringsarkitekturen och förstå replikeringsterminologierna.
SQL-serverreplikeringsarkitektur och terminologier
- Utgivaren är Source Database-instansen som publicerar dataändringarna som kan distribueras till en annan databas. Data från en enskild utgivare kan skickas till en enskild prenumerant eller flera prenumeranter .
- Prenumerant är Destination Database Instance där vi distribuerar dataändringarna som hämtats från Publisher Database. Prenumerant kan antingen vara en Publisher-instans eller en annan instans i Publisher Server/en annan server på samma plats/avlägsen plats. Innan dataändringarna distribueras till Subscriber Database-instansen lagras dessa data i distributören .
- Distributören är en databas som lagrar ändringsloggar som hämtats från Publishers databaser. När en server är aktiverad som distributör kommer den att skapa en systemdatabas med namnet distributionsdatabasen .
Genom placeringen av distributionsdatabaser kan de klassificeras som antingen lokala eller fjärrdistributörer.
– Lokal distributör är en distributionsdatabas som finns på Publisher-databasinstansen.
– Fjärrdistributör är en distributionsdatabas som finns antingen i Subscriber-databasinstansen eller i någon annan SQL Server-instans förutom Publisher-databasinstansen.
Den avgörande faktorn är var distributionsdatabasen ska placeras på Publisher-instansen (en annan instans). det beror på serverresurserna som är tillgängliga för att hantera datadistributionsbelastningen.
Beroende på hur informationen kommer att skickas från distributionsdatabasen till abonnentinstansen, kan den klassificeras i antingen Push eller Pull-prenumerationer .
– Push-prenumeration innebär att Distributionsdatabasen tar ansvar för att skicka data till Subscriber-databasen.
– Pull-prenumeration innebär att prenumerantdatabasinstansen tar ansvar för att hämta tillgänglig data från distributionsdatabasen och tillämpa den på prenumerantdatabasen.
- Artiklar är den grundläggande enheten för replikering. Det indikerar eventuella dataändringar på detta databasobjekt eller artikel som kommer att replikeras från utgivare till prenumerant. Artikeln kan vara en tabell, vy, indexerad vy, lagrad procedur eller den användardefinierade funktionen.
- Publikationer är en samling av en eller flera artiklar från databasen i Publisher.
- Prenumeration definierar vilken publikation som kommer att tas emot. Det bestämmer också från vilken publikation och på vilket schema data replikeras. Prenumeration kan vara antingen Push eller Pull (från publicering till prenumeration).
- Replikeringsagenter är fristående program som ansvarar för att spåra ändringar och distribuera data över utgivaren till distributören och prenumeranten. Alla replikeringsagenter körs som jobb under SQL Server Agent. Således kan den administreras via SSMS under SQL Server Agent Jobs eller Replication Monitor. Följande typer av replikeringsagenter är tillgängliga:
- Snapshot Agent – Används av nästan alla typer av replikering. Snapshot-agenten körs från servern som innehåller distributionsdatabasen. Den förbereder schemat och initiala data för alla artiklar som ingår i en publikation på en utgivare. Den skapar också ögonblicksbildfilerna i en ögonblicksbildsmapp och registrerar synkroniseringsdetaljer i distributionsdatabasen.
- Log Reader Agent – Används av transaktionsreplikering. Målet är att läsa dataändringarna för artiklar som är aktiverade för replikering från utgivardatabasens transaktionsloggar och lagrade i distributionsdatabasen. Log Reader Agent körs från distributörsservern.
- Distributionsagent – Används av transaktions- och ögonblicksreplikering. Den applicerar de initiala ögonblicksbilderna och inkrementella eller tillgängliga pågående transaktioner från distributionsdatabasen på abonnentdatabasen. Distributionsagenten körs från Distributor Server för Push-prenumerationer och Subscriber Server för Pull-prenumerationer.
- Slå samman agent – Används endast av sammanslagningsreplikering. Den tillämpar de initiala ögonblicksbildfilerna och avstämning av differentiella eller inkrementella förändringar mellan utgivaren eller prenumeranten. Merge Agent körs på distributörsservern för push-replikering och från abonnentservern för dragprenumerationer.
- Köläsaragent – Queue Reader Agent används av transaktionsreplikering med uppdateringsalternativ i kö. Den flyttar ändringar från prenumerant till utgivare. Queue Reader Agent körs från distributörsservern.
- Underhållsjobb för replikering – Som förklarats tidigare är alla replikeringsagenter fristående program som ställs in när du konfigurerar replikering. De körs som jobb under SQL Server Agent Jobs. Några viktiga jobb att notera är Distribution Clean Up:Distribution, Agent History Clean Up:Distribution och Expired Subscription Clean Up.
Typer av replikering i SQL Server
Nu när vi känner till terminologin, låt oss dyka in i typerna av replikering.
- Transaktionsreplikering . Som namnet antyder kommer varje transaktion eller dataändring inom transaktionsomfånget på Publisher att skickas till abonnenten i nästan realtid med mindre förseningar beroende på nätverkets bandbredd och serverresurser. Transaktionsreplikering använder Log Reader Agent för att läsa dataändringarna från Transaktionsloggarna i Publisher-databasen. Den använder också distributionsagenten för att tillämpa ändringar på abonnenten. Ibland kan den använda Snapshot Agent för att ta initiala Snapshot-data för alla replikerade artiklar. Transaktionell replikeringspublikation kan falla under kategorierna nedan:
- Standard transaktionsreplikering – Subscriber är en skrivskyddad databas ur transaktionsreplikeringsperspektivet. Eventuella ändringar som görs av någon i prenumerantdatabasen kommer inte att spåras och uppdateras till utgivardatabasen. Standardtransaktionell replikering kallas ofta för transaktionsreplikering.
- Transaktionsreplikering med uppdateringsbara prenumerationer är en förbättring av standardtransaktionell replikering som spårar dataändringar som sker på prenumerationer. Närhelst dataändringar initieras på en uppdateringsbar prenumeration kommer de först att spridas till utgivaren och sedan till andra prenumeranter.
- Peer-to-Peer-replikering är en förbättring av standardtransaktionell replikering. Den sprider transaktionskonsekventa förändringar i nästan realtid över flera serverinstanser.
- Dubbelriktad replikering är en förbättring av standardtransaktionsreplikeringen som tillåter två servrar (gränsen till endast 2 servrar och därför namngiven Bidirectional) att utbyta dataändringarna mellan varandra med vilken server som helst som fungerar som en utgivare (för att skicka ändringar till en annan server) eller som en prenumerant (för att ta emot ändringar från en annan server).
- Slå samman replikering – Stöder insamling av dataändringar som sker över både utgivare och prenumeranter och distribuerar den till den andra servern. Sammanfogningsreplikeringen kräver ROWGUID kolumnen på tabellartiklarna som är involverade i sammanslagningsreplikering. Den använder triggers för att fånga dataändringarna mellan utgivare och prenumeranter. Dessutom levererar den ändringarna över servrar när både utgivare och prenumerant är anslutna till nätverket. Merge Replication använder Merge Agent för att replikera dataändringarna mellan utgivare och prenumeranter.
- Snapshot Replikering – Som namnet indikerar, förlitar sig Snapshot Replication inte på vare sig transaktionsloggar eller utlösare för att fånga ändringarna. Den tar en ögonblicksbild av artiklar som är involverade i publicering och tillämpar den på abonnenten med de uppgifter som är tillgängliga vid tidpunkten för ögonblicksbilden. Snapshot-replikeringen använder Snapshot-agenten för att ta en ögonblicksbild av utgivaren och använder distributionsagenten för att tillämpa dessa poster på prenumerant.
SQL-servertransaktionsreplikering
Transaktionsreplikering är vanligtvis att föredra i scenarier där OLTP Publisher-databasen har tunga data INSERT/UPDATE och/eller DELETE-aktiviteter.
Eftersom Publisher-serverinstansen har en enorm DISK IO på gång, kan generering av rapporter orsaka allvarliga blockeringar. Det kan också påverka serverns prestanda. Därför är en annan server med nästan realtidsdata bra för att avlasta rapporteringskraven.
Ett av de grundläggande kraven för transaktionsreplikering är att de replikerade tabellerna ska ha en tillgänglig primärnyckel.
Vi kan sammanfatta hur transaktionsreplikering fungerar. Ta en titt på diagrammet nedan för Transactional Replication Architecture hämtat från den officiella Microsoft-dokumentationen.
Publikationen skapas i Publisher-databasen som innehåller listan över artiklar för replikering till prenumerantdatabasen.
Transaktionsreplikering initieras vanligtvis från utgivare till distributör via Snapshot Agent eller fullständiga säkerhetskopior. Snapshot Agent stöds via Replication Configuration Wizard. Den fullständiga säkerhetskopieringen stöds via TSQL-utlåtanden för att initiera transaktionsreplikeringen.
Log Reader Agent skannar Transaktionsloggen i Publisher-databasen efter spårade artiklar. Sedan kopierar den dataändringarna från transaktionsloggen till distributionsdatabasen.
Distributionsdatabasen kan vara antingen i Publisher eller Subscriber; det kan också vara eller en annan oberoende SQL Server-instans.
Observera även följande saker:
- Log Reader Agent körs kontinuerligt från distributörsservern för att söka efter nya kommandon markerade för replikering. Men om du inte vill köra kontinuerligt och istället vill köra enligt ett schema kan vi ändra Log Reader Agent SQL-jobbet som kommer att skapas.
- Log Reader Agent hämtar alla poster som är markerade för replikering från transaktionsloggar-batcherna och skickar dem till distributionsdatabasen.
- Log Reader Agent hämtar endast ingångna transaktioner från Transactional Log of Publisher Database. Så alla långvariga frågor i Publisher-databasen kan direkt påverka replikering eftersom den väntar på att den aktiva transaktionen ska slutföras.
Distributionsagenten hämtar alla odistribuerade nya kommandon från distributionsdatabasen och applicerar dem på prenumerationsdatabasen via antingen push- eller pull-mekanism. Som nämnts tidigare, om Push Subscription Distributor tar äganderätten för att tillämpa ändringarna från distributionsdatabasen till prenumerant medan i Pull Subscription Subscriber databasen tar äganderätten för att hämta ändringarna från distributionsdatabasen till prenumerant.
När posterna väl har distribuerats från databasen Distribution to Subscriber kommer de att markeras som distribuerade och markeras för radering från distributionsdatabasen. Ett av nyckelreplikeringsunderhållsjobben med namnet Distribution Clean Up:Distributionsjobbet körs en gång var tionde minut för att radera de distribuerade posterna från distributionsdatabasen för att behålla distributionsdatabasens storlek under kontroll.
Med den detaljerade förklaringen av begreppen replikering och transaktionsreplikering kan vi lägga vantarna på det genom att konfigurera replikering för AdventureWorks databas och verifierande replikering för varje komponent som diskuteras teoretiskt.
Konfigurera transaktionsreplikering steg för steg (via SSMS GUI)
Transaktionell replikeringskonfiguration innefattar tre huvudsteg:
- Konfigurera distributionsdatabasen
- Skapa publikationer
- Skapa prenumeration
Innan du försöker konfigurera replikering, se till att replikeringskomponenter är installerade som en del av SQL Server-installationen eller använd SQL Server-media för att installera replikeringskomponenter, eftersom de är nödvändiga för uppgiften.
I SSMS ansluter du till Publisher Database Instance och högerklicka på replikering :
Distributionen är inte konfigurerad just nu. Därför har vi alternativet Konfigurera distribution. Vi kan antingen konfigurera distributionsdatabasen med hjälp av guiden Konfigurera distribution eller via guiden för att skapa publikationer.
Följ stegen nedan för att konfigurera distributionsdatabasen och publikationen:
Utöka Replikering och högerklicka på Ny publikation .
Guiden för ny publicering kommer att lanseras. Klicka på Nästa för att se distributören konfigurationsalternativ.
Som standard väljer den Publisher-servern för att hålla distributionsdatabasen. Om du vill använda en fjärrdistributionsdatabas, välj det andra alternativet. Klicka på Nästa .
Nästa alternativ är att konfigurera Snapshot-mappen . Ändra den till önskad mapp. Annars kommer den att skapas på sökvägen till SQL Server-installationsmappen som standard. Klicka på Nästa .
Välj Publication Database (här är det AdventureWorks ) och klicka på Nästa .
Välj Publicationstyp – Transaktionsreplikering . Klicka på Nästa .
Välj Artiklar för denna publikation. För teständamål, välj alla tabeller och Visningar :
Innan du klickar på Nästa , expandera tabellerna en gång till för att verifiera vissa problem.
Vissa tabeller är markerade med röda ikoner. När vi klickar på dessa tabeller ser vi en varning som indikerar att en tabell inte kan replikeras eftersom den inte har en primärnyckel, ett av de avgörande kraven för transaktionsreplikering. Vi kommer senare att gå in mer i detalj. Klicka nu på Nästa .
En sida med artikelproblem relaterade till beroenden visas. Klicka på Nästa .
Nästa alternativ är att filtrera tabellrader – eftersom vi testar den grundläggande replikeringen kan vi ignorera den. Klicka på Nästa .
Konfigurera Snapshot Agent – ignorera och klicka på Nästa .
Agent Inställningar – klicka på Säkerhetsinställningar för att konfigurera kontot för att köra Snapshot-agenten och Log Reader Agent under den.
Ändra sedan Snapshot Agent Process att köra under SQL Server Agent Service Account.
Ställ in Log Reader Agent till Anslut till utgivare> Genom att utge sig för att vara processkontot . Klicka på OK .
Agentsäkerheten kommer att uppdateras.
Därför har vi konfigurerat Distributören och alla delar av publikationen som Artiklar , Snapshot Agent , Log Reader Agent och agentvärdepapper . Vi har nästan slutfört skapandet av publikationen via Wizard.
Om du behöver studera vidare om TSQL-skript som används för att skapa publikation, kan vi kontrollera Generera en skriptfil för att skapa publikationen alternativ. Annars klickar du på Nästa .
Eftersom jag valde att spara filen låter guiden mig ställa in Skriptfilsökvägen och namn . Ange dessa uppgifter och klicka på Nästa .
Guiden frågar slutligen efter publikationsnamnet , jag har döpt den till AdventureWorks_pub med databasens namn och nyckelord för att indikera det som en publikation för enklare identifiering.
Verifiera alla uppgifter som tillhandahålls i sammanfattningen sida och klicka på Slutför .
Guiden visar förloppet i Skapa publikation . När det är klart ser vi bekräftelsen. Klicka på Stäng .
För att verifiera att distributören har skapats framgångsrikt (Distributionsdatabas), expandera systemdatabaserna:
För att verifiera att Publicering har skapats framgångsrikt , expandera Lokal publikation :
Vi har konfigurerat distributionsdatabasen och skapat publikationsdatabasen på AdventureWorks-databasen framgångsrikt. Nu kan vi fortsätta med prenumerationen skapande
Högerklicka på den nya publikationen vi har precis skapat och väljer Nya prenumerationer :
Guiden för nya prenumerationer Kommer komma. För att starta processen, klicka på Nästa .
Publikationen sida ber att säkerställa att både Publication och Utgivare databaser är valda. Klicka på Nästa .
Ställ in Distributionsagent till antingen Push eller Pull Prenumeration. Vi kommer att använda Publisher Server som prenumerant, och den typen kommer inte att ha någon inverkan. Därför lämnar vi standardvärdet Push Prenumeration. Klicka på Nästa .
Välj Prenumeranter (databas). Jag väljer AdventureWorks_REPL återställd från samma säkerhetskopia av AdventureWorks Database. Klicka på Nästa .
Ställ in agentsäkerhet :
Eftersom jag ska göra allt inom en enda server använder jag agenttjänstkontot .
Nästa fönster visar Distribution Agent Security värden som redan är konfigurerade. Klicka på Nästa .
Synkroniseringsschema – lämna det till standard. Klicka på Nästa .
Initiera prenumerationer – lämna det med standardvärdena. Klicka på Nästa .
När du har angett alla nödvändiga detaljer kommer du att kunna slutföra processen för att skapa prenumerationen. Kontrollera Generera skriptfil... alternativet för att studera skripten senare och klicka på Nästa .
Ange sökvägen för att spara filerna, klicka på Nästa .
Ta en titt på sammanfattningen och kontrollera alla konfigurerade värden. När du har verifierat klickar du på Slutför .
Skapandet av prenumerationen är klar. Klicka på Stäng .
Nu kan vi se prenumerationen visas under vår Publikation .
Konfigurera Snapshot Agent
Vårt nästa steg är att arbeta med ögonblicksbilden Agent för att skicka inledande data från Utgivare till prenumerant .
Innan vi går in i det måste vi lägga märke till replikeringsmonitorn . Detta viktiga verktyg är tillgängligt i SSMS för att se replikeringsstatusen på olika nivåer, servernivå, utgivardatabasnivå, prenumerationsnivå och replikeringsagentnivå.
Högerklicka på replikering /Lokal publikation /Lokal prenumeration /Publikation eller prenumerationen vi skapade för att starta replikeringsmonitorn som visas nedan:
I Replication Monitor , expandera Publisher Server (RRJ)> Publikation ([AdventureWorks]:AdventureWorks_pub) för att visa prenumerationsinformationen. Högerklicka på Prenumeration och välj Visa detaljer .
Som vi kan se, informationen om Initial Snapshot för vår publikation AdventureWorks_pub är ännu inte tillgänglig. Vi måste köra Snapshot-agentjobbet för att skicka inledande data till prenumerantdatabasen .
Håll det här fönstret öppet för att se förloppet för Snapshot efter att ha startat Snapshot Agent-jobbet .
Högerklicka på Publikation > Visa status för ögonblicksbildagent :
Agenten har aldrig körts meddelandet säger att vi aldrig har kört Snapshot Agent. Klicka på Start .
Medan Snapshot Agent körs kan du se framstegen:
När alla ögonblicksbilder har skapats kommer det att producera bekräftelsemeddelandet:
Vi kan se Snapshot-filerna som skapats nyligen i Snapshot-mappen som vi angav sökvägen för tidigare.
När alla ögonblicksbilder har tillämpats av Distributionsagenten till Prenumerantdatabasen , kommer den att visa statusen nedan i den öppna replikeringsmonitorn fönster:
grattis! Vi har framgångsrikt konfigurerat transaktionsreplikering med hjälp av Snapshot Agent.
Obs :Om vi har en enorm utgivardatabas kan det ta mycket tid att skapa ögonblicksbilder. Därför rekommenderas det att använda den fullständiga säkerhetskopian av Publisher-databasen istället för att köra Snapshot Agent – vi kommer att täcka detta problem i efterföljande artiklar.
Verifiera replikeringskomponenter
Varje replikeringskomponent kan verifieras av både SSMS GUI och TSQL-frågor. Vi kommer att diskutera det i ytterligare artiklar, och här förklarar vi snabbt hur du ser egenskaperna hos komponenterna nedan.
Utgivare
I SSMS högerklickar du på replikering > Utgivaregenskaper > Publicationsdatabaser :
För att se detaljer om utgivaren , kör nedanstående frågor mot distributionsdatabasen.
USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO
Prenumerant
Prenumerantinformation kan erhållas med nedanstående fråga i SSMS.
USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info
Distributör
I SSMS högerklickar du på replikering > Distributör Egenskaper :
Klicka på Utgivare för att visa listan över alla utgivare som använder denna distributionsdatabasen.
I SSMS kan vi köra frågan nedan för att få samma information.
USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO
Artiklar
Högerklicka på Publikation > Publiceringsegenskaper > Artiklar . Du kommer att se listan över alla tillgängliga artiklar. Egenskaperna för enskilda artiklar kan ändras genom att klicka på Artikelegenskaper likaså.
USE AdventureWorks
GO
-- To View all articles available under a Publication
exec sp_helparticle @publication = 'Adventureworks_pub'
GO
-- To View all article columns for a particular article available under a Publication
exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'
GO
USE distribution
GO
SELECT * from MSArticles
Publicering
Högerklicka på Publikation > Egenskaper :
I SSMS kan vi köra frågan nedan för att se Publicationsegenskaper :
USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications
Prenumeration
Högerklicka på Prenumeration > Prenumerationsegenskaper :
I SSMS kan vi köra skriptet nedan för att få prenumerationsinformation:
USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO
replikeringsagenter
Under SQL Server Agent Jobs , kan vi hitta de specifika jobben skapad för alla replikeringsagenter:
I SSMS kan vi köra frågan för att ta reda på vilket jobb som är det nödvändiga Log Reader Agent Job , Snapshot Agent Job och Distributionsagentjobb . Dessutom kan vi se Rengöringsjobbet för distributionsagent och flera andra jobb relaterade till replikering skapades medan vi ställde in publicering och prenumerationer internt.
Hur Log Reader Agent fungerar
Log Reader Agent läser all registrerad data från Publisher-databasens transaktionsloggar och skickar den till Distributörsdatabasen. Även om Microsoft inte tillhandahåller ett officiellt sätt att läsa transaktionsloggar, finns det få odokumenterade funktioner som fn_dblog() och fn_dump_dblog() som kan läsa data från loggfiler. Dessa funktioner är dock odokumenterade och täcks inte av Microsofts support. Därför kommer vi inte att utforska dem ytterligare.
Hur distributionsagenten levererar dataändringarna till abonnentdatabasen
När data väl har skrivits till distributionsdatabasen kan vi läsa hur dessa data lagras i distributionstabeller. För det använder vi sp_browsereplcmds procedur – den hämtar posterna över MSrepl_commands och MSrepl_transactions tabeller.
För inlärningsändamål, låt oss ta en tabell med tre kolumner som heter Person.ContactType :
Den skapade prenumerationen kommer att göra 3 procedurer för varje artikel som är en del av Publication in Subscriber databas med nedanstående namnkonventioner:
- dbo.sp_MSins_
- dbo.sp_MSupd_
- dbo.sp_MSdel_
För artikeln Person.ContactType Table kan vi se procedurerna nedan skapade i prenumerantdatabasen:
- dbo.sp_MSins_PersonContactType – INSERT nya poster hämtade från Transaction Logs of Publisher-databasen och spreds sedan till distributionsdatabasen.
- dbo.sp_MSupd_PersonContactType – UPPDATERA ändringar som hämtats från Transaction Logs of Publisher-databasen och sedan spridits till distributionsdatabasen.
- dbo.sp_MSdel_PersonContactType – RADERA records captured from Transaction Logs of Publisher database and then propagated to the distribution database.
Script of the dbo.sp_MSins_PersonContactType Procedure
As you can see, it’s a straightforward INSERT statement that comes out of the distribution database:
ALTER procedure [dbo].[sp_MSins_PersonContactType]
@c1 int,
@c2 nvarchar(50),
@c3 datetime
as
begin
insert into [Person].[ContactType] (
[ContactTypeID],
[Name],
[ModifiedDate]
) values (
@c1,
@c2,
@c3 )
end
GO
Script of the dbo.sp_MSupd_PersonContactType Procedure
The script relies on the Primary Key values to identify the unique record for updating:
ALTER procedure [dbo].[sp_MSupd_PersonContactType]
@c1 int = NULL,
@c2 nvarchar(50) = NULL,
@c3 datetime = NULL,
@pkc1 int = NULL,
@bitmap binary(1)
as
begin
declare @primarykey_text nvarchar(100) = ''
update [Person].[ContactType] set
[Name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [Name] end,
[ModifiedDate] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [ModifiedDate] end
where [ContactTypeID] = @pkc1
if @@rowcount = 0
if @@microsoftversion>0x07320000
Begin
if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
Begin
set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13233
End
Else
exec sp_MSreplraiserror @errorid=20598
End
end
GO
Script of the dbo.sp_MSdel_PersonContactType Procedure
This script relies on the Primary Key values to identify a unique record for deleting records from the Subscriber :
ALTER procedure [dbo].[sp_MSdel_PersonContactType]
@pkc1 int
as
begin
declare @primarykey_text nvarchar(100) = ''
delete [Person].[ContactType]
where [ContactTypeID] = @pkc1
if @@rowcount = 0
if @@microsoftversion>0x07320000
Begin
if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
Begin
set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13234
End
Else
exec sp_MSreplraiserror @errorid=20598
End
end
GO
This clearly explains why Transactional Replication enforces the Primary Key as a key requirement for tables to be added as part of Replication .
Now, let’s see the Transactional Replication in action. Let’s change some data in the Publisher database. For simplicity, I’ll take the same Person.ContactType bord.
Executing the SELECT statement on the table yields 20 records:
Next, I INSERTed a sample record into the Person.ContactType tabell:
And, I UPDATE the newly inserted record:
DELETE the newly inserted record from the table:
We need to verify these transactions in Replication using sp_browsereplcmds
Changes from Person.ContactType were captured from the Transactional Logs of Publisher Database (AdventureWorks ) and sent to the Distribution database in the same order. Later, it was propagated to the Subscriber Database (AdventureWorks_REPL ).
Slutsats
Thanks for reading this long power-packed article! We have gone through a variety of topics, such as:
- Replication Architecture and Terminologies
- SQL Server Replication Types
- SQL Server Transactional Replication in Detail
- SQL Server Transactional Replication Configuration (Default approach)
- SQL Server Transactional Replication Verification
- SQL Server Transactional Replication in action
I hope that you’ve found lots of helpful information in this article. In subsequent parts, we’ll explore troubleshooting various issues that are frequently encountered in Replication, and learn how to handle them more efficiently.