Interna der SQL Server-Transaktionsreplikation

Die SQL Server-Transaktionsreplikation ist eine der am häufigsten verwendeten Replikationstechniken zum Freigeben, Kopieren oder Verteilen von Daten an mehrere Ziele. In diesem Artikel werden wir die Replikation und verschiedene Replikationstypen besprechen und besonderes Augenmerk auf die Arbeit der Transaktionsreplikation legen.

Was ist SQL-Transaktionsreplikation?

Replikation ist die SQL Server-Technologie zum Kopieren oder Verteilen von Daten von einer Datenbank in eine andere, wobei die Datenkonsistenz beibehalten wird.

Die Replikation kann verwendet werden, um Daten von einer Datenbank in eine andere zu übertragen

auf derselben Instanz oder einer anderen Instanz auf demselben Server;
oder über Server an einem einzelnen Standort oder mehreren Standorten.

Zuerst sollten wir die Replikationsarchitektur durchgehen und die Replikationsterminologien verstehen.

SQL Server-Replikationsarchitektur und Terminologien

Der Herausgeber ist die Quelldatenbankinstanz, die die Datenänderungen veröffentlicht, die an eine andere Datenbank verteilt werden können. Daten von einem einzelnen Publisher kann an einen einzelnen Abonnenten gesendet werden oder mehrere Abonnenten .
Abonnent ist die Zieldatenbankinstanz, in der wir die von der Publisher-Datenbank erfassten Datenänderungen verteilen. Der Abonnent kann entweder eine Publisher-Instanz oder eine andere Instanz im Publisher-Server/einem anderen Server am selben Standort/entfernten Standort sein. Bevor die Datenänderungen an die Instanz der Abonnentendatenbank verteilt werden, werden diese Daten im Verteiler gespeichert .
Der Vertriebspartner ist eine Datenbank, die Änderungsprotokolle speichert, die von Publisher-Datenbanken erfasst wurden. Wenn ein Server als Verteiler aktiviert wird, erstellt er eine Systemdatenbank mit dem Namen Verteilungsdatenbank .

Durch den Standort der Vertriebsdatenbanken können sie entweder als lokale oder entfernte Vertriebspartner klassifiziert werden.

– Lokaler Vertriebspartner ist eine Verteilungsdatenbank, die sich auf der Publisher-Datenbankinstanz befindet.
– Remote-Distributor ist eine Verteilungsdatenbank, die sich entweder in der Abonnentendatenbankinstanz oder in jeder anderen SQL Server-Instanz außer der Herausgeberdatenbankinstanz befindet.

Der entscheidende Faktor ist, wo die Verteilungsdatenbank auf der Verlegerinstanz (einer anderen Instanz) platziert wird. es hängt von den verfügbaren Serverressourcen ab, um die Datenverteilungslast zu bewältigen.

Je nachdem, wie die Daten von der Verteilungsdatenbank an die Abonnenteninstanz gesendet werden, können sie entweder als Push klassifiziert werden oder Pull-Abonnements .

– Push-Abonnement bedeutet, dass die Verteilungsdatenbank die Verantwortung dafür übernimmt, die Daten per Push an die Abonnentendatenbankinstanz zu übertragen.
– Pull-Abonnement bedeutet, dass die Instanz der Abonnentendatenbank dafür verantwortlich ist, die verfügbaren Daten aus der Verteilungsdatenbank abzurufen und auf die Abonnentendatenbank anzuwenden.

Artikel sind die grundlegende Einheit der Replikation. Es zeigt alle Datenänderungen an diesem Datenbankobjekt oder Artikel an, die vom Verleger zum Abonnenten repliziert werden. Der Artikel kann eine Tabelle, Ansicht, indizierte Ansicht, gespeicherte Prozedur oder die benutzerdefinierte Funktion sein.
Veröffentlichungen sind eine Sammlung von einem oder mehreren Artikeln aus der Datenbank in Publisher.
Abonnement legt fest, welche Veröffentlichung empfangen wird. Außerdem bestimmt es, aus welcher Veröffentlichung und nach welchem Zeitplan die Daten repliziert werden. Das Abonnement kann entweder Push oder Pull sein (von der Veröffentlichung zum Abonnement).
Replikationsagenten sind eigenständige Programme, die für die Nachverfolgung von Änderungen und die Verteilung von Daten über den Publisher an Distributor und Subscriber verantwortlich sind. Alle Replikations-Agents werden als Jobs unter dem SQL Server-Agent ausgeführt. Somit kann es über SSMS unter SQL Server Agent Jobs oder Replication Monitor verwaltet werden. Die folgenden Typen von Replication Agents sind verfügbar:
Snapshot-Agent – Wird von fast allen Replikationstypen verwendet. Der Snapshot-Agent wird vom Server ausgeführt, auf dem sich die Verteilungsdatenbank befindet. Es bereitet das Schema und die Anfangsdaten aller Artikel vor, die in einer Veröffentlichung auf einem Verlag enthalten sind. Außerdem erstellt es die Snapshot-Dateien in einem Snapshot-Ordner und zeichnet Synchronisierungsdetails in der Distributionsdatenbank auf.
Protokolllese-Agent – Wird von der Transaktionsreplikation verwendet. Das Ziel besteht darin, die Datenänderungen von Artikeln, die für die Replikation aktiviert sind, aus den Transaktionsprotokollen der Herausgeberdatenbank zu lesen und in der Verteilungsdatenbank zu speichern. der Protokollleseagent wird vom Verteilerserver ausgeführt.
Vertriebsagent – Wird von Transaktions- und Snapshot-Replikation verwendet. Es wendet die anfänglichen Snapshot-Dateien und inkrementellen oder verfügbaren ausstehenden Transaktionen aus der Verteilungsdatenbank auf die Abonnentendatenbank an. Der Verteilungsagent wird vom Verteilerserver für Push-Abonnements und vom Abonnentenserver für Pull-Abonnements ausgeführt.
Merge-Agent – Wird nur von der Mergereplikation verwendet. Es wendet die anfänglichen Snapshot-Dateien und den Abgleich von differenziellen oder inkrementellen Änderungen auf dem Verleger oder Abonnenten an. Der Merge-Agent wird auf dem Verteilerserver für die Push-Replikation und vom Abonnentenserver für Pull-Abonnements ausgeführt.
Warteschlangenlese-Agent – Der Warteschlangenleseagent wird von der Transaktionsreplikation mit der Option für Aktualisierungen in der Warteschlange verwendet. Es verschiebt Änderungen vom Abonnenten zum Herausgeber. Der Warteschlangenleseagent wird vom Verteilerserver ausgeführt.
Replikationswartungsjobs – Wie bereits erläutert, sind alle Replication Agents eigenständige Programme, die während der Konfiguration der Replikation eingerichtet werden. Sie werden als Jobs unter SQL Server-Agent-Jobs ausgeführt. Einige wichtige Jobs, die erwähnt werden müssen, sind Distribution Clean Up:Distribution, Agent History Clean Up:Distribution und Expired Subscription Clean Up.

Replikationsarten im SQL-Server

Nun, da wir die Terminologie kennen, lassen Sie uns in die Arten der Replikation eintauchen.

Transaktionsreplikation . Wie der Name schon sagt, wird jede Transaktion oder Datenänderung innerhalb des Transaktionsbereichs auf dem Publisher nahezu in Echtzeit mit geringfügigen Verzögerungen je nach Netzwerkbandbreite und Serverressourcen an den Abonnenten gesendet. Die Transaktionsreplikation verwendet den Protokolllese-Agent, um die Datenänderungen aus den Transaktionsprotokollen der Herausgeberdatenbank zu lesen. Es verwendet auch den Verteilungs-Agent, um Änderungen auf den Abonnenten anzuwenden. Gelegentlich kann es Snapshot Agent verwenden, um anfängliche Snapshot-Daten aller replizierten Artikel zu nehmen. Die Transaktionsreplikationsveröffentlichung kann unter die folgenden Kategorien fallen:
- Standardtransaktionsreplikation – Der Abonnent ist aus Sicht der Transaktionsreplikation eine schreibgeschützte Datenbank. Alle Änderungen, die von irgendjemandem an der Abonnentendatenbank vorgenommen werden, werden nicht nachverfolgt und in der Herausgeberdatenbank aktualisiert. Die Standard-Transaktionsreplikation wird oft als Transaktionsreplikation bezeichnet.
- Transaktionsreplikation mit aktualisierbaren Abonnements ist eine Erweiterung der Standard-Transaktionsreplikation, die die Datenänderungen verfolgt, die auf Abonnements stattfinden. Immer wenn Datenänderungen an einem aktualisierbaren Abonnement initiiert werden, werden sie zuerst an den Herausgeber und dann an andere Abonnenten weitergegeben.
- Peer-to-Peer-Replikation ist eine Erweiterung der Standard-Transaktionsreplikation. Es überträgt transaktionskonsistente Änderungen nahezu in Echtzeit über mehrere Serverinstanzen hinweg.
- Bidirektionale Replikation ist eine Erweiterung der Standard-Transaktionsreplikation, die es zwei Servern (auf nur 2 Server begrenzt und daher bidirektional genannt) ermöglicht, die Datenänderungen untereinander auszutauschen, wobei jeder Server als Herausgeber (um Änderungen an einen anderen Server zu senden) oder als Abonnent fungiert (um Änderungen von einem anderen Server zu erhalten).
Mergereplikation – Unterstützt die Erfassung von Datenänderungen, die sowohl auf dem Herausgeber als auch auf dem Abonnenten stattfinden, und verteilt sie an den anderen Server. Die Mergereplikation erfordert die ROWGUID Spalte in der Tabelle Artikel, die an der Mergereplikation beteiligt sind. Es verwendet Trigger, um die Datenänderungen über Herausgeber und Abonnenten hinweg zu erfassen. Außerdem werden die Änderungen serverübergreifend übermittelt, wenn sowohl der Verleger als auch der Abonnent mit dem Netzwerk verbunden sind. Die Mergereplikation verwendet den Merge-Agent, um die Datenänderungen zwischen Verleger und Abonnent zu replizieren.
Snapshot-Replikation – Wie der Name schon sagt, verlässt sich Snapshot Replication weder auf Transaktionsprotokolle noch auf Trigger, um die Änderungen zu erfassen. Es erstellt eine Momentaufnahme der an der Veröffentlichung beteiligten Artikel und wendet sie mit den zum Zeitpunkt der Momentaufnahme verfügbaren Aufzeichnungen auf den Abonnenten an. Die Snapshot-Replikation verwendet den Snapshot-Agent, um einen Snapshot des Verlegers zu erstellen, und verwendet den Verteilungs-Agent, um diese Datensätze auf den Abonnenten anzuwenden.

SQL Server-Transaktionsreplikation

Die Transaktionsreplikation wird in der Regel in Szenarien bevorzugt, in denen die OLTP-Publisher-Datenbank umfangreiche Daten-INSERT/UPDATE- und/oder DELETE-Aktivitäten aufweist.

Da auf der Publisher-Serverinstanz große DISK-E/A stattfinden, kann das Generieren von Berichten schwerwiegende Blockierungen verursachen. Es kann sich auch auf die Serverleistung auswirken. Daher ist ein weiterer Server mit nahezu Echtzeitdaten gut geeignet, um die Anforderungen an die Berichterstellung zu entlasten.

Eine der grundlegenden Anforderungen für die Transaktionsreplikation ist, dass für die replizierten Tabellen ein Primärschlüssel verfügbar sein sollte.

Wir können zusammenfassen, wie die Transaktionsreplikation funktioniert. Sehen Sie sich das folgende Diagramm der Transaktionsreplikationsarchitektur aus der offiziellen Microsoft-Dokumentation an.

Die Veröffentlichung wird in der Herausgeberdatenbank erstellt, die die Liste der Artikel zum Replizieren in die Abonnentendatenbank umfasst.

Die Transaktionsreplikation wird normalerweise vom Herausgeber zum Verteiler über den Snapshot-Agent oder vollständige Sicherungen initialisiert. Der Snapshot-Agent wird über den Replikationskonfigurationsassistenten unterstützt. Die vollständige Sicherung wird über TSQL-Anweisungen unterstützt, um die Transaktionsreplikation zu initialisieren.

Der Protokollleseagent durchsucht das Transaktionsprotokoll der Herausgeberdatenbank nach nachverfolgten Artikeln. Dann kopiert es die Datenänderungen aus dem Transaktionsprotokoll in die Verteilungsdatenbank.

Die Verteilungsdatenbank kann sich entweder im Verleger oder im Abonnenten befinden; es kann auch eine andere unabhängige SQL Server-Instanz sein.

Beachten Sie auch die folgenden Dinge:

Der Protokollleseagent wird kontinuierlich vom Verteilerserver ausgeführt, um nach neuen Befehlen zu suchen, die für die Replikation markiert sind. Wenn Sie jedoch nicht kontinuierlich und stattdessen nach einem Zeitplan ausführen möchten, können wir den SQL-Job des Protokollleseagenten ändern, der erstellt wird.
Der Protokollleseagent nimmt alle für die Replikation markierten Datensätze aus dem Transaktionsprotokoll in Stapeln auf und sendet sie an die Verteilungsdatenbank.
Der Protokollleseagent nimmt nur festgeschriebene Transaktionen aus dem Transaktionsprotokoll der Herausgeberdatenbank auf. Daher können sich lang andauernde Abfragen in der Publisher-Datenbank direkt auf die Replikation auswirken, da sie auf den Abschluss der aktiven Transaktion wartet.

Der Verteilungsagent nimmt alle nicht verteilten neuen Befehle aus der Verteilungsdatenbank auf und wendet sie entweder über einen Push- oder einen Pull-Mechanismus auf die Abonnementdatenbank an. Wie bereits erwähnt, übernimmt der Push-Abonnement-Distributor die Eigentümerschaft, um die Änderungen von der Distributionsdatenbank auf den Abonnenten anzuwenden, während die Pull-Abonnement-Abonnentendatenbank die Eigentümerschaft übernimmt, um die Änderungen von der Distributionsdatenbank auf den Abonnenten abzurufen.

Sobald die Datensätze erfolgreich von der Datenbank „Verteilung an Abonnenten“ verteilt wurden, werden sie als „Verteilt“ markiert und zum Löschen aus der Datenbank „Verteilung“ markiert. Einer der Schlüsselreplikations-Wartungsjobs namens Distribution Clean Up:Der Verteilungsjob wird einmal alle 10 Minuten ausgeführt, um die verteilten Datensätze aus der Verteilungsdatenbank zu löschen und die Größe der Verteilungsdatenbank unter Kontrolle zu halten.

Mit der detaillierten Erläuterung der Konzepte der Replikation und Transaktionsreplikation können wir es in die Hände bekommen, indem wir die Replikation für AdventureWorks konfigurieren Datenbank und Überprüfung der Replikation für jede theoretisch besprochene Komponente.

Transaktionsreplikation Schritt für Schritt konfigurieren (über die SSMS-GUI)

Die Konfiguration der Transaktionsreplikation umfasst drei Hauptschritte:

Verteilungsdatenbank konfigurieren
Veröffentlichungserstellung
Abonnementerstellung

Bevor Sie versuchen, die Replikation zu konfigurieren, vergewissern Sie sich, dass die Replikationskomponenten als Teil der SQL Server-Installation installiert sind, oder verwenden Sie SQL Server-Medien, um die Replikationskomponenten zu installieren, da sie für die Aufgabe erforderlich sind.

Stellen Sie in SSMS eine Verbindung zur Publisher-Datenbankinstanz her und klicken Sie mit der rechten Maustaste auf Replikation :

Die Verteilung ist derzeit nicht konfiguriert. Daher haben wir die Option Verteilung konfigurieren. Wir können die Verteilungsdatenbank entweder mit dem Assistenten zum Konfigurieren der Verteilung oder mit dem Assistenten zum Erstellen von Veröffentlichungen konfigurieren.

Führen Sie die folgenden Schritte aus, um die Verteilungsdatenbank und die Veröffentlichung zu konfigurieren:

Erweitern Replikation und klicken Sie mit der rechten Maustaste auf Neue Veröffentlichung .

Assistent für neue Veröffentlichungen wird starten. Klicken Sie auf Weiter um den Distributor anzuzeigen Konfigurationsoptionen.

Standardmäßig wählt es den Verlegerserver zum Speichern der Verteilungsdatenbank aus. Wenn Sie eine entfernte Verteilungsdatenbank verwenden möchten, wählen Sie die zweite Option. Klicken Sie auf Weiter .

Die nächste Option ist die Konfiguration des Snapshot-Ordners . Ändern Sie es in den erforderlichen Ordner. Andernfalls wird es standardmäßig im Pfad des SQL Server-Installationsordners erstellt. Klicken Sie auf Weiter .

Wählen Sie die Publikationsdatenbank aus (hier ist es AdventureWorks ) und klicken Sie auf Weiter .

Wählen Sie den Veröffentlichungstyp – Transaktionsreplikation . Klicken Sie auf Weiter .

Wählen Sie Artikel für diese Veröffentlichung. Wählen Sie zu Testzwecken alle Tabellen aus und Aufrufe :

Bevor Sie auf Weiter klicken , erweitern Sie die Tabellen noch einmal, um einige Probleme zu überprüfen.

Einige Tabellen sind durch rote Symbole gekennzeichnet. Wenn wir auf diese Tabellen klicken, sehen wir die Warnung, dass eine Tabelle nicht repliziert werden kann, weil sie keinen Primärschlüssel hat, eine der entscheidenden Voraussetzungen für die Transaktionsreplikation. Wir werden später noch genauer darauf eingehen. Klicken Sie nun auf Weiter .

Eine Seite mit Artikelproblemen im Zusammenhang mit Abhängigkeiten erscheinen. Klicken Sie auf Weiter .

Die nächste Option ist Tabellenzeilen filtern – Da wir die grundlegende Replikation testen, können wir sie ignorieren. Klicken Sie auf Weiter .

Snapshot-Agent konfigurieren – ignorieren und auf Weiter klicken .

Agent Einstellungen – Klicken Sie auf Sicherheitseinstellungen um das Konto so zu konfigurieren, dass der Snapshot-Agent und der Protokolllese-Agent darunter ausgeführt werden.

Ändern Sie dann den Snapshot-Agent-Prozess unter dem SQL Server Agent-Dienstkonto auszuführen.

Legen Sie den Protokolllese-Agent fest zum Verbinden mit dem Herausgeber> durch Imitieren des Prozesskontos . Klicken Sie auf OK .

Die Agentensicherheit wird aktualisiert.

Damit haben wir den Distributor konfiguriert und alle Elemente der Publikation wie Artikel , Snapshot-Agent , Protokolllese-Agent , und Agent Securities . Wir haben die Veröffentlichungserstellung mit dem Assistenten fast abgeschlossen.

Wenn Sie sich weiter mit TSQL-Skripten befassen müssen, die zum Erstellen von Veröffentlichungen verwendet werden, können wir den Abschnitt Generieren einer Skriptdatei zum Erstellen der Veröffentlichung überprüfen Möglichkeit. Klicken Sie andernfalls auf Weiter .

Da ich mich entschieden habe, die Datei zu speichern, erlaubt mir der Assistent, den Skriptdateipfad festzulegen und Name . Geben Sie diese Details ein und klicken Sie auf Weiter .

Der Assistent fragt schließlich nach dem Publikationsnamen , ich habe es AdventureWorks_pub genannt mit dem Namen der Datenbank und Schlüsselwörtern, um sie zur leichteren Identifizierung als Veröffentlichung zu kennzeichnen.

Überprüfen Sie alle in der Zusammenfassung angegebenen Daten Seite und klicken Sie auf Fertig stellen .

Der Assistent zeigt den Fortschritt in Veröffentlichung erstellen an . Wenn es fertig ist, sehen wir die Bestätigung. Klicken Sie auf Schließen .

Um die erfolgreiche Erstellung des Distributors zu überprüfen (Verteilungsdatenbank), erweitern Sie die Systemdatenbanken:

Um die erfolgreiche Erstellung der Veröffentlichung zu überprüfen , maximieren Sie Lokale Veröffentlichung :

Wir haben die Verteilungsdatenbank konfiguriert und die Veröffentlichungsdatenbank auf der AdventureWorks-Datenbank erstellt erfolgreich. Jetzt können wir mit dem Abonnement fortfahren Erstellung

Klicken Sie mit der rechten Maustaste auf die neue Publikation wir gerade erstellt haben und Neue Abonnements auswählen :

Der Assistent für neue Abonnements wird auftauchen. Um den Vorgang zu starten, klicken Sie auf Weiter .

Die Publikation Seite bittet sicherzustellen, dass sowohl die Veröffentlichung und Herausgeber Datenbanken ausgewählt sind. Klicken Sie auf Weiter .

Legen Sie den Verteilungsagenten fest entweder Push oder Ziehen Abonnement. Wir werden den Publisher Server verwenden als Abonnent, und dieser Typ hat keine Auswirkungen. Daher belassen wir die Standardeinstellung Push Abonnement. Klicken Sie auf Weiter .

Wählen Sie die Abonnenten aus (Datenbank). Ich wähle AdventureWorks_REPL aus aus derselben AdventureWorks-Datenbanksicherung wiederhergestellt. Klicken Sie auf Weiter .

Legen Sie die Agent-Sicherheit fest :

Da ich alles auf einem einzigen Server erledigen werde, verwende ich das Agent-Dienstkonto .

Das nächste Fenster zeigt die Distribution Agent Security Werte bereits konfiguriert. Klicken Sie auf Weiter .

Synchronisierungszeitplan – belassen Sie es auf der Standardeinstellung. Klicken Sie auf Weiter .

Abonnements initialisieren – Belassen Sie es bei den Standardwerten. Klicken Sie auf Weiter .

Nachdem Sie alle erforderlichen Details angegeben haben, können Sie den Vorgang zum Erstellen des Abonnements abschließen. Überprüfen Sie die Skriptdatei erstellen… Option, um die Skripte später zu studieren, und klicken Sie auf Weiter .

Geben Sie den Pfad zum Speichern der Dateien an und klicken Sie auf Weiter .

Schauen Sie sich die Zusammenfassung an und überprüfen Sie alle konfigurierten Werte. Klicken Sie nach der Bestätigung auf Fertig stellen .

Die Abonnementerstellung ist abgeschlossen. Klicken Sie auf Schließen .

Jetzt können wir das Abonnement sehen unter unserer Veröffentlichung angezeigt .

Konfigurieren Sie den Snapshot-Agent

Unser nächster Schritt ist die Arbeit am Snapshot Agent um die Anfangsdaten vom Publisher zu senden an Abonnent .

Bevor wir darauf eingehen, müssen wir den Replication Monitor beachten . Dieses wichtige Tool ist in SSMS verfügbar, um den Replikationsstatus auf verschiedenen Ebenen anzuzeigen, Serverebene, Herausgeberdatenbankebene, Abonnementebene und Ebene der Replikations-Agents.

Klicken Sie mit der rechten Maustaste auf Replikation /Lokale Veröffentlichung /Lokales Abonnement /Veröffentlichung oder das Abonnement wir erstellt haben, um den Replication Monitor zu starten wie unten gezeigt:

Im Replikationsmonitor , erweitern Sie Publisher Server (RRJ)> Veröffentlichung ([AdventureWorks]:AdventureWorks_pub) um die Abonnementdetails anzuzeigen. Klicken Sie mit der rechten Maustaste auf Abonnement und wählen Sie Details anzeigen aus .

Wie wir sehen können, sind die Informationen zum Ersten Snapshot für unsere Publikation AdventureWorks_pub ist noch nicht verfügbar. Wir müssen den Snapshot-Agent-Job ausführen, um Anfangsdaten an die Abonnentendatenbank zu senden .

Lassen Sie dieses Fenster geöffnet, um den Fortschritt von Snapshot nach dem Start des Snapshot-Agent-Jobs zu sehen .

Klicken Sie mit der rechten Maustaste auf Veröffentlichung > Snapshot-Agent-Status anzeigen :

Der Agent wurde noch nie ausgeführt besagt, dass wir den Snapshot-Agent noch nie ausgeführt haben. Klicken Sie auf Starten .

Während der Snapshot-Agent ausgeführt wird, können Sie den Fortschritt beobachten:

Wenn alle Snapshots erstellt sind, wird die Bestätigungsmeldung ausgegeben:

Wir können die neu erstellten Snapshot-Dateien im Snapshot-Ordner sehen, für den wir zuvor den Pfad angegeben haben.

Nachdem alle Snapshots vom Distribution Agent angewendet wurden zur Abonnentendatenbank , wird der folgende Status im geöffneten Replication Monitor angezeigt Fenster:

Herzlichen Glückwunsch! Wir haben die Transaktionsreplikation erfolgreich mit dem Snapshot-Agent konfiguriert.

Hinweis :Wenn wir eine riesige Publisher-Datenbank haben, kann das Erstellen eines Snapshots viel Zeit in Anspruch nehmen. Daher wird empfohlen, die vollständige Sicherung der Publisher-Datenbank zu verwenden, anstatt den Snapshot-Agent auszuführen – wir werden dieses Problem in späteren Artikeln behandeln.

Replikationskomponenten überprüfen

Alle Replikationskomponenten können sowohl durch SSMS-GUI- als auch durch TSQL-Abfragen überprüft werden. Wir werden es in weiteren Artikeln besprechen, und hier erklären wir schnell, wie Sie die Eigenschaften der folgenden Komponenten anzeigen können.

Herausgeber

Klicken Sie in SSMS mit der rechten Maustaste auf Replikation > Publisher-Eigenschaften > Publikationsdatenbanken :

Zum Anzeigen von Details über den Herausgeber , führen Sie die folgenden Abfragen für die Verteilungsdatenbank aus.

USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO

Abonnent

Abonnenteninformationen können mit der folgenden Abfrage in SSMS abgerufen werden.

USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info

Händler

Klicken Sie in SSMS mit der rechten Maustaste auf Replikation > Händler Eigenschaften :

Klicken Sie auf Publisher um die Liste aller Publisher anzuzeigen, die diese Distributionsdatenbank verwenden.

In SSMS können wir die folgende Abfrage ausführen, um dieselben Details zu erhalten.

USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO

Artikel

Klicken Sie mit der rechten Maustaste auf Veröffentlichung > Publikationseigenschaften > Artikel . Sie sehen die Liste aller verfügbaren Artikel. Die Eigenschaften einzelner Artikel können geändert werden, indem Sie auf Artikeleigenschaften klicken auch.

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

Veröffentlichung

Klicken Sie mit der rechten Maustaste auf Veröffentlichung > Eigenschaften :

In SSMS können wir die folgende Abfrage ausführen, um die Veröffentlichungseigenschaften anzuzeigen :

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

Abonnement

Klicken Sie mit der rechten Maustaste auf Abonnement > Abonnementeigenschaften :

In SSMS können wir das folgende Skript ausführen, um die Abonnementinformationen abzurufen:

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

Replikationsagenten

Unter SQL Server Agent-Jobs , können wir die spezifischen Jobs finden erstellt für alle Replication Agents:

In SSMS können wir die Abfrage ausführen, um herauszufinden, welcher Job der notwendige Log Reader Agent Job ist , Snapshot-Agent-Auftrag , und Verteilungsagentenjobs . Außerdem können wir den Job Distribution Agent Cleanup sehen und mehrere andere Jobs im Zusammenhang mit der Replikation, die erstellt wurden, während wir intern Veröffentlichungen und Abonnements einrichteten.

Funktionsweise des Protokolllese-Agents

Der Protokolllese-Agent liest alle festgeschriebenen Daten aus den Transaktionsprotokollen der Verlegerdatenbank und überträgt sie per Push an die Verteilerdatenbank. Auch wenn Microsoft keine offizielle Methode zum Lesen von Transaktionsprotokollen anbietet, gibt es einige undokumentierte Funktionen wie fn_dblog() und fn_dump_dblog() die die Daten aus Protokolldateien lesen können. Diese Funktionen sind jedoch nicht dokumentiert und werden nicht vom Microsoft-Support abgedeckt. Daher werden wir sie nicht weiter untersuchen.

Wie der Verteilungs-Agent die Datenänderungen an die Abonnentendatenbank übermittelt

Sobald die Daten in die Verteilungsdatenbank geschrieben wurden, können wir lesen, wie diese Daten in Verteilungstabellen gespeichert werden. Dafür wenden wir die sp_browsereplcmds an Prozedur – es ruft die Datensätze über die MSrepl_commands ab und MSrepl_transactions Tabellen.

Nehmen wir zu Lernzwecken eine Tabelle mit 3 Spalten namens Person.ContactType :

Das erstellte Abonnement führt 3 Verfahren für jeden Artikel durch, der Teil der Veröffentlichung in der Abonnentendatenbank mit den folgenden Namenskonventionen ist:

dbo.sp_MSins_
dbo.sp_MSupd_
dbo.sp_MSdel_

Für den Artikel Person.ContactType Table sehen wir die folgenden Prozeduren, die in der Subscriber-Datenbank erstellt wurden:

dbo.sp_MSins_PersonContactType – EINFÜGEN neue Datensätze, die aus den Transaktionsprotokollen der Publisher-Datenbank erfasst und dann an die Verteilungsdatenbank weitergegeben werden.
dbo.sp_MSupd_PersonContactType – AKTUALISIEREN Änderungen, die aus den Transaktionsprotokollen der Publisher-Datenbank erfasst und dann an die Verteilungsdatenbank weitergegeben werden.
dbo.sp_MSdel_PersonContactType – LÖSCHEN 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 table.

Executing the SELECT statement on the table yields 20 records:

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

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

Schlussfolgerung

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.