sql >> Database >  >> RDS >> Sqlserver

Interne onderdelen voor transactiereplicatie van SQL Server

Transactiereplicatie van SQL Server is een van de meest voorkomende replicatietechnieken die wordt gebruikt om gegevens te delen, kopiëren of distribueren naar meerdere bestemmingen. In dit artikel bespreken we replicatie en verschillende replicatietypes, en besteden we speciale aandacht aan het transactionele replicatiewerk.

Wat is SQL-transactiereplicatie?

Replicatie is de SQL Server-technologie voor het kopiëren of distribueren van gegevens van de ene database naar de andere met behoud van gegevensconsistentie.

Replicatie kan worden gebruikt om gegevens van de ene database naar de andere over te dragen

  • op dezelfde instantie of een andere instantie op dezelfde server;
  • of tussen Servers op een enkele locatie of meerdere locaties.

Eerst moeten we de replicatie-architectuur doornemen en de terminologieën van replicatie begrijpen.

SQL Server Replicatie Architectuur &Terminologieën

  • De uitgever is de brondatabase-instantie die de gegevenswijzigingen publiceert die naar een andere database kunnen worden gedistribueerd. Gegevens van een één uitgever kan worden verzonden naar een Enkele Abonnee of meerdere Abonnees .
  • Abonnee is de bestemmingsdatabase-instantie waar we de gegevenswijzigingen distribueren die zijn vastgelegd uit de uitgeversdatabase. Abonnee kan een Publisher-instantie zijn of een andere instantie in Publisher Server/een andere server op dezelfde locatie/verre locatie. Voordat de gegevenswijzigingen worden gedistribueerd naar de abonneedatabase-instantie, worden deze gegevens opgeslagen in de distributeur .
  • De distributeur is een database die wijzigingslogboeken opslaat die zijn vastgelegd uit Publisher-databases. Wanneer een server is ingeschakeld als distributeur, zal deze een systeemdatabase maken met de naam distributiedatabase .

Op basis van de locatie van distributiedatabases kunnen ze worden geclassificeerd als lokale of externe distributeurs.

Lokale distributeur is een distributiedatabase die zich op het Publisher-database-exemplaar bevindt.
Verdeler op afstand is een distributiedatabase die zich ofwel in de abonneedatabase-instantie of in een andere SQL Server-instantie behalve de Publisher-database-instantie bevindt.

De beslissende factor is waar de Distributiedatabase op de Publisher-instantie (een andere instantie) moet worden geplaatst. het hangt af van de beschikbare serverbronnen om de gegevensdistributiebelasting te verwerken.

Afhankelijk van de manier waarop de gegevens van de distributiedatabase naar de abonnee-instantie worden verzonden, kan deze worden ingedeeld in Push of Abonnementen ophalen .

Push-abonnement betekent dat de distributiedatabase de verantwoordelijkheid op zich neemt om de gegevens naar de abonneedatabase-instantie te pushen.
Trek abonnement betekent dat de Abonneedatabase-instantie de verantwoordelijkheid neemt om de beschikbare gegevens uit de Distributiedatabase te halen en deze toe te passen op de Abonneedatabase.

  • Artikelen zijn de fundamentele eenheid van replicatie. Het geeft eventuele gegevenswijzigingen in dit databaseobject of artikel aan die van uitgever naar abonnee worden gerepliceerd. Het artikel kan een tabel, weergave, geïndexeerde weergave, opgeslagen procedure of de door de gebruiker gedefinieerde functie zijn.
  • Publicaties zijn een verzameling van een of meer artikelen uit de database in Publisher.
  • Abonnement bepaalt welke publicatie zal worden ontvangen. Het bepaalt ook uit welke publicatie en op welk schema de gegevens worden gerepliceerd. Abonnement kan Push of Pull zijn (van publicatie tot abonnement).
  • Replicatieagenten zijn zelfstandige programma's die verantwoordelijk zijn voor het volgen van wijzigingen en het distribueren van gegevens over de uitgever naar de distributeur en de abonnee. Alle replicatie-agents worden uitgevoerd als taken onder SQL Server Agent. Het kan dus worden beheerd via SSMS onder SQL Server Agent Jobs of Replication Monitor. De volgende typen replicatieagenten zijn beschikbaar:
  • Momentopname-agent - Gebruikt door bijna alle soorten replicatie. De Snapshot Agent wordt uitgevoerd vanaf de server die de distributiedatabase bevat. Het bereidt het schema en de initiële gegevens voor van alle artikelen die zijn opgenomen in een publicatie op een uitgever. Het creëert ook de Snapshot-bestanden in een snapshot-map en registreert de synchronisatiedetails in de Distributiedatabase.
  • Log Reader-agent – Gebruikt door Transactionele Replicatie. Het doel is om de gegevenswijzigingen te lezen van artikelen die zijn ingeschakeld voor replicatie vanuit de transactielogboeken van de uitgeversdatabase en zijn opgeslagen in de distributiedatabase. de Log Reader Agent draait vanaf de Distributor Server.
  • Distributieagent – Gebruikt door transactie- en momentopnamereplicatie. Het past de initiële Snapshot-bestanden en incrementele of beschikbare lopende transacties van de Distributiedatabase toe op de Abonneedatabase. De Distribution Agent draait vanaf de Distributor Server voor Push-abonnementen en de Subscriber Server voor Pull-abonnementen.
  • Agent samenvoegen – Alleen gebruikt door Merge Replication. Het past de initiële snapshot-bestanden en afstemming van differentiële of incrementele wijzigingen toe op de uitgever of abonnee. De Merge Agent draait op de Distributor Server voor Push Replication en vanaf de Subscriber Server voor Pull Subscriptions.
  • Wachtrijlezer-agent – Queue Reader Agent wordt gebruikt door Transactionele Replicatie met update-optie in wachtrij. Het verplaatst wijzigingen van abonnee naar uitgever. De Queue Reader Agent draait vanaf de Distributor Server.
  • Replicatie-onderhoudstaken – Zoals eerder uitgelegd, zijn alle Replication Agents zelfstandige programma's die zijn ingesteld tijdens het configureren van Replication. Ze worden uitgevoerd als taken onder SQL Server Agent Jobs. Enkele belangrijke taken die moeten worden opgemerkt, zijn Distributie opschonen:distributie, opschonen van agentgeschiedenis:distributie en opschonen van verlopen abonnement.

Soorten replicatie in SQL Server

Als we nu de terminologie kennen, gaan we dieper in op de soorten replicatie.

  1. Transactionele replicatie . Zoals de naam al doet vermoeden, wordt elke transactie of gegevenswijziging binnen het transactiebereik op Publisher bijna in realtime naar de abonnee verzonden met kleine vertragingen, afhankelijk van de netwerkbandbreedte en serverbronnen. Transactionele replicatie gebruikt de Log Reader Agent om de gegevenswijzigingen uit de Transactional Logs van de Publisher-database te lezen. Het gebruikt ook de Distributieagent om wijzigingen toe te passen op de Abonnee. Af en toe kan Snapshot Agent worden gebruikt om de eerste Snapshot-gegevens van alle gerepliceerde artikelen te nemen. Publicatie van transactiereplicatie kan onder de onderstaande categorieën vallen:
    • Standaard transactiereplicatie – Abonnee is een alleen-lezen database vanuit het perspectief van transactiereplicatie. Wijzigingen die door iemand in de Abonneedatabase worden uitgevoerd, worden niet bijgehouden en bijgewerkt naar de Uitgeversdatabase. De standaard transactiereplicatie wordt vaak transactiereplicatie genoemd.
    • Transactionele replicatie met bij te werken abonnementen is een verbetering van de standaard transactiereplicatie die de gegevenswijzigingen bijhoudt die plaatsvinden op abonnementen. Wanneer gegevenswijzigingen worden geïnitieerd op een updatebaar abonnement, worden deze eerst doorgegeven aan de uitgever en vervolgens aan andere abonnees.
    • Peer-to-peer-replicatie is een verbetering van de standaard transactiereplicatie. Het verspreidt transactieconsistente wijzigingen in bijna realtime over meerdere serverinstanties.
    • Bidirectionele replicatie is een verbetering van de standaard transactiereplicatie waarmee twee servers (beperkt tot slechts 2 servers en daarom bidirectioneel genoemd) de gegevenswijzigingen onderling kunnen uitwisselen met een server die optreedt als uitgever (om wijzigingen naar een andere server te verzenden) of als abonnee (om wijzigingen van een andere server te ontvangen).
  2. Replicatie samenvoegen – Ondersteunt het vastleggen van gegevenswijzigingen die plaatsvinden bij zowel Publisher als Abonnee en distribueert deze naar de andere Server. De samenvoegreplicatie vereist de ROWGUID kolom in de tabel Artikelen die betrokken zijn bij samenvoegreplicatie. Het gebruikt triggers om de gegevenswijzigingen vast te leggen tussen uitgever en abonnee. Het levert ook de wijzigingen op alle servers wanneer zowel de uitgever als de abonnee op het netwerk zijn aangesloten. Merge Replication gebruikt de Merge Agent om de gegevenswijzigingen te repliceren tussen Publisher en Abonnee.
  3. Snapshot-replicatie – Zoals de naam al aangeeft, is Snapshot Replication niet afhankelijk van transactielogboeken of triggers om de wijzigingen vast te leggen. Het maakt een momentopname van artikelen die betrokken zijn bij publicatie en past deze toe op de Abonnee met de records die beschikbaar zijn op het moment van de momentopname. De momentopnamereplicatie gebruikt de momentopnameagent om een ​​momentopname van de uitgever te maken en gebruikt de distributieagent om deze records op de abonnee toe te passen.

SQL Server Transactionele Replicatie

Transactiereplicatie heeft doorgaans de voorkeur in scenario's waarin de OLTP Publisher-database zware gegevens INSERT/UPDATE- en/of DELETE-activiteiten heeft.

Aangezien de Publisher-serverinstantie een enorme DISK IO heeft, kan het genereren van rapporten ernstige blokkeringen veroorzaken. Het kan ook de prestaties van de server beïnvloeden. Daarom is een andere server met bijna realtime gegevens goed voor het ontlasten van de rapportagevereisten.

Een van de fundamentele vereisten voor transactiereplicatie is dat de gerepliceerde tabellen een primaire sleutel beschikbaar moeten hebben.

We kunnen samenvatten hoe Transactionele Replicatie werkt. Bekijk het onderstaande Transactional Replication Architecture-diagram uit de officiële Microsoft-documentatie.

De publicatie wordt gemaakt in de Publisher-database die de lijst met artikelen bevat voor replicatie naar de Abonnee-database.

Transactiereplicatie wordt doorgaans geïnitialiseerd van uitgever naar distributeur via de momentopnameagent of volledige back-ups. De Snapshot Agent wordt ondersteund via de wizard Replicatieconfiguratie. De volledige back-up wordt ondersteund via TSQL-verklaringen om de transactiereplicatie te initialiseren.

De Log Reader Agent scant het transactielogboek van de Publisher-database op bijgehouden artikelen. Vervolgens kopieert het de gegevenswijzigingen van het transactielogboek naar de distributiedatabase.

De distributiedatabase kan in Publisher of Subscriber staan; het kan ook een andere onafhankelijke SQL Server-instantie zijn.

Let ook op de volgende dingen:

  • Log Reader Agent draait continu vanaf de Distributor Server om te scannen op nieuwe opdrachten die zijn gemarkeerd voor Replicatie. Als u echter niet continu wilt werken en in plaats daarvan volgens een schema wilt werken, kunnen we de Log Reader Agent SQL-taak wijzigen die wordt gemaakt.
  • Log Reader Agent haalt alle records die zijn gemarkeerd voor replicatie in batches op uit het transactielogboek en stuurt ze naar de distributiedatabase.
  • Log Reader Agent haalt alleen Toegezegde transacties op uit het Transactielogboek van Publisher Database. Dus langlopende query's op de Publisher-database kunnen rechtstreeks van invloed zijn op replicatie terwijl deze wacht tot de actieve transactie is voltooid.

De distributieagent haalt alle niet-gedistribueerde nieuwe opdrachten uit de distributiedatabase en past deze toe op de abonnementendatabase via een push- of pullmechanisme. Zoals eerder vermeld, als Push Subscription Distributor het eigendom overneemt om de wijzigingen van Distributiedatabase op Abonnee toe te passen, terwijl in Pull Subscription Subscriber-database het eigendom overneemt om de wijzigingen op te halen van Distributiedatabase naar Abonnee.

Zodra de records met succes zijn gedistribueerd vanuit de database voor distributie naar abonnees, worden ze gemarkeerd als gedistribueerd en gemarkeerd voor verwijdering uit de database voor distributie. Een van de onderhoudstaken voor sleutelreplicatie genaamd Distributie opschonen:de distributietaak wordt eens in de 10 minuten uitgevoerd om de gedistribueerde records uit de distributiedatabase te verwijderen om de grootte van de distributiedatabase onder controle te houden.

Met de gedetailleerde uitleg van concepten van replicatie en transactionele replicatie, kunnen we deze in handen krijgen door Replicatie te configureren voor AdventureWorks database en het verifiëren van replicatie voor elk theoretisch besproken onderdeel.

Transactiereplicatie stap voor stap configureren (via SSMS GUI)

De configuratie van de transactiereplicatie omvat 3 belangrijke stappen:

  1. Distributiedatabase configureren
  2. Publicatie maken
  3. Aanmaken van abonnement

Voordat u replicatie probeert te configureren, moet u ervoor zorgen dat replicatiecomponenten zijn geïnstalleerd als onderdeel van de installatie van SQL Server of dat u SQL Server-media gebruikt om replicatiecomponenten te installeren, aangezien deze nodig zijn voor de taak.

Maak in SSMS verbinding met de Publisher Database Instance en klik met de rechtermuisknop op Replicatie :

Distributie is momenteel niet geconfigureerd. Daarom hebben we de optie Distributie configureren. We kunnen de distributiedatabase configureren met behulp van de wizard Distributie configureren of via de wizard Publicatie maken.

Volg de onderstaande stappen om de distributiedatabase en publicatie te configureren:

Uitvouwen Replicatie en klik met de rechtermuisknop op Nieuwe publicatie .

Nieuwe publicatiewizard zal lanceren. Klik op Volgende om de Distributeur . te zien configuratie-opties.

Standaard kiest het de Publisher-server om de distributiedatabase te bewaren. Als u een externe distributiedatabase wilt gebruiken, kiest u de tweede optie. Klik op Volgende .

De volgende optie is voor het configureren van de Momentopnamemap . Wijzig het in de gewenste map. Anders wordt het standaard gemaakt op het pad van de SQL Server-installatiemap. Klik op Volgende .

Selecteer de Publicatiedatabase (hier is het AdventureWorks ) en klik op Volgende .

Kies het Publicatietype Transactionele replicatie . Klik op Volgende .

Kies Artikelen voor deze publicatie. Selecteer voor testdoeleinden alle Tabellen en Beelden :

Voordat u op Volgende clicking klikt , vouw tabellen nogmaals uit om enkele problemen te verifiëren.

Sommige tabellen zijn gemarkeerd met rode pictogrammen. Wanneer we op die tabellen klikken, zien we de waarschuwing dat een tabel niet kan worden gerepliceerd omdat deze geen primaire sleutel heeft, een van de cruciale vereisten voor transactionele replicatie. We zullen later meer in detail treden. Klik nu op Volgende .

Een pagina met Artikelproblemen gerelateerd aan afhankelijkheden verschijnen. Klik op Volgende .

De volgende optie is om Tabelrijen te filteren - aangezien we de basisreplicatie testen, kunnen we deze negeren. Klik op Volgende .

Snapshot-agent configureren – negeer en klik op Volgende .

Agent Instellingen – klik op Beveiligingsinstellingen om het account te configureren om de Snapshot-agent en Log Reader Agent eronder uit te voeren.

Wijzig vervolgens het Snapshot Agent-proces om te draaien onder SQL Server Agent Service Account.

Stel de Log Reader-agent in naar Verbinding maken met uitgever> Door zich voor te doen als het procesaccount . Klik op OK .

De Agent-beveiliging wordt bijgewerkt.

Daarom hebben we de Distributeur . geconfigureerd en alle elementen van de Publicatie zoals Artikelen , Momentopname-agent , Agent voor logboeklezer , en Agent Securities . We zijn bijna klaar met het maken van de publicatie via de wizard.

Als u meer wilt weten over TSQL-scripts die worden gebruikt om een ​​publicatie te maken, kunnen we de optie Een scriptbestand genereren om de publicatie te maken controleren. optie. Klik anders op Volgende .

Aangezien ik ervoor heb gekozen om het bestand op te slaan, stelt de wizard me in staat om het Scriptbestandspad in te stellen en naam . Geef deze details op en klik op Volgende .

De wizard vraagt ​​uiteindelijk om de Publicatienaam , ik heb het AdventureWorks_pub genoemd met de databasenaam en trefwoorden om het aan te geven als een publicatie voor eenvoudigere identificatie.

Controleer alle gegevens in de Samenvatting pagina en klik op Voltooien .

De wizard geeft de voortgang weer in Publicatie maken . Wanneer het voltooid is, zien we de bevestiging. Klik op Sluiten .

Om de succesvolle creatie van de Distributeur te verifiëren (Distributiedatabase), breid de systeemdatabases uit:

Om de succesvolle creatie van Publicatie te verifiëren , vouw Lokale publicatie uit :

We hebben de distributiedatabase geconfigureerd en de publicatiedatabase op de AdventureWorks-database gemaakt met succes. Nu kunnen we doorgaan met het Abonnement creatie

Klik met de rechtermuisknop op de nieuwe Publicatie we hebben zojuist Nieuwe abonnementen gemaakt en geselecteerd :

De Wizard Nieuwe Abonnementen zal verschijnen. Om het proces te starten, klikt u op Volgende .

De Publicatie pagina vraagt ​​om ervoor te zorgen dat zowel de Publicatie en Uitgever databases zijn geselecteerd. Klik op Volgende .

Stel de Distributieagent in om ofwel Duwen of Trek Abonnement. We gaan de Publisher Server . gebruiken als de Abonnee, en dat type heeft geen enkele impact. Daarom laten we de standaard Push Abonnement. Klik op Volgende .

Selecteer de Abonnees (databank). Ik selecteer AdventureWorks_REPL hersteld vanaf dezelfde AdventureWorks Database-back-up. Klik op Volgende .

Stel de agentbeveiliging in :

Aangezien ik alles binnen één server ga doen, gebruik ik het Agent-serviceaccount .

Het volgende venster toont de Distribution Agent Security waarden al geconfigureerd. Klik op Volgende .

Synchronisatieschema - laat het op de standaard. Klik op Volgende .

Abonnementen initialiseren – laat het met de standaardwaarden. Klik op Volgende .

Nadat u alle benodigde details heeft verstrekt, kunt u het proces voor het maken van het abonnement voltooien. Controleer het Script-bestand genereren... optie om de scripts later te bestuderen en klik op Volgende .

Geef het pad op om de bestanden op te slaan, klik op Volgende .

Bekijk het overzicht en controleer alle geconfigureerde waarden. Klik na verificatie op Voltooien .

Het aanmaken van een abonnement is voltooid. Klik op Sluiten .

Nu kunnen we het Abonnement . zien weergegeven onder onze Publicatie .

Configureer de Snapshot Agent

Onze volgende stap is om te werken aan de Momentopname Agent om de eerste gegevens te verzenden van Uitgever naar Abonnee .

Voordat we erin stappen, moeten we de Replicatiemonitor . opmerken . Deze essentiële tool is beschikbaar in SSMS om de replicatiestatus op verschillende niveaus, serverniveau, uitgeversdatabaseniveau, abonnementsniveau en replicatieagenten, te bekijken.

Klik met de rechtermuisknop op Replicatie /Lokale publicatie /Lokaal abonnement /Publicatie of het Abonnement die we hebben gemaakt om de Replicatiemonitor te lanceren zoals hieronder weergegeven:

In de Replicatiemonitor , vouw Publisher Server (RRJ)> Publicatie ([AdventureWorks]:AdventureWorks_pub) uit om de abonnementsdetails weer te geven. Klik met de rechtermuisknop op Abonnement en selecteer Details bekijken .

Zoals we kunnen zien, is de informatie over de Initiële momentopname voor onze publicatie AdventureWorks_pub is nog niet beschikbaar. We moeten de taak Snapshot-agent uitvoeren om de initiële gegevens naar de abonneedatabase te verzenden .

Houd dit venster open om de voortgang van Snapshot te zien na het starten van de Snapshot Agent-taak .

Klik met de rechtermuisknop op Publicatie > Status momentopname-agent bekijken :

De agent is nog nooit uitgevoerd bericht geeft aan dat we de Snapshot Agent nooit hebben uitgevoerd. Klik op Start .

Terwijl de Snapshot Agent wordt uitgevoerd, kunt u de voortgang bekijken:

Wanneer alle snapshots zijn gemaakt, wordt het bevestigingsbericht weergegeven:

We kunnen de Snapshot-bestanden zien die nieuw zijn gemaakt in de Snapshot-map waarvoor we eerder het pad hebben opgegeven.

Nadat alle snapshots zijn toegepast door de Distributieagent naar de Abonneedatabase , wordt de onderstaande status weergegeven in de geopende Replicatiemonitor venster:

Gefeliciteerd! We hebben Transactionele Replicatie met succes geconfigureerd met Snapshot Agent.

Opmerking :als we een enorme uitgeversdatabase hebben, kan het maken van snapshots veel tijd kosten. Het wordt daarom aanbevolen om de volledige back-up van de Publisher-database te gebruiken in plaats van de Snapshot Agent uit te voeren - we zullen dit probleem in volgende artikelen behandelen.

Replicatiecomponenten verifiëren

Elke replicatiecomponent kan worden geverifieerd door zowel SSMS GUI als TSQL-query's. We zullen het in andere artikelen bespreken en hier zullen we snel uitleggen hoe je de eigenschappen van de onderstaande componenten kunt bekijken.

Uitgever

Klik in SSMS met de rechtermuisknop op Replicatie > Eigenschappen voor uitgevers > Publicatiedatabases :

Om details over de Uitgever te bekijken , voer de onderstaande query's uit op de distributiedatabase.

USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO

Abonnee

Abonneegegevens kunnen worden verkregen met de onderstaande vraag in SSMS.

USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info

Distributeur

Klik in SSMS met de rechtermuisknop op Replicatie > Distributeur Eigenschappen :

Klik op Uitgevers om de lijst weer te geven van alle uitgevers die deze distributiedatabase gebruiken.

In SSMS kunnen we de onderstaande query uitvoeren om dezelfde details te verkrijgen.

USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO	

Artikelen

Klik met de rechtermuisknop op Publicatie > Publicatie-eigenschappen > Artikelen . U ziet de lijst met alle beschikbare artikelen. De eigenschappen van individuele artikelen kunnen worden gewijzigd door te klikken op Artikeleigenschappen ook.

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

Publicatie

Klik met de rechtermuisknop op Publicatie > Eigenschappen :

In SSMS kunnen we de onderstaande query uitvoeren om de Publicatie-eigenschappen te bekijken :

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

Abonnement

Klik met de rechtermuisknop op Abonnement > Abonnementseigenschappen :

In SSMS kunnen we het onderstaande script uitvoeren om de abonnementsinformatie te krijgen:

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

Replicatieagenten

Onder SQL Server Agent-taken , kunnen we de specifieke Vacatures . vinden gemaakt voor alle replicatieagenten:

In SSMS kunnen we de query uitvoeren om erachter te komen welke taak de benodigde Log Reader Agent Job is , Momentopname agent baan , en Vacatures voor distributieagenten . Bovendien kunnen we de taak Distributieagent opschonen . zien en verschillende andere taken met betrekking tot replicatie die zijn gemaakt terwijl we de publicatie en abonnementen intern aan het instellen waren.

Hoe Log Reader Agent werkt

De Log Reader-agent leest alle vastgelegde gegevens uit de transactielogboeken van de Publisher-database en pusht deze naar de Distributor-database. Hoewel Microsoft geen officiële manier biedt om transactielogboeken te lezen, zijn er weinig ongedocumenteerde functies zoals fn_dblog() en fn_dump_dblog() die de gegevens uit logbestanden kan lezen. Deze functies zijn echter niet gedocumenteerd en worden niet gedekt door Microsoft-ondersteuning. We zullen ze dus niet verder onderzoeken.

Hoe Distribution Agent de gegevenswijzigingen aan de abonneedatabase levert

Zodra de gegevens naar de distributiedatabase zijn geschreven, kunnen we lezen hoe die gegevens in distributietabellen zijn opgeslagen. Daarvoor passen we de sp_browsereplcmds . toe procedure – het haalt de records op over de MSrepl_commands en MSrepl_transactions tabellen.

Laten we voor leerdoeleinden een tabel nemen met 3 kolommen met de naam Person.ContactType :

Het aangemaakte Abonnement maakt 3 procedures voor elk artikel dat deel uitmaakt van Publicatie in Abonneedatabase met de onderstaande naamgevingsconventies:

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

Voor het Person.ContactType Table-artikel kunnen we de onderstaande procedures zien die zijn gemaakt in de abonneedatabase:

  • dbo.sp_MSins_PersonContactType INSERT nieuwe records vastgelegd uit de transactielogboeken van de Publisher-database en vervolgens gepropageerd naar de distributiedatabase.
  • dbo.sp_MSupd_PersonContactType UPDATE wijzigingen vastgelegd uit de Transactielogboeken van de Publisher-database en vervolgens doorgegeven aan de distributiedatabase.
  • dbo.sp_MSdel_PersonContactType VERWIJDEREN 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 tafel.

Executing the SELECT statement on the table yields 20 records:

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

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

Conclusie

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. Gastgebruiker wachtwoord in 11i/R12

  2. MySQL, MariaDB, Percona Server, MongoDB of PostgreSQL implementeren - gemakkelijk gemaakt met ClusterControl

  3. Hoe kan ik een ddl-script genereren (of krijgen) op een bestaande tabel in Oracle? Ik moet ze opnieuw maken in Hive

  4. Verbind ODBC-toepassingen op Windows met QuickBooks Online