SQL Server Transactional Replication er en af de mest almindelige replikeringsteknikker, der bruges til at dele, kopiere eller distribuere data til flere destinationer. I denne artikel vil vi diskutere replikering, forskellige replikeringstyper og være særlig opmærksom på arbejdet med transaktionsreplikering.
Hvad er SQL Transactional Replication?
Replikering er SQL Server-teknologien til at kopiere eller distribuere data fra en database til en anden og samtidig bevare datakonsistens.
Replikering kan bruges til at overføre data fra en database til en anden
- på samme instans eller en anden instans på samme server;
- eller på tværs af servere på en enkelt placering eller flere steder.
Først bør vi gennemgå replikeringsarkitekturen og forstå replikeringsterminologierne.
SQL-serverreplikeringsarkitektur og terminologier
- Udgiveren er kildedatabaseforekomsten, der udgiver de dataændringer, der kan distribueres til en anden database. Data fra en enkelt udgiver kan sendes til en enkelt abonnent eller flere abonnenter .
- Abonnent er Destination Database Forekomsten, hvor vi distribuerer dataændringerne hentet fra Publisher-databasen. Abonnenten kan enten være en Publisher Instance eller en anden instans i Publisher Server/en anden Server på samme lokation/fjern placering. Før dataændringerne distribueres til Subscriber Database-instansen, gemmes disse data i distributøren .
- Distributøren er en database, der gemmer ændringslogfiler, der er hentet fra Publisher-databaser. Når en server er aktiveret som distributør, vil den oprette en systemdatabase ved navn distributionsdatabasen .
Ud fra placeringen af distributionsdatabaser kan de klassificeres som enten lokale eller fjerndistributører.
– Lokal distributør er en distributionsdatabase, der ligger på Publisher-databaseinstansen.
– Fjerndistributør er en distributionsdatabase, der findes enten i Subscriber-databaseforekomsten eller i enhver anden SQL Server-forekomst bortset fra Publisher-databaseforekomsten.
Den afgørende faktor er, hvor distributionsdatabasen skal placeres på Publisher-forekomsten (en anden forekomst). det afhænger af de tilgængelige serverressourcer til at håndtere datadistributionsbelastningen.
Afhængigt af, hvordan dataene sendes fra distributionsdatabasen til abonnentforekomsten, kan de klassificeres i enten Push eller Træk abonnementer .
– Push-abonnement betyder, at distributionsdatabasen påtager sig ansvaret for at skubbe dataene til abonnentdatabaseforekomsten.
– Træk abonnement betyder, at abonnentdatabaseinstansen tager ansvar for at trække de tilgængelige data fra distributionsdatabasen og anvende dem på abonnentdatabasen.
- Artikler er den grundlæggende enhed for replikation. Det angiver eventuelle dataændringer på dette databaseobjekt eller denne artikel, som vil blive replikeret fra udgiver til abonnent. Artiklen kan være en tabel, visning, indekseret visning, lagret procedure eller den brugerdefinerede funktion.
- Publikationer er en samling af en eller flere artikler fra databasen i Publisher.
- Abonnement definerer, hvilken publikation der vil blive modtaget. Det bestemmer også fra hvilken publikation og på hvilken tidsplan dataene replikeres. Abonnement kan enten være Push eller Pull (fra udgivelse til abonnement).
- Replikeringsagenter er selvstændige programmer, der er ansvarlige for at spore ændringer og distribuere data på tværs af udgiveren til distributøren og abonnenten. Alle replikeringsagenter udføres som job under SQL Server Agent. Det kan således administreres via SSMS under SQL Server Agent Jobs eller Replication Monitor. Følgende typer replikeringsagenter er tilgængelige:
- Snapshot Agent – Anvendes af næsten alle typer replikering. Snapshot-agenten kører fra serveren med distributionsdatabasen. Den forbereder skemaet og indledende data for alle artikler, der er inkluderet i en publikation på en udgiver. Den opretter også snapshot-filerne i en snapshot-mappe og registrerer synkroniseringsdetaljer i distributionsdatabasen.
- Loglæseragent – Anvendes af transaktionsreplikering. Målet er at læse dataændringerne for artikler aktiveret til replikering fra udgiverdatabasens transaktionslogfiler og gemt i distributionsdatabasen. Log Reader Agent kører fra distributørserveren.
- Distributionsagent – Anvendes af Transactional and Snapshot Replication. Den anvender de indledende Snapshot-filer og inkrementelle eller tilgængelige afventende transaktioner fra distributionsdatabasen til abonnentdatabasen. Distributionsagenten kører fra distributørserveren til Push-abonnementer og abonnentserveren til Pull-abonnementer.
- Flet agent – Bruges kun af Merge Replication. Den anvender de indledende snapshotfiler og afstemning af differentielle eller trinvise ændringer på tværs af udgiveren eller abonnenten. Merge Agent kører på distributørserveren til Push-replikering og fra abonnentserveren til Pull-abonnementer.
- Kølæseragent – Kølæseragent bruges af transaktionsreplikering med mulighed for opdatering i kø. Det flytter ændringer fra abonnent til udgiver. Kølæseragenten kører fra distributørserveren.
- Replikeringsvedligeholdelsesjob – Som forklaret tidligere er alle replikeringsagenter selvstændige programmer, der er opsat under konfiguration af replikering. De kører som job under SQL Server Agent Jobs. Få væsentlige opgaver, der skal bemærkes, er Distribution Clean Up:Distribution, Agent History Clean Up:Distribution og Expired Subscription Clean Up.
Typer af replikering i SQL Server
Nu når vi kender terminologien, lad os dykke ned i typerne af replikering.
- Transaktionsreplikering . Som navnet antyder, vil enhver transaktion eller dataændring inden for transaktionsomfanget på Publisher blive sendt til abonnenten i næsten realtid med mindre forsinkelser afhængigt af netværkets båndbredde og serverressourcer. Transaktionsreplikering bruger Log Reader Agent til at læse dataændringerne fra Transactional Logs i Publisher-databasen. Den bruger også distributionsagenten til at anvende ændringer på abonnenten. Af og til kan den bruge Snapshot Agent til at tage indledende Snapshot-data af alle replikerede artikler. Transaktionel replikeringspublikation kan falde ind under nedenstående kategorier:
- Standard transaktionsreplikering – Subscriber er en skrivebeskyttet database fra Transactional Replication-perspektivet. Eventuelle ændringer udført af nogen i abonnentdatabasen vil ikke blive sporet og opdateret til udgiverdatabasen. Standard transaktionsreplikering omtales ofte som transaktionsreplikering.
- Transaktionsreplikering med opdaterbare abonnementer er en forbedring af standardtransaktionel replikering, der sporer de dataændringer, der finder sted på abonnenter. Når dataændringer påbegyndes på et abonnement, der kan opdateres, videregives de først til udgiveren og derefter til andre abonnenter.
- Peer-to-Peer-replikering er en forbedring af standardtransaktionsreplikeringen. Det udbreder transaktionskonsistente ændringer i næsten realtid på tværs af flere serverforekomster.
- Tovejsreplikering er en forbedring af den standardtransaktionelle replikering, der tillader to servere (begrænset til kun 2 servere og derfor kaldet Bidirectional) at udveksle dataændringerne på tværs af hinanden med enhver server, der fungerer som en udgiver (for at sende ændringer til en anden server) eller som en abonnent (for at modtage ændringer fra en anden server).
- Flet replikering – Understøtter registrering af dataændringer, der finder sted på tværs af både udgiver og abonnent, og distribuerer dem til den anden server. Sammenfletningsreplikeringen kræver ROWGUID kolonne på tabelartiklerne involveret i fletreplikering. Den bruger triggere til at fange dataændringerne på tværs af udgiver og abonnent. Det leverer også ændringerne på tværs af servere, når både Publisher og Subscriber er forbundet til netværket. Merge Replication bruger Merge Agent til at replikere dataændringerne på tværs af Publisher og Subscriber.
- Snapshot-replikering – Som navnet indikerer, er Snapshot-replikering ikke afhængig af hverken transaktionslogfiler eller triggere til at fange ændringerne. Den tager et øjebliksbillede af artikler involveret i udgivelsen og anvender det på abonnenten med de optegnelser, der er tilgængelige på tidspunktet for øjebliksbilledet. Snapshot-replikeringen bruger Snapshot-agenten til at tage et øjebliksbillede af udgiveren og bruger distributionsagenten til at anvende disse registreringer til abonnenten.
SQL-servertransaktionel replikering
Transaktionel replikering foretrækkes typisk i scenarier, hvor OLTP Publisher-databasen har tunge data INSERT/UPDATE og/eller DELETE-aktiviteter.
Da Publisher-serverforekomsten har en enorm DISK IO i gang, kan generering af rapporter forårsage alvorlige blokeringer. Det kan også påvirke serverens ydeevne. Derfor er en anden server med næsten realtidsdata god til at aflaste rapporteringskravene.
Et af de grundlæggende krav til transaktionsreplikering er, at de replikerede tabeller skal have en primær nøgle tilgængelig.
Vi kan opsummere, hvordan transaktionsreplikering fungerer. Tag et kig på nedenstående Transactional Replication Architecture-diagram taget fra den officielle Microsoft-dokumentation.
Publikationen oprettes i Publisher-databasen, der omfatter listen over artikler til replikering til abonnentdatabasen.
Transaktionel replikering vil typisk blive initialiseret fra udgiver til distributør via Snapshot-agenten eller fuld sikkerhedskopiering. Snapshot-agenten understøttes via Replication Configuration Wizard. Den fulde backup understøttes via TSQL-erklæringer for at initialisere transaktionsreplikeringen.
Log Reader Agent scanner Transaktionsloggen for Publisher-databasen for sporede artikler. Derefter kopierer den dataændringerne fra transaktionsloggen til distributionsdatabasen.
Distributionsdatabasen kan være enten i Publisher eller Subscriber; det kan også være eller en anden uafhængig SQL Server-instans.
Bemærk også følgende ting:
- Log Reader Agent kører kontinuerligt fra distributørserveren for at scanne efter nye kommandoer markeret til replikering. Men hvis du ikke ønsker at køre kontinuerligt og ønsker at køre efter en tidsplan i stedet, kan vi ændre Log Reader Agent SQL Job, der vil blive oprettet.
- Log Reader Agent henter alle poster, der er markeret til replikering, fra transaktionslog i batches og sender dem til distributionsdatabasen.
- Log Reader Agent henter kun forpligtede transaktioner fra Transactional Log of Publisher Database. Så alle langvarige forespørgsler på Publisher-databasen kan direkte påvirke replikering, da den venter på, at den aktive transaktion er fuldført.
Distributionsagenten henter alle ikke-distribuerede nye kommandoer fra distributionsdatabasen og anvender dem til abonnementsdatabasen via enten push- eller pull-mekanisme. Som tidligere nævnt, hvis Push Subscription Distributor overtager ejerskabet for at anvende ændringerne fra Distribution database til Subscriber, mens Pull Subscription Subscriber database tager ejerskab for at hente ændringerne fra Distribution database til Subscriber.
Når posterne er distribueret med succes fra distribution til abonnent-databasen, vil de blive markeret som distribueret og markeret til sletning fra distributionsdatabasen. Et af nøglereplikeringsvedligeholdelsesjob med navnet Distribution Clean Up:Distributionsjob kører en gang hvert 10. minut for at slette de distribuerede poster fra distributionsdatabasen for at bevare distributionsdatabasens størrelse under kontrol.
Med den detaljerede forklaring af begreberne replikering og transaktionsreplikering kan vi få fingrene i det ved at konfigurere replikering til AdventureWorks database og verificerende replikering for hver komponent, der diskuteres teoretisk.
Konfiguration af transaktionsreplikering trin for trin (via SSMS GUI)
Transaktionel replikeringskonfiguration involverer 3 hovedtrin:
- Konfiguration af distributionsdatabase
- Oprettelse af publikationer
- Oprettelse af abonnement
Før du prøver at konfigurere replikering, skal du sørge for, at replikeringskomponenter er installeret som en del af SQL Server-installationen, eller brug SQL Server-medier til at installere replikeringskomponenter, da de er nødvendige for opgaven.
I SSMS skal du oprette forbindelse til Publisher Database Instance og højreklik på replikering :
Distribution er ikke konfigureret lige nu. Derfor har vi indstillingen Konfigurer distribution. Vi kan enten konfigurere distributionsdatabasen ved hjælp af guiden Konfigurer distribution eller via guiden til oprettelse af publikationer.
Følg nedenstående trin for at konfigurere distributionsdatabasen og publikationen:
Udvid Replikering og højreklik på Ny udgivelse .
Guiden Ny udgivelse vil lancere. Klik på Næste for at se distributøren konfigurationsmuligheder.
Som standard vælger den Publisher-serveren til at holde distributionsdatabasen. Hvis du ønsker at bruge en ekstern distributionsdatabase, skal du vælge den anden mulighed. Klik på Næste .
Den næste mulighed er at konfigurere Snapshot-mappen . Skift den til den ønskede mappe. Ellers vil den som standard blive oprettet på SQL Server installationsmappestien. Klik på Næste .
Vælg Publication Database (her er det AdventureWorks ), og klik på Næste .
Vælg Udgivelsestype – Transaktionsreplikering . Klik på Næste .
Vælg Artikler for denne udgivelse. Til testformål skal du vælge alle tabeller og Visninger :
Før du klikker på Næste , udvid tabellerne igen for at bekræfte nogle problemer.
Nogle tabeller er markeret med røde ikoner. Når vi klikker på disse tabeller, ser vi advarslen, der indikerer, at en tabel ikke kan replikeres, fordi den ikke har en primær nøgle, et af de afgørende krav til transaktionsreplikering. Vi vil senere komme nærmere ind på det. Klik nu på Næste .
En side med Artikelproblemer relateret til afhængigheder vises. Klik på Næste .
Den næste mulighed er at filtrere tabelrækker – da vi tester den grundlæggende replikation, kan vi ignorere den. Klik på Næste .
Konfigurer Snapshot Agent – ignorer og klik på Næste .
Agent Indstillinger – klik på Sikkerhedsindstillinger for at konfigurere kontoen til at udføre Snapshot-agenten og Log Reader Agent under den.
Skift derefter Snapshot Agent-processen at køre under SQL Server Agent Service Account.
Indstil Log Reader Agent til Opret forbindelse til udgiver> ved at efterligne proceskontoen . Klik på OK .
Agentsikkerheden vil blive opdateret.
Derfor har vi konfigureret Distributoren og alle elementer i publikationen som Artikler , Snapshot Agent , Loglæseragent , og Agentværdipapirer . Vi har næsten afsluttet oprettelsen af publikationen via Wizard.
Hvis du har brug for at studere yderligere om TSQL-scripts, der bruges til at oprette publikation, kan vi kontrollere Generer en script-fil for at oprette publikationen mulighed. Ellers skal du klikke på Næste .
Da jeg valgte at gemme filen, giver guiden mig mulighed for at indstille Script-filstien og navn . Angiv disse detaljer, og klik på Næste .
Guiden beder endelig om Udgivelsesnavnet , jeg har kaldt det AdventureWorks_pub med databasenavnet og nøgleord for at angive det som en publikation for lettere identifikation.
Bekræft alle data, der er angivet i oversigten side, og klik på Udfør .
Guiden viser status i Oprettelse af publikation . Når det er færdigt, ser vi bekræftelsen. Klik på Luk .
For at bekræfte den vellykkede oprettelse af Distributoren (Distributionsdatabase), udvid systemdatabaserne:
For at bekræfte den vellykkede oprettelse af Publikation , udvid Lokal udgivelse :
Vi har konfigureret distributionsdatabasen og oprettet publikationsdatabasen på AdventureWorks-databasen succesfuldt. Nu kan vi fortsætte med Abonnementet skabelse
Højreklik på den nye Publikation vi har lige oprettet og vælg Nye abonnementer :
Guiden Nye abonnementer vil dukke op. Klik på Næste for at starte processen .
Publikationen side beder om at sikre, at både Publication og Udgiver databaser er valgt. Klik på Næste .
Indstil Distributionsagent til enten Push eller Træk Abonnement. Vi kommer til at bruge Publisher Server som abonnent, og den type vil ikke have nogen indflydelse. Derfor forlader vi standard Push Abonnement. Klik på Næste .
Vælg Abonnenter (database). Jeg vælger AdventureWorks_REPL gendannet fra den samme AdventureWorks Database backup. Klik på Næste .
Indstil Agentsikkerhed :
Da jeg vil gøre alt inden for en enkelt server, bruger jeg Agent-tjenestekontoen .
Det næste vindue viser Distribution Agent Security værdier, der allerede er konfigureret. Klik på Næste .
Synkroniseringsplan – lad det være standard. Klik på Næste .
Initialiser abonnementer – lad den stå med standardværdierne. Klik på Næste .
Når du har angivet alle de nødvendige detaljer, vil du være i stand til at fuldføre processen med at oprette abonnementet. Tjek Generer script-fil... mulighed for at studere scripts senere og klik på Næste .
Angiv stien til at gemme filerne, klik på Næste .
Tag et kig på oversigten og tjek alle de konfigurerede værdier. Når du er verificeret, skal du klikke på Udfør .
Oprettelse af abonnement er fuldført. Klik på Luk .
Nu kan vi se abonnementet vist under vores Publikation .
Konfigurer Snapshot Agent
Vores næste skridt er at arbejde på øjebliksbilledet Agent for at sende de indledende data fra Udgiver til Abonnent .
Før vi går ind i det, skal vi lægge mærke til replikeringsmonitoren . Dette kritiske værktøj er tilgængeligt i SSMS til at se replikeringsstatus på forskellige niveauer, serverniveau, udgiverdatabaseniveau, abonnementsniveau og replikeringsagentniveau.
Højreklik på replikering /Lokal udgivelse /Lokalt abonnement /Publikation eller abonnementet vi oprettede for at starte replikeringsovervågningen som vist nedenfor:
I replikeringsmonitor , udvid Publisher Server (RRJ)> Publikation ([AdventureWorks]:AdventureWorks_pub) for at få vist abonnementsoplysningerne. Højreklik på Abonnement og vælg Se detaljer .
Som vi kan se, er oplysningerne om Initial Snapshot for vores publikation AdventureWorks_pub er endnu ikke tilgængelig. Vi bliver nødt til at udføre Snapshot-agentjobbet for at sende indledende data til abonnentdatabasen .
Hold dette vindue åbent for at se status for Snapshot efter start af Snapshot Agent-jobbet .
Højreklik på Publikation > Se Snapshot Agent Status :
Agenten har aldrig været kørt meddelelsen angiver, at vi aldrig har udført Snapshot Agent. Klik på Start .
Mens Snapshot-agenten kører, kan du se fremskridtene:
Når alle snapshots er oprettet, vil det frembringe bekræftelsesmeddelelsen:
Vi kan se Snapshot-filerne oprettet for nylig i Snapshot-mappen, som vi tidligere har angivet stien til.
Når alle snapshots er anvendt af Distributionsagenten til Abonnentdatabasen , vil den vise nedenstående status i den åbne replikeringsmonitor vindue:
Tillykke! Vi har konfigureret transaktionsreplikering med Snapshot Agent.
Bemærk :Hvis vi har en enorm Publisher-database, kan det tage meget tid at oprette et øjebliksbillede. Det anbefales derfor at bruge den fulde sikkerhedskopi af Publisher-databasen i stedet for at udføre Snapshot-agenten – vi vil dække dette problem i de efterfølgende artikler.
Bekræftelse af replikeringskomponenter
Alle replikeringskomponenter kan verificeres af både SSMS GUI og TSQL-forespørgsler. Vi vil diskutere det i yderligere artikler, og her vil vi hurtigt forklare, hvordan du kan se egenskaberne for nedenstående komponenter.
Udgiver
Højreklik på replikering i SSMS > Udgiveregenskaber > Udgivelsesdatabaser :
For at se detaljer om udgiveren , udfør nedenstående forespørgsler mod distributionsdatabasen.
USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO
Abonnent
Abonnentoplysninger kan fås med nedenstående forespørgsel i SSMS.
USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info
Distributør
Højreklik på replikering i SSMS > Distributør Egenskaber :
Klik på Udgivere for at vise listen over alle udgivere, der bruger denne distributionsdatabase.
I SSMS kan vi køre nedenstående forespørgsel for at få de samme detaljer.
USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO
Artikler
Højreklik på Publikation > Publikationsegenskaber > Artikler . Du vil se listen over alle tilgængelige artikler. Egenskaberne for individuelle artikler kan ændres ved at klikke på Artikelegenskaber også.
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
Publikation
Højreklik på Publikation > Egenskaber :
I SSMS kan vi køre nedenstående forespørgsel for at se Publikationsegenskaberne :
USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications
Abonnement
Højreklik på Abonnement > Abonnementsegenskaber :
I SSMS kan vi udføre nedenstående script for at få abonnementsoplysningerne:
USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO
Replikeringsagenter
Under SQL Server Agent Jobs , kan vi finde de specifikke job oprettet til alle replikeringsagenter:
I SSMS kan vi udføre forespørgslen for at finde ud af, hvilket job der er det nødvendige Log Reader Agent Job , Snapshot Agent Job , og Distributionsagentjob . Desuden kan vi se Oprydningsjobbet for distributionsagent og adskillige andre job relateret til replikering, der blev oprettet, mens vi satte udgivelse og abonnementer internt.
Sådan fungerer Log Reader Agent
Loglæseragenten læser alle forpligtede data fra Publisher-databasens transaktionslogfiler og skubber dem til distributørdatabasen. Selvom Microsoft ikke tilbyder en officiel måde at læse transaktionslogfiler på, er der få udokumenterede funktioner som fn_dblog() og fn_dump_dblog() der kan læse data fra logfiler. Disse funktioner er dog udokumenterede og ikke dækket af Microsoft-support. Derfor vil vi ikke udforske dem yderligere.
Hvordan distributionsagent leverer dataændringerne til abonnentdatabasen
Når dataene er skrevet til distributionsdatabasen, kan vi læse, hvordan disse data er gemt i distributionstabeller. Til det anvender vi sp_browsereplcmds procedure – den henter posterne på tværs af MSrepl_commands og MSrepl_transactions tabeller.
Til læringsformål, lad os tage en tabel med 3 kolonner med navnet Person.ContactType :
Det oprettede abonnement vil lave 3 procedurer for hver artikel, der er en del af Publication in Subscriber database med nedenstående navnekonventioner:
- dbo.sp_MSins_
- dbo.sp_MSupd_
- dbo.sp_MSdel_
For artiklen Person.ContactType Table kan vi se nedenstående procedurer oprettet i abonnentdatabasen:
- dbo.sp_MSins_PersonContactType – INDSÆT nye registreringer hentet fra Transaction Logs of Publisher-databasen og derefter spredt til distributionsdatabasen.
- dbo.sp_MSupd_PersonContactType – OPDATERING ændringer hentet fra Transaction Logs of Publisher-databasen og derefter videregivet til distributionsdatabasen.
- dbo.sp_MSdel_PersonContactType – SLET 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 tabel.
Executing the SELECT statement on the table yields 20 records:
Next, I INSERTed a sample record into the Person.ContactType tabel:
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 ).
Konklusion
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.