sql >> Databáze >  >> RDS >> Sqlserver

SQL Server Transakční replikace interní

Transakční replikace serveru SQL je jednou z nejběžnějších replikačních technik používaných ke sdílení, kopírování nebo distribuci dat do více cílů. V tomto článku probereme replikaci, různé typy replikace a budeme věnovat zvláštní pozornost práci transakční replikace.

Co je transakční replikace SQL?

Replikace je technologie SQL Server pro kopírování nebo distribuci dat z jedné databáze do druhé při zachování konzistence dat.

Replikaci lze použít k přenosu dat z jedné databáze do druhé

  • ve stejné instanci nebo jiné instanci na stejném serveru;
  • nebo mezi servery na jednom místě nebo na více místech.

Nejprve bychom si měli projít Replikační architekturu a porozumět terminologii replikace.

Replikační architektura a terminologie serveru SQL Server

  • Vydavatel je instance zdrojové databáze, která publikuje změny dat, které lze distribuovat do jiné databáze. Data od jednoho vydavatele lze odeslat Jednému odběrateli nebo více odběratelů .
  • Odběratel je instance cílové databáze, kde distribuujeme změny dat zachycené z databáze vydavatelů. Předplatitelem může být buď instance vydavatele, nebo jiná instance na serveru vydavatele/jiný server ve stejném umístění/vzdáleném umístění. Před distribucí změn dat do instance databáze odběratelů jsou tato data uložena v distributorovi .
  • Distributor je databáze, která ukládá protokoly změn zachycené z databází aplikace Publisher. Když je server povolen jako distributor, vytvoří systémovou databázi s názvem distribuční databáze .

Podle umístění distribučních databází je lze klasifikovat jako místní nebo vzdálené distributory.

Místní distributor je distribuční databáze umístěná v instanci databáze Publisher.
Vzdálený distributor je distribuční databáze umístěná buď v instanci databáze Subscriber, nebo v jakékoli jiné instanci SQL Serveru kromě instance databáze Publisher.

Rozhodujícím faktorem je umístění distribuční databáze na instanci Publisher (jiná instance). to závisí na prostředcích serveru, které jsou k dispozici pro zpracování zatížení distribuce dat.

Podle způsobu, jakým budou data odesílána z Distribuční databáze do instance Subscriber, je lze rozdělit na Push nebo Vytáhnout odběry .

Push Subscription znamená, že distribuční databáze přebírá odpovědnost za odeslání dat do instance databáze předplatitelů.
Vytáhnout předplatné znamená, že instance databáze předplatitelů přebírá odpovědnost za stažení dostupných dat z databáze distribuce a jejich použití v databázi předplatitelů.

  • Články jsou základní jednotkou replikace. Označuje jakékoli změny dat v tomto databázovém objektu nebo článku, které budou replikovány z vydavatele na odběratele. Článek může být tabulka, zobrazení, indexované zobrazení, uložená procedura nebo funkce definovaná uživatelem.
  • Publikace jsou sbírkou jednoho nebo více článků z databáze v Publisheru.
  • Předplatné definuje, jaká publikace bude přijata. Také určuje, ze které publikace a v jakém plánu jsou data replikována. Předplatné může být Push nebo Pull (od publikace k předplatnému).
  • Replikační agenti jsou samostatné programy odpovědné za sledování změn a distribuci dat napříč vydavatelem distributorovi a předplatiteli. Všichni replikační agenti se spouštějí jako úlohy pod SQL Server Agent. Lze jej tedy spravovat prostřednictvím SSMS pod SQL Server Agent Jobs nebo Replication Monitor. K dispozici jsou následující typy replikačních agentů:
  • Agent snímku – Používá se téměř u všech typů replikací. Snapshot Agent se spouští ze serveru obsahujícího distribuční databázi. Připravuje schéma a počáteční údaje všech článků obsažených v publikaci o vydavateli. Také vytváří soubory snímků ve složce snímků a zaznamenává podrobnosti o synchronizaci do distribuční databáze.
  • Agent čtečky protokolů – Používá se transakční replikací. Cílem je načíst změny dat článků povolených pro replikaci z protokolů transakcí databáze vydavatelů a uložených do distribuční databáze. agent Log Reader se spouští z distribučního serveru.
  • Distribuční agent – Používá se transakční replikací a replikací snímků. Aplikuje počáteční soubory snímků a přírůstkové nebo dostupné nevyřízené transakce z databáze distribuce na databázi odběratelů. Distribuční agent se spouští z distribučního serveru pro Push Subscriptions a Subscriber Server pro Pull Subscriptions.
  • Agent sloučení – Používá se pouze replikací sloučení. Aplikuje počáteční soubory snímků a odsouhlasení rozdílových nebo přírůstkových změn napříč vydavatelem nebo předplatitelem. Agent sloučení běží na distribučním serveru pro Push Replication a ze serveru Subscriber pro Pull Subscriptions.
  • Agent čtečky front – Agent čtečky front je používán transakční replikací s možností aktualizace ve frontě. Přesouvá změny z odběratele na vydavatele. Agent čtečky front se spouští z distribučního serveru.
  • Úlohy údržby replikace – Jak bylo vysvětleno dříve, všichni replikační agenti jsou samostatné programy nastavené při konfiguraci Replikace. Spouštějí se jako úlohy pod SQL Server Agent Jobs. Mezi několik významných úloh, které je třeba poznamenat, patří Čištění distribuce:Distribuce, Čištění historie agentů:Distribuce a Čištění předplatného, ​​jehož platnost vypršela.

Typy replikace v SQL Server

Nyní, když známe terminologii, pojďme se ponořit do typů replikace.

  1. Transakční replikace . Jak název napovídá, každá transakce nebo změna dat v rámci transakčního rozsahu na vydavateli bude odeslána předplatiteli téměř v reálném čase s menším zpožděním v závislosti na šířce pásma sítě a prostředcích serveru. Transakční replikace používá agenta Log Reader ke čtení změn dat z transakčních protokolů databáze Publisher. Také používá distribučního agenta k aplikování změn na předplatitele. Příležitostně může použít Snapshot Agent k pořízení počátečních dat snímku všech replikovaných článků. Publikace transakční replikace může spadat do následujících kategorií:
    • Standardní transakční replikace – Subscriber je databáze pouze pro čtení z pohledu transakční replikace. Jakékoli změny provedené kýmkoli v databázi odběratelů nebudou sledovány a aktualizovány v databázi vydavatelů. Standardní transakční replikace se často nazývá transakční replikace.
    • Transakční replikace s aktualizovatelnými předplatnými je Vylepšení standardní transakční replikace, která sleduje změny dat probíhající na předplatitelích. Kdykoli jsou u Aktualizovatelného předplatného zahájeny změny dat, budou nejprve předány vydavateli a poté dalším předplatitelům.
    • Replikace typu peer-to-peer je vylepšením standardní transakční replikace. Šíří transačně konzistentní změny téměř v reálném čase na více serverových instancích.
    • Obousměrná replikace je vylepšení standardní transakční replikace, která umožňuje dvěma serverům (omezeno pouze na 2 servery a proto pojmenované obousměrné) vyměňovat si změny dat mezi sebou s libovolným serverem působícím jako vydavatel (pro odesílání změn na jiný server) nebo jako předplatitel (pro příjem změn z jiného serveru).
  2. Sloučit replikaci – Podporuje zachycování změn dat, ke kterým dochází u vydavatele i předplatitele, a distribuuje je na druhý server. Slučovací replikace vyžaduje ROWGUID ve sloupci Články tabulky zapojené do slučovací replikace. K zachycení změn dat napříč vydavatelem a odběratelem používá spouštěče. Změny také doručuje mezi servery, když jsou k síti připojeni vydavatel i odběratel. Replikace sloučení používá agenta sloučení k replikaci změn dat napříč vydavatelem a odběratelem.
  3. Replikace snímku – Jak název napovídá, replikace snímků se při zachycení změn nespoléhá ani na transakční protokoly, ani na spouštěče. Pořídí snímek článků zapojených do publikace a použije jej na předplatitele se záznamy dostupnými v době snímku. Replikace snímku používá agenta snímku k pořízení snímku vydavatele a používá agenta distribuce k použití těchto záznamů na předplatitele.

Transakční replikace serveru SQL Server

Transakční replikace je obvykle upřednostňována ve scénářích, kde databáze OLTP Publisher má náročné aktivity VLOŽENÍ/Aktualizace a/nebo DELETE dat.

Vzhledem k tomu, že instance serveru Publisher má velký objem DISK IO, generování sestav může způsobit závažná blokování. Může také ovlivnit výkon serveru. Jiný server s daty téměř v reálném čase je tedy vhodný pro snížení zátěže požadavků na vytváření sestav.

Jedním ze základních požadavků na transakční replikaci je, že replikované tabulky by měly mít k dispozici primární klíč.

Můžeme shrnout, jak funguje transakční replikace. Podívejte se na níže uvedený diagram architektury transakční replikace převzatý z oficiální dokumentace společnosti Microsoft.

Publikace je vytvořena v databázi vydavatelů, která obsahuje seznam článků pro replikaci do databáze odběratelů.

Transakční replikace bude obvykle inicializována od vydavatele k distributorovi prostřednictvím agenta snímku nebo úplných záloh. Snapshot Agent je podporován prostřednictvím Průvodce konfigurací replikace. Úplné zálohování je podporováno prostřednictvím příkazů TSQL pro inicializaci transakční replikace.

Agent Log Reader prohledává transakční protokol databáze vydavatele, zda neobsahuje sledované články. Poté zkopíruje změny dat z transakčního protokolu do distribuční databáze.

Distribuční databáze může být v aplikaci Publisher nebo Subscriber; může to být také nebo jiná nezávislá instance SQL Server.

Všimněte si také následujících věcí:

  • Agent Log Reader běží nepřetržitě z distribučního serveru a hledá nové příkazy označené pro replikaci. Pokud si však nepřejete spouštět nepřetržitě a chcete místo toho běžet podle plánu, můžeme změnit úlohu SQL agenta Log Reader Agent, která bude vytvořena.
  • Agent Log Reader vyzvedne všechny záznamy označené pro replikaci z dávek Transakčního protokolu a odešle je do distribuční databáze.
  • Agent Log Reader sbírá pouze potvrzené transakce z Transakčního protokolu databáze vydavatele. Jakékoli dlouhotrvající dotazy na databázi Publisher tedy mohou přímo ovlivnit replikaci, protože čeká na dokončení aktivní transakce.

Distribuční agent vyzvedne všechny nedistribuované nové příkazy z distribuční databáze a aplikuje je na předplatitelskou databázi prostřednictvím mechanismu Push nebo Pull. Jak již bylo zmíněno dříve, pokud Distributor Push Subscription převezme vlastnictví k použití změn z distribuční databáze na odběratele, zatímco v případě Pull Subscription Subscription převezme vlastnictví k načtení změn z distribuční databáze k odběrateli.

Jakmile budou záznamy úspěšně distribuovány z databáze distribuce odběratelům, budou označeny jako distribuované a označeny k odstranění z databáze distribuce. Jedna z úloh údržby replikace klíčů s názvem Vyčištění distribuce:Úloha distribuce se spouští každých 10 minut za účelem odstranění distribuovaných záznamů z databáze distribuce, aby byla velikost distribuční databáze pod kontrolou.

Díky podrobnému vysvětlení pojmů replikace a transakční replikace se nám to dostane do rukou tím, že nakonfigurujeme replikaci pro AdventureWorks databáze a ověření replikace pro každou teoreticky diskutovanou komponentu.

Konfigurace transakční replikace krok za krokem (prostřednictvím GUI SSMS)

Konfigurace transakční replikace zahrnuje 3 hlavní kroky:

  1. Konfigurace distribuční databáze
  2. Vytvoření publikace
  3. Vytvoření předplatného

Před pokusem o konfiguraci replikace se ujistěte, že komponenty replikace jsou nainstalovány jako součást instalace serveru SQL Server, nebo použijte médium SQL Server k instalaci komponent replikace, protože jsou pro danou úlohu nezbytné.

V SSMS se připojte k Instance databáze vydavatelů a klikněte pravým tlačítkem na Replikace :

Distribuce není momentálně nakonfigurována. Máme tedy možnost Konfigurovat distribuci. Distribuční databázi můžeme nakonfigurovat buď pomocí průvodce konfigurací distribuce, nebo pomocí průvodce vytvořením publikace.

Chcete-li nakonfigurovat distribuční databázi a publikaci, postupujte podle následujících kroků:

Rozbalit Replikace a klikněte pravým tlačítkem na Nová publikace .

Průvodce novou publikací spustí se. Klikněte na Další zobrazíte distributora možnosti konfigurace.

Ve výchozím nastavení zvolí vydavatelský server k uložení distribuční databáze. Pokud si přejete používat vzdálenou distribuční databázi, zvolte druhou možnost. Klikněte na Další .

Další možností je konfigurace složky snímků . Změňte jej na požadovanou složku. V opačném případě bude ve výchozím nastavení vytvořen v cestě instalační složky serveru SQL. Klikněte na Další .

Vyberte Databázi publikací (zde je to AdventureWorks ) a klikněte na Další .

Vyberte Typ publikace Transakční replikace . Klikněte na Další .

Vyberte Články pro tuto publikaci. Pro účely testování vyberte všechny tabulky a Zobrazení :

Před kliknutím na Další , ještě jednou rozbalte tabulky, abyste ověřili některé problémy.

Některé tabulky jsou označeny červenými ikonami. Když na tyto tabulky klikneme, zobrazí se upozornění, že tabulku nelze replikovat, protože nemá primární klíč, což je jeden z klíčových požadavků pro transakční replikaci. Později půjdeme podrobněji. Nyní klikněte na Další .

Stránka s problémy s články související se závislostmi se objeví. Klikněte na Další .

Další možností je Filtrovat řádky tabulky – protože testujeme základní replikaci, můžeme ji ignorovat. Klikněte na Další .

Konfigurace agenta snímku – ignorujte a klikněte na Další .

Agent Nastavení – klikněte na Nastavení zabezpečení pro konfiguraci účtu tak, aby spouštěl agenta Snapshot a agenta Log Reader pod ním.

Poté změňte Proces agenta snímku spustit pod účtem SQL Server Agent Service Account.

Nastavte Agenta aplikace Log Reader k Připojení k vydavateli> Zosobněním účtu Process . Klikněte na OK .

Agent Security bude aktualizován.

Proto jsme nakonfigurovali Distributor a všechny prvky Publikace jako Články , Agent snímku , Agent aplikace Log Reader a Agent Securities . Téměř jsme dokončili vytváření publikace pomocí průvodce.

Pokud potřebujete dále studovat skripty TSQL používané k vytvoření publikace, můžeme zkontrolovat Vygenerovat soubor skriptu pro vytvoření publikace volba. V opačném případě klikněte na Další .

Protože jsem zvolil uložení souboru, průvodce mi umožňuje nastavit cestu k souboru skriptu a jméno . Zadejte tyto podrobnosti a klikněte na Další .

Průvodce se nakonec zeptá na Název publikace , nazval jsem to AdventureWorks_pub s názvem databáze a klíčovými slovy pro označení publikace pro snazší identifikaci.

Ověřte všechna data uvedená v přehledu a klikněte na Dokončit .

Průvodce zobrazí průběh v Vytváření publikace . Až bude hotovo, uvidíme potvrzení. Klikněte na Zavřít .

Pro ověření úspěšného vytvoření distributora (Distribuční databáze), rozbalte systémové databáze:

Pro ověření úspěšného vytvoření Publikace , rozbalte Místní publikace :

Nakonfigurovali jsme distribuční databázi a vytvořili publikační databázi v databázi AdventureWorks úspěšně. Nyní můžeme pokračovat s předplatným vytvoření

Klikněte pravým tlačítkem na novou Publikaci právě jsme vytvořili a vybrali Nová předplatná :

Průvodce novými odběry objeví se. Chcete-li zahájit proces, klikněte na Další .

Publikace stránka požaduje zajistit, aby obě Publikace a Vydavatel databází jsou vybrány. Klikněte na Další .

Nastavte Distribučního agenta buď Push nebo Vytáhnout Předplatné. Budeme používat Server pro vydavatele jako odběratel a tento typ nebude mít žádný dopad. Ponecháváme tedy výchozí Push Předplatné. Klikněte na Další .

Vyberte Odběratelé (databáze). Vybírám AdventureWorks_REPL obnovena ze stejné zálohy AdventureWorks Database. Klikněte na Další .

Nastavte Zabezpečení agenta :

Protože budu dělat vše v rámci jednoho serveru, používám účet služby Agent .

Další okno představuje Zabezpečení agenta distribuce již nakonfigurované hodnoty. Klikněte na Další .

Plán synchronizace – ponechte výchozí nastavení. Klikněte na Další .

Inicializovat odběry – ponechat s výchozími hodnotami. Klikněte na Další .

Poté, co zadáte všechny potřebné údaje, budete moci dokončit proces vytvoření předplatného. Zkontrolujte Generovat soubor skriptu… možnost prostudovat skripty později a klikněte na Další .

Zadejte cestu k uložení souborů a klikněte na Další .

Podívejte se na souhrn a zkontrolujte všechny nakonfigurované hodnoty. Po ověření klikněte na Dokončit .

Vytvoření předplatného je dokončeno. Klikněte na Zavřít .

Nyní vidíme Předplatné zobrazeno pod naší Publikací .

Nakonfigurujte agenta snímku

Naším dalším krokem je pracovat na snímku Agent k odeslání počátečních dat od Vydavatele na předplatitele .

Než do něj vkročíme, musíme si všimnout Monitoru replikace . Tento kritický nástroj je k dispozici v SSMS pro zobrazení stavu replikace na různých úrovních, na úrovni serveru, na úrovni databáze vydavatele, na úrovni předplatného a na úrovni agentů replikace.

Klikněte pravým tlačítkem na Replikace /Místní publikace /Místní odběr /Publikace nebo Předplatné vytvořili jsme ke spuštění Monitoru replikace jak je uvedeno níže:

V Monitoru replikace , rozbalte Server pro vydavatele (RRJ)> Publikace ([AdventureWorks]:AdventureWorks_pub) pro zobrazení podrobností o předplatném. Klikněte pravým tlačítkem na Předplatné a vyberte Zobrazit podrobnosti .

Jak vidíme, informace o počátečním snímku pro naši publikaci AdventureWorks_pub zatím není k dispozici. Budeme muset spustit úlohu agenta Snapshot k odeslání počátečních dat do databáze odběratelů .

Po spuštění úlohy Snapshot Agent nechte toto okno otevřené, abyste viděli průběh Snapshotu .

Klikněte pravým tlačítkem na Publikace > Zobrazit stav agenta snímku :

Agent nebyl nikdy spuštěn zpráva uvádí, že jsme nikdy nespustili Snapshot Agent. Klikněte na Start .

Zatímco se Snapshot Agent spouští, můžete sledovat průběh:

Po vytvoření všech snímků se zobrazí potvrzovací zpráva:

Nově vytvořené soubory snímků můžeme vidět ve složce Snapshot, pro kterou jsme dříve poskytli cestu.

Po použití všech snímků Agentem distribuce do databáze předplatitelů , zobrazí se níže uvedený stav v otevřeném Monitoru replikace okno:

Gratuluji! Úspěšně jsme nakonfigurovali transakční replikaci pomocí Snapshot Agent.

Poznámka :Pokud máme obrovskou databázi vydavatelů, vytvoření snímku může zabrat hodně času. Proto se doporučuje použít úplnou zálohu databáze Publisher namísto spouštění agenta Snapshot Agent – ​​tomuto problému se budeme věnovat v následujících článcích.

Ověření replikačních komponent

Každá komponenta replikace může být ověřena jak pomocí SSMS GUI, tak pomocí TSQL dotazů. Probereme to v dalších článcích a zde rychle vysvětlíme, jak zobrazit vlastnosti níže uvedených komponent.

Vydavatel

V SSMS klikněte pravým tlačítkem na Replikace > Vlastnosti vydavatele > Publikační databáze :

Chcete-li zobrazit podrobnosti o Vydavateli , proveďte níže uvedené dotazy na distribuční databázi.

USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO

Odběratel

Informace o předplatiteli lze získat pomocí níže uvedeného dotazu v SSMS.

USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info

Distributor

V SSMS klikněte pravým tlačítkem na Replikace > Distributor Vlastnosti :

Klikněte na Vydavatelé k zobrazení seznamu všech vydavatelů používajících tuto distribuční databázi.

V SSMS můžeme spustit níže uvedený dotaz a získat stejné podrobnosti.

USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO	

Články

Klikněte pravým tlačítkem na Publikace > Vlastnosti publikace > Články . Zobrazí se seznam všech dostupných článků. Vlastnosti jednotlivých článků lze upravit kliknutím na Vlastnosti článku také.

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

Publikace

Klikněte pravým tlačítkem na Publikace > Vlastnosti :

V SSMS můžeme spustit níže uvedený dotaz a zobrazit Vlastnosti publikace :

USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications

Předplatné

Klikněte pravým tlačítkem na Předplatné > Vlastnosti předplatného :

V SSMS můžeme spustit níže uvedený skript a získat informace o předplatném:

USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO

Replikační agenti

V části Úlohy SQL Server Agent , můžeme najít konkrétní Jobs vytvořeno pro všechny replikační agenty:

V SSMS můžeme spustit dotaz, abychom zjistili, která úloha je nezbytná Log Reader Agent Job , Snímek úlohy agenta a Úlohy distribučního agenta . Kromě toho můžeme vidět úlohu vyčištění agenta distribuce a několik dalších úloh souvisejících s replikací vytvořených, když jsme interně nastavovali publikování a předplatné.

Jak funguje agent Log Reader

Agent čtečky protokolů přečte všechna potvrzená data z transakčních protokolů databáze Publisher a odešle je do databáze distributorů. Přestože společnost Microsoft neposkytuje oficiální způsob, jak číst protokoly transakcí, existuje několik nezdokumentovaných funkcí, jako je fn_dblog() a fn_dump_dblog() který umí číst data ze souborů protokolu. Tyto funkce jsou však nezdokumentované a nevztahuje se na ně podpora společnosti Microsoft. Nebudeme je tedy dále zkoumat.

Jak agent distribuce doručuje změny dat do databáze odběratelů

Jakmile jsou data zapsána do distribuční databáze, můžeme si přečíst, jak jsou tato data uložena v distribučních tabulkách. K tomu použijeme sp_browsereplcmds procedura – načte záznamy přes MSrepl_commands a MSrepl_transactions tabulky.

Pro účely učení si vezměme tabulku se 3 sloupci s názvem Person.ContactType :

Vytvořené předplatné vytvoří 3 procedury pro každý článek, který je součástí publikace v databázi předplatitelů s níže uvedenými konvencemi pro pojmenování:

  • dbo.sp_MSins_
  • dbo.sp_MSupd_
  • dbo.sp_MSdel_

V článku Person.ContactType Table vidíme níže uvedené postupy vytvořené v databázi odběratelů:

  • dbo.sp_MSins_PersonContactType INSERT nové záznamy zachycené z databáze Transaction Logs of Publisher a poté přenesené do distribuční databáze.
  • dbo.sp_MSupd_PersonContactType AKTUALIZACE změny zachycené z databáze Transaction Logs of Publisher a poté přenesené do distribuční databáze.
  • dbo.sp_MSdel_PersonContactType SMAZAT 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 tabulka.

Executing the SELECT statement on the table yields 20 records:

Next, I INSERTed a sample record into the Person.ContactType tabulka:

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

Závěr

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.


  1. Oracle.ManagedDataAccess.EntityFramework - ORA-01918:uživatel 'dbo' neexistuje

  2. Úvod do SQL

  3. Jak spustit funkci v Oracle s parametry

  4. phpMyAdmin hází #2002 nelze se přihlásit k serveru mysql phpmyadmin