Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Interne SQL Server-Transaktionsreplikation – Teil 2

SQL Server-Transaktionsreplikation ist eine der am häufigsten verwendeten Replikationstechniken zum Kopieren oder Verteilen von Daten über mehrere Ziele. Im vorherigen Artikel haben wir die SQL Server-Replikation, Replikationstypen und die grundlegenden Interna zur Funktionsweise der Transaktionsreplikation besprochen. Jetzt tauchen wir in erweiterte Interna der Funktionsweise der SQL Server-Transaktionsreplikation ein.

Architektur der Transaktionsreplikation

Bevor wir beginnen, empfehle ich Ihnen, Ihr Wissen mit meinem vorherigen Artikel hier aufzufrischen.

Sehen wir uns zunächst die Architektur der SQL Server-Transaktionsreplikation an, die unten in der Microsoft-Dokumentation gezeigt wird.

In der Publisher-Datenbank , erstellen Sie eine Publikation bestehend aus der Liste der Artikel (Tabellen , Aufrufe usw.), die Sie an den Abonnenten replizieren müssen Datenbank. Sobald die Artikel für die Replikation aktiviert sind, werden alle Änderungen an diesen Artikeln für die Replikation markiert in den Transaktionsprotokollen der Publisher-Datenbank.

Die SQL Server-Transaktionsreplikation kann vom Publisher aus initialisiert werden an Händler und dann zum Abonnenten Datenbank über Snapshot Agent oder Voll Sicherungen . Der Snapshot Agent kann die Initialisierung durchführen über den Replikationskonfigurationsassistenten . Die vollständige Sicherung wird nur über T-SQL-Anweisungen unterstützt.

Der Protokolllese-Agent scannt das Transaktionsprotokoll der Herausgeberdatenbank, um die nachverfolgten Änderungen zu erkennen, die für die Replikation markiert sind. Es ignoriert andere in den Transaktionsprotokollen erfasste Änderungen und kopiert Datenänderungen aus dem Transaktionsprotokoll in die Verteilungsdatenbank.

Die Verteilungsdatenbank kann sich entweder im Verleger oder Abonnenten oder in einer anderen unabhängigen SQL Server-Instanz befinden. Beachten Sie 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 ausgeführt werden 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 per Push auf die Abonnementdatenbank an oder Ziehen Mechanismus .

  • Push-Abonnement – der Händler übernimmt das Eigentum, um Änderungen aus der Verteilungsdatenbank auf den Abonnenten anzuwenden.
  • Pull-Abonnement – ​​ der Abonnent Datenbank übernimmt den Besitz, um Änderungen aus der Verteilungsdatenbank an den Abonnenten abzurufen.

Sobald die Datensätze erfolgreich von der Verteilung an die Abonnentendatenbank verteilt wurden, werden sie als Verteilt markiert und auch zum Löschen aus der Distributionsdatenbank markiert .

Einer der Schlüsselreplikationswartungsjobs ist die Verteilungsbereinigung :Der Verteilungsjob wird alle 10 Minuten ausgeführt, um verteilte Datensätze aus der Verteilungsdatenbank zu löschen und die Größe der Verteilungsdatenbank unter Kontrolle zu halten.

Daher ist es unser Ziel für den aktuellen Artikel, die folgenden Themen zu untersuchen:

  • Verteilungsdatenbank
  • Replikationsagenten
    • Snapshot-Agent
    • Protokolllese-Agent
    • Vertriebsstelle
  • Replikations-Agent-Profile
  • Replikationswartungsjobs
  • Replikationslatenz und Tracer-Token
  • TableDiff-Dienstprogramm
  • SQL Server-Agent-Warnungen

SQL Server-Verteilungsdatenbank

Eine Verteilungsdatenbank ist eine Systemdatenbank, die während der Konfiguration der Replikation erstellt wird. Es ist das Herzstück der Replikation, da der Großteil des Prozesses aus einer Verteilungsdatenbank heraus ausgeführt wird.

Aufgrund der Art der Verteilungsdatenbank können wir nur begrenzte Operationen darauf ausführen, wie z. B. Sicherung und Wiederherstellung. Wir können es nicht direkt wie Benutzerdatenbanken löschen.

Bei einer riesigen Datenbank mit vielen zu replizierenden Daten müssen wir einige spezielle Maßnahmen ergreifen, um die Durchsatzleistung der Replikation zu verbessern:

Standardmäßig wird die Verteilungsdatenbank im in SQL Server konfigurierten Standardinstallationspfad erstellt . Falls nicht konfiguriert, wird es auf C erstellt : Laufwerk oder in den SQL Server-Installationsordnern. Wir empfehlen Ihnen, die Verteilungsdatenbank auf einen schnelleren Speicher/Festplatte zu verschieben, um die Leistung zu verbessern.

Die Anfangsdateigröße und Autowachstum der Verteilungsdatenbank wird gemäß den Einstellungen für die anfängliche Dateigröße und die automatische Vergrößerung der Modelldatenbank festgelegt. Konfigurieren Sie die Anfangsdateigröße auf einen besseren Wert wie 10 GB im Falle einer Datenbankreplikation mit Transaktionsauslastung. Die Autogrowth-Eigenschaften sollten bis zu 512 MB oder 1 GB für Daten- und Protokolldateien betragen. Dann gibt es keine große Fragmentierung der Daten- und Protokolldateien.

Konfigurieren Sie Täglich oder Routinesicherungsjobs um die Distributionsdatenbank zu Referenzzwecken oder zur Fehlerbehebung im Falle einer Datenbeschädigung oder eines Datenverlusts einzubeziehen.

Konfigurieren Sie die Tägliche Indexreorganisation oder Wartung Arbeitsplätze um die Verteilungsdatenbank einzuschließen. Die Datenbank beinhaltet riesige Dateneinfügungen in die MSrepl_transactions und MSrepl_commands Tabellen.

Hinweis:Kontinuierliches Abfragen dieser beiden Tabellen und DELETE von ihnen nach dem erfolgreichen Senden von Daten an die Abonnentendatenbank erhöht das Risiko einer Fragmentierung. Die regelmäßige Neuerstellung dieser Tabellen kann die Leistung der Verteilungsdatenbank verbessern.

Klicken Sie mit der rechten Maustaste auf Replikation, um Attribute der Verteilungsdatenbank anzuzeigen und zu ändern, die sich auf die Replikation beziehen > Verteilereigenschaften :

Klicken Sie auf die Ellipse Schaltfläche auf der rechten Seite, um weitere Details zu den einzelnen aufgelisteten Optionen anzuzeigen.

Beachten Sie, dass das Ändern von Parametern die Leistung der Verteilungsdatenbank beeinträchtigen kann. Implementieren Sie Änderungen daher erst, nachdem Sie alle Parameter, die Sie ändern möchten, sorgfältig bewertet haben.

Aufbewahrung von Transaktionen gibt an, wie viele Daten in der Verteilungsdatenbank aufbewahrt werden sollen. Die Minimal- und Maximalwerte können in Stunden oder Tagen angegeben werden.

Der auf 0 Stunden festgelegte Transaktionsaufbewahrungswert gibt an, dass Datensätze, sobald sie erfolgreich in die Abonnentendatenbank repliziert wurden, aus der Verteilungsdatenbank gelöscht werden können. Wenn Sie diesen Wert erhöhen, erhöht sich die Größe der Verteilungsdatenbank. Daher müssen wir es entsprechend planen.

Aufbewahrung des Verlaufs gibt den Aufbewahrungszeitraum zum Speichern der Daten des Transaktionsreplikationsleistungsverlaufs an. Standardmäßig sind es 48 Stunden.

Zum Löschen einer Verteilungsdatenbank , müssen wir die Veröffentlichung deaktivieren die dieser bestimmten Verteilungsdatenbank zugeordnet ist, und löschen Sie sie dann mit einer der beiden Methoden. Einer ist eine Kombination aus Veröffentlichung deaktivieren und dem Verteilungsassistenten. Ein anderer verwendet sp_dropdistributor oder sp_dropdistributiondb Verfahren. Der Assistent verwendet intern diese beiden Verfahren, um die Verteilung zu deaktivieren und die Verteilungsdatenbank zu löschen.

SQL Server Replication Agents

Replikationsagenten sind eigenständige Programme, die dafür verantwortlich sind, Datenänderungen vom Herausgeber nachzuverfolgen und diese Änderungen an die Verteiler- und Abonnentendatenbanken weiterzugeben. Sie werden als SQL Server Agent-Jobs ausgeführt.

Sehen wir uns zunächst den Speicherort dieser eigenständigen Programme an.

Um die Replikation zu konfigurieren, benötigen wir die Replikationskomponenten über das SQL Server-Installationsprogramm installiert. Wenn Sie fertig sind, können wir die eigenständigen Programme im Zusammenhang mit dem Replikationsagenten sehen, die im Installationspfad verfügbar sind:

C:\Programme\Microsoft SQL Server\130\COM

In meinem Fall ist die Version von SQL Server Version 2016. Daher ist sie im Pfad unter 130.

Für jeden Replication Agent sehen wir das jeweils verfügbare Standalone-Programm:

  • DISTRIB.exe – Verteilungsagent
  • Logread.exe – Protokolllese-Agent
  • Qrdrsvc.exe – Warteschlangenlesedienst-Agent
  • Replmerg.exe – Merge Replication Agent
  • Snapshot.exe – Snapshot-Agent
  • Tablediff.exe – Dienstprogramm zum Vergleichen von Tabellen. Wir können später in diesem Artikel auf weitere Details eingehen.

Jetzt, da wir wissen, wofür diese eigenständigen Programme verantwortlich sind und wo sie sich befinden, können wir verstehen, wie sie über SQL Server Agent Jobs ausgeführt werden.

Da wir uns mit der SQL Server-Transaktionsreplikation befassen, gehen wir die Jobs des Snapshot-Agents, des Protokolllese-Agents und des Verteilungs-Agents durch (dieselbe Logik gilt für alle anderen Agenten).

Snapshot-Agent

Der Snapshot-Agent wird auf dem 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 Herausgeber enthalten sind, erstellt die Snapshot-Dateien im Snapshot-Ordner und zeichnet die Synchronisierungsdetails in der Distributionsdatenbank auf.

Aus der Distribution MSSnapshot_agents Tabelle können wir den SQL Server-Agent-Auftrag identifizieren, der die Snapshot-Agent-Aktivitäten ausführt. Jede Veröffentlichung umfasst einen dedizierten SQL Server-Agent-Job, der sich um die Verantwortlichkeiten des Snapshot-Agenten kümmern muss.

Erweitern Sie SQL Server-Agent und öffnen Sie den oben genannten Jobnamen. Es zeigt die Details und die Kategorie an Name – REPL-Snapshot

Klicken Sie auf den Schritt um die vom Snapshot-Agenten durchgeführten Aktivitäten anzuzeigen.

Klicken Sie auf einen einzelnen Schritt, um die Informationen zum Snapshot-Agent-Job anzuzeigen.

Schritt 1 protokolliert bei jedem Start des Snapshot-Agenten einen Eintrag in der Verlaufstabelle, indem er sp_MSadd_snapshot_history verwendet Verfahren.

Die Tabelle, die den Verlauf der vom Snapshot-Agenten ausgeführten Details enthält, ist MSsnapshot_history Tabelle in der Verteilungsdatenbank.

Es entspricht dem Status des Snapshot-Agenten anzeigen Dialogfenster.

Fahren Sie mit Schritt 2 fort – Agent ausführen . Es wird den Snapshot-Agent-Job starten .

Unter dem Befehl , konnten wir keine T-SQL-Anweisungen oder -Abfragen finden. Es wurden nur einige Parameter aufgelistet. Die Antwort liegt also im hervorgehobenen Abschnitt der obigen Abbildung. Es zeigt, dass der JobschrittType ist Replikations-Snapshot Dadurch wird das eigenständige Programm snapshot.exe gestartet um die Aufgaben des Snapshot-Agenten wahrzunehmen.

Weitere Einzelheiten zu snapshot.exe finden Sie in diesem MSDN-Artikel. Wir werden auch später bei der Fehlerbehebung der Probleme im Zusammenhang mit der Replikation ins Detail gehen.

Schließlich gehen wir zu Schritt 3 – der letzte Job-Step. Es erfasst alle unerwarteten Abschaltungen von Agent-Jobs und meldet sie ab.

Protokolllese-Agent

Immer wenn die Veröffentlichung in einer Datenbank konfiguriert wird, werden alle Änderungen, die an diesen Artikeln vorgenommen werden, im Transaktionsprotokoll für die Replikation markiert. Der Protokollleseagent liest diese Datenänderungen über logread.exe und speichert sie über zwei separate Prozesse in der Verteilungsdatenbank:

  • Transaktionsprotokolle lesen – es verwendet die sp_replcmds erweiterte gespeicherte Prozedur zum Scannen nach Datenänderungen vom Verleger. Da diese gespeicherte Prozedur auf DLL-Dateien verweist, werden Interna darüber, wie genau Microsoft Protokolldateien liest, nicht identifiziert. Wir können jedoch undokumentierte Funktionen wie fn_dblog() ausprobieren und fn_dump_dblog() um zu verstehen, wie die Transaktionsprotokolldatei funktioniert.
  • In Verteilungsdatenbank schreiben – Es verwendet die sp_MSadd_replcmds gespeicherte Prozedur in der Verteilungsdatenbank, um die aus den Transaktionsprotokollen der Herausgeberdatenbank gelesenen Binärdaten zu schreiben. Es schreibt die Transaktionsdetails in die MSrepl_transactions Tabelle und einzelne Befehle zu den MSrepl_commands Tabelle.

Für jede veröffentlichte Datenbank ist nur ein Protokolllese-SQL Server-Agent-Auftrag verfügbar. Sie können seinen Namen wie folgt identifizieren:

Erweitern Sie den SQL Server-Agent und öffnen Sie den obigen Auftrag des Protokolllese-Agenten, um die Schritte anzuzeigen. Es wird die Job-Kategorie angezeigt unter Replication Log Reader.

Klicken Sie auf Schritte , um einzelne Schritte anzuzeigen, die vom Protokolllese-Agent ausgeführt werden. Wie beim Snapshot-Agent-Job sehen wir drei gleichwertige Schritte für den Log-Leser-Agent-Job.

Schritt 1 ruft sp_MSadd_logreader_history auf Verfahren zum Protokollieren der Startstatusverlaufsmeldungen des Protokollleseagenten in MSlogreader_history Tabelle.

Schritt 2 startet den Log Reader Agent-Prozess mit dem eigenständigen Programm logread.exe .

Weitere Details zu logread.exe finden Sie im jeweiligen MSDN-Artikel. Später werden wir auch die kritischen Konfigurationsparameter des Protokollleseagenten untersuchen.

Schritt 3 erfasst ein abruptes Herunterfahren des Log Reader Agent-Auftrags.

Vertriebsagent

Der Verteilungs-Agent (DISTRIB.exe) wurde von der Transaktions- und Snapshot-Replikation verwendet, um die anfänglichen Snapshot-Dateien und inkrementelle oder verfügbare ausstehende Transaktionen von der Verteilungsdatenbank auf die Abonnentendatenbank anzuwenden.

Dieser Agent wird vom Verteilerserver für die Push-Abonnements und vom Abonnentenserver für die Pull-Abonnements ausgeführt. Um den Namen des SQL Server-Agentenjobs zu finden, der die Aufgaben des Verteilungsagenten ausführt, können wir die spezifische Abfrage wie unten gezeigt ausführen:

Erweitern Sie den Auftrag des SQL Server-Agenten und öffnen Sie ihn, um weitere Informationen und die der Replikationsverteilung zugewiesene Kategorie anzuzeigen.

Klicken Sie auf Schritte – Sie sehen die Schritte, die den zuvor angezeigten Schritten der Snapshot- und Protokolllese-Agent-Jobs ähneln.

Schritt 1 ruft sp_MSadd_distribution_history auf Verfahren zum Protokollieren der Verlaufsmeldungen zum Startstatus des Protokollleseagenten in der MSdistribution_history Tabelle.

Schritt 2 startet den Distribution Agent-Prozess (DISTRIB.exe) mit den Standardparametern.

Weitere Einzelheiten zu DISTRIB.exe finden Sie im MSDN-Artikel. Außerdem gehen wir in den nächsten Artikeln auf die kritischen Konfigurationsparameter des Verteilungsagenten ein.

Schritt 3 erfasst Details über das abrupte Herunterfahren des Verteilungs-Agent-Auftrags.

Replikations-Agent-Profile

Aus den Verteilereigenschaften , können wir die Option zum Anzeigen der Replication Agent-Profile erhalten . Belassen Sie die Agentenprofile auf den Standardwerten und ändern Sie sie nur nach Bedarf für Fehlerbehebungszwecke.

Klicken Sie auf Profilstandards , um die für alle auf dem Server verfügbaren Replication Agents konfigurierten Standardwerte anzuzeigen.

Wählen Sie die Verteilungsagenten aus Abschnitt und klicken Sie auf die Ellipse neben dem Standardagentenprofil um die konfigurierten Werte zu sehen. Siehe Abbildung unten:

Zeigen Sie das Standardagentenprofil an der Snapshot-Agenten Leser-Agent:

Standardagentenprofil für den Protokollleser Agent:

Replikationswartungsjobs

Neben Replication Agents haben wir Replication Maintenance Jobs .

Dies sind SQL Server-Agent-Aufträge, die beim Konfigurieren der SQL Server-Transaktionsreplikation erstellt werden. Sie sind verfügbar, um sicherzustellen, dass die Transaktionsreplikation ordnungsgemäß funktioniert.

Einige Jobs zur Replikationswartung sind für die Transaktionsreplikation unerlässlich. Sehen wir sie uns an.

  • Bereinigung der Verteilung: Verteilung – führt die sp_MSdistribution_cleanup aus Verfahren zum Löschen von Replikationsbefehlen aus MSrepl_transactions und MSrepl_commands Tische. Die Bereinigung erfolgt in der Verteilungsdatenbank, nachdem Befehle erfolgreich an die Abonnentendatenbank gesendet wurden, basierend auf dem in der Verteilungsdatenbank konfigurierten Wert für den Transaktionsaufbewahrungszeitraum. Standardmäßig wird dieser Job alle 10 Minuten in der Verteilungsdatenbank ausgeführt. Ändern Sie diese Werte nur nach eingehender Prüfung.
  • Agent Verlauf bereinigen:Verteilung – führt die sp_MShistory_cleanup aus Verfahren in der Verteilungsdatenbank, um Verlaufsdatensätze zu bereinigen, die älter sind als der in dieser Datenbank konfigurierte Verlaufsaufbewahrungszeitraum. Standardmäßig ist es für 48 Tage konfiguriert und wird alle 10 Minuten ausgeführt. Wenn Sie diese Werte ändern möchten, überlegen Sie sich alle Aspekte sorgfältig.
  • Abgelaufen Abonnementbereinigung – führt die sp_expired_subscription_cleanup aus Prozedur in der Master-Datenbank, um abgelaufene oder lange inaktive Abonnements zu löschen. Standardmäßig wird dieses Verfahren einmal täglich ausgeführt.

Replikationslatenz und Tracer-Token

Replikationslatenz ist die Zeit, die der Replikationsprozess benötigt, um Änderungen an veröffentlichten Artikeln aus der Publisher-Datenbank zu verfolgen, bis diese erfolgreich über den Distributor an den Abonnenten geliefert werden.

Die Replikationslatenz wird in Millisekunden gemessen. Der Zielwert von 0 (Echtzeitreplikation) bis zu einem sehr niedrigen Wert (Idealfälle). Dies ist eine der wichtigsten Maßnahmen zur Überwachung der Replikationsleistung.

Wir können die Replikationslatenz mit dem Replikationsmonitor oder den dedizierten sp_replcounters überprüfen Verfahren.

Da der Replication Monitor hat die Aktualisierung kann es zu geringfügigen Abweichungen von den beobachteten Werten kommen. Um die leichten Abweichungen bei der Berechnung der Replikationslatenz zu überwinden, kommen uns Tracer-Token zu Hilfe.

Klicken Sie auf die Tracer-Tokens (siehe Abbildung oben), um einen neuen Satz von Testbefehlen vom Publisher zu senden. Messen Sie dann, wann es die Verteilerdatenbank erreicht und wann es an die Abonnentendatenbank gesendet wurde. Klicken Sie auf Tracer einfügen So senden Sie Tracer-Tokens aus der Publisher-Datenbank:

Sobald die Datensätze erfolgreich im Abonnenten empfangen wurden, können wir die gesamte Replikationslatenz für unser aktuelles Setup nachverfolgen. In unserem Fall sind es 9 Sekunden:4 Sekunden vom Publisher zum Distributor und 5 Sekunden vom Distributor zum Subscriber.

Tablediff-Dienstprogramm

Tablediff-Dienstprogramm (tablediff.exe) wird im Pfad C:\Programme\Microsoft SQL Server\130\COM installiert sobald wir die Replikationskomponenten installiert haben.

Das Dienstprogramm TableDiff vergleicht zwei Tabellen auf Nichtkonvergenz. Das bedeutet, dass wir 2 Tabellen vergleichen und die Unterschiede zwischen ihnen identifizieren können. Anschließend wird die Zieltabelle im Vergleich zur Quelltabelle synchronisiert, indem dedizierte INSERT/UPDATE/DELETE-Skripts generiert werden. Weitere Details sind in der offiziellen Dokumentation verfügbar.

Da sich die SQL Server-Transaktionsreplikation nicht um manuelle Änderungen in der Abonnentendatenbank kümmert, kann dieses Dienstprogramm helfen, diese Art von Tabellen nach Bedarf zu synchronisieren. Es verfügt jedoch nicht über einen Assistenten oder eine Benutzeroberfläche – Sie können nur über die Eingabeaufforderung oder über Batchdateien darauf zugreifen.

Andere Tools können den Vergleich und die Synchronisierung vereinfachen. Das dbForge Compare Bundle für SQL Server prüft die Diskrepanzen in den Datenbanken und bestimmten Tabellen identifiziert und analysiert sie. Es generiert auch die notwendigen Skripte, um sie zu synchronisieren. Es bietet eine visuelle Oberfläche und eine Reihe von Optionen, um die Aufgaben schnell und unkompliziert auszuführen.

SQL Server-Agent-Warnungen

Alle Schlüsselkomponenten im Zusammenhang mit Replication Agents befinden sich als Jobs unter den SQL Server Agent-Jobs. Daher ist es wichtig, kontinuierlich zu überwachen, wie SQL Server-Agent-Jobs funktionieren, um sicherzustellen, dass die Replikation ohne Probleme funktioniert. Die häufigsten Probleme sind unten aufgeführt:

  • Berechtigungsvergabe beim Ausführen von Replication Agent-Jobs
  • Berechtigungsvergabe beim Ausführen eines Replikationswartungsjobs.
  • Berechtigungsproblem beim Zugriff auf Herausgeber- oder Distributions- oder Abonnentendatenbank.
  • Der SQL Server-Agent ist nicht für den automatischen Start beim Neustart des Servers konfiguriert.
  • Mehrere andere replikationsbezogene Datenprobleme wie Konflikte, fehlende Daten usw.

Aus diesem Grund sollten wir über einen angemessenen Warnmechanismus verfügen, um den DBA oder eine andere Person unverzüglich über jedes Problem zu informieren.

Um DBAs oder andere Personen im Falle von Auftragsfehlern oder -fehlern zu warnen, sollten wir die Datenbank-E-Mail so konfigurieren, dass E-Mail-Benachrichtigungen gesendet werden. Dadurch kann der DBA sofort reagieren und das Problem beheben. Wir werden später in einem separaten Artikel besprechen, wie Sie die Datenbank-E-Mail und -Warnungen konfigurieren.

Beim Konfigurieren der Replikation erstellt SQL Server standardmäßig den folgenden Satz von Warnungen. Sie können sie einfach für die erforderlichen Kriterien konfigurieren. Es stellt auch sicher, dass Benachrichtigungen an die erforderlichen Personen für sofortige Maßnahmen gesendet werden.

Schlussfolgerung

Vielen Dank, dass Sie sich einen weiteren umfangreichen Artikel über Replikation angesehen haben. Ich hoffe, es hat geholfen, die Interna der Transaktionsreplikation und die Details über die Verteilungsdatenbank, die Replikationsagenten und die dafür verantwortlichen eigenständigen Programme zu klären. Wir haben auch die Replikationslatenz, Warnungen und Tracer-Token identifiziert.

Jetzt können wir tiefer eintauchen und lernen, wie man Replikationsprobleme professionell behandelt und löst. Bleiben Sie dran für den nächsten Artikel!