SQL Server Replikation: Vollständiger Leitfaden für Datenbankadministratoren [2026]

SQL Server Replikation ist ein Technologiepaket zum Kopieren und Verteilen von Daten und Datenbankobjekten von einer Datenbank in eine andere und zur anschließenden Synchronisierung zwischen den Datenbanken, um die Datenkonsistenz zu gewährleisten. Diese Funktion ermöglicht es Ihnen, mehrere Kopien Ihrer Daten auf verschiedenen Servern und Standorten zu erstellen und zu verwalten und so die Datenverfügbarkeit und -zuverlässigkeit sicherzustellen.

1.2 Zweck und Nutzen der Replikation

SQL Server Die Replikation erfüllt mehrere kritische Geschäftsanforderungen und bietet erhebliche Vorteile für die Datenbankverwaltung und Datenverteilung:

Datenverteilung über verschiedene Standorte: Die Replikation ermöglicht die gemeinsame Nutzung von Daten zwischen regionalen Niederlassungen oder globalen Standorten und verbessert so die betriebliche Effizienz, indem der lokale Zugriff auf die benötigten Daten sichergestellt wird. Dies reduziert die Netzwerklatenz und sorgt für eine bessere Performance für geografisch verteilte Benutzer.
Hochverfügbarkeit und Katastrophenwiederherstellung: Durch die Speicherung von Replikaten kritischer Daten auf mehreren Servern bietet die Replikation Redundanz und schützt so vor Hardwareausfällen und Katastrophen. Im Falle eines Ausfalls des primären Servers können die replizierten Kopien als Ausweichquellen dienen und so Ausfallzeiten und Datenverluste minimieren.
Lastverteilung und Skalierbarkeit: Die Replikation verteilt Lesevorgänge auf mehrere Server und verhindert so, dass ein einzelner Server zum Engpass wird. Dieser Ansatz verbessert die Systemleistung und ermöglicht die horizontale Skalierung Ihrer Infrastruktur mit zunehmendem Daten- und Benutzeraufkommen.
Echtzeitberichte und -analysen: Durch die Auslagerung von Berichts- und Analyseabfragen auf replizierte Server wird die Last auf Produktionsdatenbanken reduziert. Benutzer können komplexe Analyseabfragen auf nahezu Echtzeitdaten ausführen, ohne die operativen Systeme zu beeinträchtigen. Dies gewährleistet sowohl die Leistungsfähigkeit als auch die Aktualität der Daten.
Datenintegration und -konsolidierung: Die Replikation ermöglicht das Zusammenführen von Daten aus verschiedenen Quellen in einer einzigen konsolidierten Ansicht. Dies ist besonders wertvoll für Organisationen mit mehreren Niederlassungen, die Daten am Hauptsitz aggregieren müssen, oder für die Erstellung zentralisierter Data Warehouses aus verteilten operativen Systemen.

2. SQL Server Replikationsarchitektur und -komponenten

SQL Server Die Replikationsarchitektur besteht aus mehreren miteinander verbundenen Komponenten, die zusammenarbeiten, um Daten in Ihrer Datenbankinfrastruktur zu verteilen und zu synchronisieren. Dieser Abschnitt erläutert die Kernkomponenten, darunter Herausgeber, Verteiler, Abonnenten, Publikationen, Artikel, Abonnements und die Agenten, die den Datenfluss zwischen ihnen koordinieren.

Herausgeber: Ein Verleger ist ein SQL Server Eine Instanz, die eine oder mehrere Datenbanken mit zu replizierenden Daten hostet. Sie dient als autoritative Quelle in der Replikationstopologie.
Vertrieb: Ein Vertriebshändler ist ein SQL Server Die Distributor-Instanz verwaltet den Datenfluss zwischen Publishern und Subscribern. Sie hostet die Distributionsdatenbank, in der Replikationsmetadaten und Transaktionen gespeichert werden.
Teilnehmer: Ein Abonnent ist ein SQL Server Eine Instanz, die replizierte Daten von Herausgebern empfängt und speichert. Eine einzelne Abonnenteninstanz kann mehrere Abonnentendatenbanken hosten, die jeweils Daten von unterschiedlichen Publikationen empfangen.
Veröffentlichung: Eine Publikation definiert, welche Daten repliziert und wie sie an Abonnenten verteilt werden. Sie gruppiert verwandte Artikel und legt die Replikationsmethodik fest, die für alle enthaltenen Objekte gilt.
Artikel: Ein Artikel ist der grundlegende Baustein der Replikation und repräsentiert ein einzelnes Datenbankobjekt, das an Abonnenten verteilt wird.
Abonnement: Ein Abonnement stellt die Beziehung zwischen einer Publikation und einem Abonnenten her und definiert, wie und wann Daten an die Zieldatenbank geliefert werden.
Agenten: Agenten sind spezialisierte Prozesse, die die eigentliche Arbeit des Verschiebens und Synchronisierens von Daten zwischen Replikationskomponenten übernehmen.

3. Arten von SQL Server Replikation

SQL Server Es werden verschiedene Replikationstypen angeboten, die jeweils für spezifische Datenverteilungsszenarien und Geschäftsanforderungen konzipiert sind. Das Verständnis der Eigenschaften, Vorteile und Einschränkungen jedes Typs ist unerlässlich, um den richtigen Ansatz für Ihre Umgebung auszuwählen.

3.1 Snapshot-Replikation

Die Snapshot-Replikation erstellt zu einem bestimmten Zeitpunkt eine Momentaufnahme der zu veröffentlichenden Daten und verteilt anschließend die exakte, vollständige Kopie an die Abonnenten. Sie überwacht keine nachfolgenden Änderungen, bis die nächste Momentaufnahme erstellt wird. Die Snapshot-Replikation ist die einfachste Form der Replikation und eignet sich daher für Szenarien, in denen sich Daten selten ändern oder leicht veraltete Daten akzeptabel sind.

Typische Anwendungsfälle sind die Verteilung von Referenzdaten wie Preislisten oder Wechselkursen, die sich regelmäßig aktualisieren, die Bereitstellung initialer Datensätze für Data Warehouses sowie Szenarien, in denen eine vollständige Datenaktualisierung der Nachverfolgung einzelner Änderungen vorzuziehen ist. Beispielsweise könnte ein Unternehmen die Snapshot-Replikation nutzen, um aktualisierte Produktkataloge einmal täglich an die Filialen zu verteilen.

Die Hauptvorteile der Snapshot-Replikation liegen in ihrer Einfachheit, dem geringen Wartungsaufwand und der Möglichkeit, Daten ohne Primärschlüssel zu replizieren. Sie weist jedoch erhebliche Nachteile auf, darunter hohe Auswirkungen bei der Snapshot-Generierung aufgrund von Tabellensperren, hohe Latenzzeiten zwischen Aktualisierungen und Ineffizienz bei großen oder sich häufig ändernden Datensätzen. Alle Änderungen, die Abonnenten vornehmen, gehen beim Anwenden des nächsten Snapshots verloren.

3.2 Transaktionsreplikation

Die Transaktionsreplikation übermittelt Änderungen vom Herausgeber an die Abonnenten nahezu in Echtzeit, indem einzelne Transaktionen fortlaufend repliziert werden. Zunächst wird eine Momentaufnahme erstellt, um die Ausgangslage festzulegen. Anschließend wird das Transaktionsprotokoll kontinuierlich auf Änderungen an veröffentlichten Artikeln überwacht und diese inkrementell an die Abonnenten ausgeliefert.

Transaktionsreplikation eignet sich ideal für Server-zu-Server-Szenarien, die hohen Durchsatz und geringe Latenz erfordern. Typische Anwendungsfälle sind die Verbesserung von Skalierbarkeit und Verfügbarkeit durch Auslagerung von Leseoperationen auf Abonnentenserver, die Unterstützung von Data Warehousing und Reporting mit nahezu Echtzeitdaten, die Integration von Daten aus mehreren Standorten an einem zentralen Ort sowie die Auslagerung der Stapelverarbeitung auf dedizierte Server. Beispielsweise könnte eine E-Commerce-Plattform Transaktionsreplikation nutzen, um synchronisierte Bestandsdaten in regionalen Datenbanken zu gewährleisten.

Zu den Vorteilen der Transaktionsreplikation zählen die geringe Latenz bei der Datenübertragung, der hohe Durchsatz bei großen Transaktionsvolumina und die Möglichkeit, nicht replizierte Änderungen bei den Abonnenten vorzunehmen. Nachteile sind die höhere Komplexität im Vergleich zur Snapshot-Replikation, die Notwendigkeit von Primärschlüsseln in replizierten Tabellen und das Risiko eines Replikationsfehlers bei Konflikten wie beispielsweise Primärschlüsselverletzungen bei den Abonnenten.

3.3 Zusammenführungsreplikation

Die Merge-Replikation ist speziell für Umgebungen konzipiert, in denen Abonnenten offline oder mit zeitweiser Verbindung arbeiten müssen und Änderungen erst synchronisieren, wenn eine Verbindung verfügbar ist. Dieser Replikationstyp ermöglicht es, Daten sowohl auf Publisher- als auch auf Subscriber-Ebene unabhängig voneinander zu ändern, Änderungen mithilfe von Triggern und Metadatentabellen zu verfolgen und Modifikationen während der Synchronisierung automatisch zusammenzuführen.

Die Merge-Replikation ist für mobile Anwendungen und verteilte Serverumgebungen konzipiert, in denen autonome Änderungen auftreten. Anwendungsbeispiele sind die Vertriebsautomatisierung, bei der mobile Nutzer offline arbeiten und die Daten später synchronisieren, Kassensysteme, die unabhängig voneinander arbeiten und Daten regelmäßig konsolidieren, sowie verteilte Anwendungen, bei denen mehrere Standorte gemeinsam genutzte Daten aktualisieren müssen. Beispielsweise könnte eine Einzelhandelskette die Merge-Replikation nutzen, damit jede Filiale ihren lokalen Lagerbestand verwalten und gleichzeitig mit dem zentralen Lagersystem synchronisieren kann.

Zu den Vorteilen der Mergereplikation zählen die Unterstützung autonomer Abonnenten, die Änderungen vornehmen können, die Toleranz gegenüber zeitweiligen Netzwerkunterbrechungen und die flexible Konfliktlösung. Nachteile sind der höhere Aufwand bei Einrichtung und Wartung, der Leistungsverlust durch die Verfolgung von Metadaten und Triggern, das Hinzufügen von eindeutigen Identifikatorspalten zu Tabellen sowie das Potenzial für Konflikte, die verwaltet und gelöst werden müssen.

3.4 Peer-to-Peer-Replikation

Peer-to-Peer-Replikation basiert auf Transaktionsreplikation und ermöglicht es mehreren Serverinstanzen (drei oder mehr Knoten), als gleichberechtigte Partner zu agieren, wobei jeder Knoten gleichzeitig als Publisher und Subscriber fungiert. In dieser Topologie verwalten alle Knoten identische Datenkopien und können sowohl Lese- als auch Schreibvorgänge verarbeiten, wodurch eine vollständig verteilte Multi-Master-Umgebung entsteht.

Peer-to-Peer-Replikation eignet sich für Anwendungen, die eine horizontale Skalierung von Leseoperationen und hohe Verfügbarkeit erfordern. Anwendungsfälle sind beispielsweise Webanwendungen, die Katalogabfragen auf mehrere Knoten verteilen und dabei Datenkonsistenz gewährleisten, Szenarien, die Wartungsarbeiten oder Upgrades ohne Ausfallzeiten durch die individuelle Offline-Schaltung von Knoten erfordern, sowie globale Anwendungen mit Rechenzentren in verschiedenen Regionen. So könnte beispielsweise eine weltweit tätige Software-Supportorganisation Peer-to-Peer-Replikation zwischen Niederlassungen in verschiedenen Zeitzonen nutzen, um sicherzustellen, dass jeder Standort lokalen Zugriff auf aktuelle Daten hat.

Zu den Vorteilen der Peer-to-Peer-Replikation zählen eine verbesserte Leseleistung durch Scale-out, höhere Verfügbarkeit mit mehreren aktiven Knoten und nahezu Echtzeit-Datenkonsistenz. Nachteile sind die Notwendigkeit der Enterprise Edition, die Komplexität der Verwaltung von Topologien mit mehreren Knoten, die Erfordernis identischer Schemata und Daten auf allen Knoten sowie potenzielle Konflikte, wenn Schreibvorgänge nicht korrekt partitioniert werden.

3.5 Bidirektionale Replikation

Die bidirektionale Replikation ist eine spezielle Transaktionsreplikationstopologie, die speziell für Umgebungen mit zwei Servern entwickelt wurde, in denen beide Server Änderungen austauschen müssen. Jeder Server veröffentlicht Daten und abonniert dieselben Daten vom anderen Server, wodurch ein einfacher bidirektionaler Synchronisierungsfluss entsteht. Obwohl auch die Peer-to-Peer-Replikation zwei Knoten unterstützt, bietet die bidirektionale Replikation in diesem speziellen Szenario eine höhere Leistung.

Bidirektionale Replikation eignet sich für Szenarien, die zwei aktive Server mit synchronisierten Daten erfordern, wie beispielsweise Aktiv-Aktiv-Konfigurationen für Hochverfügbarkeit oder geografisch verteilte Anwendungen, bei denen jeder Standort lokalen Schreibzugriff benötigt. Die Topologie erfordert ein sorgfältiges Anwendungsdesign, um Datenaktualisierungen zu partitionieren und Konflikte zu vermeiden.

Zu den Vorteilen zählen eine optimierte Leistung in Zwei-Server-Szenarien, eine einfachere Konfiguration im Vergleich zur Peer-to-Peer-Replikation, eine nahezu Echtzeit-Synchronisierung und ein geringerer Overhead als bei der Merge-Replikation. Zu den Nachteilen gehören die Beschränkung auf genau zwei Server, das Fehlen einer integrierten Konfliktlösung, was eine sorgfältige Anwendungsentwicklung erfordert, sowie die Notwendigkeit geeigneter Partitionierungsstrategien zur Vermeidung von Konflikten.

3.6 Aktualisierbare Abonnements

Aktualisierbare Abonnements erweitern die Transaktionsreplikation, sodass Abonnenten gelegentlich Änderungen an replizierten Daten vornehmen können, die dann an den Herausgeber und andere Abonnenten weitergegeben werden. Im Gegensatz zur Merge-Replikation oder Peer-to-Peer-Topologien, die für häufige bidirektionale Aktualisierungen ausgelegt sind, eignen sich aktualisierbare Abonnements für Szenarien, in denen der primäre Datenfluss unidirektional ist (vom Herausgeber zu den Abonnenten), Abonnenten aber gelegentlich Korrekturen oder Aktualisierungen vornehmen müssen.

Aktualisierbare Abonnements eignen sich für Szenarien, in denen die meisten Aktualisierungen beim Herausgeber erfolgen, gelegentliche Aktualisierungen bei den Abonnenten jedoch erforderlich sind, beispielsweise in Außenstellen, die hauptsächlich Daten lesen, aber lokale Korrekturen oder Aktualisierungen vornehmen müssen. Die Topologie erfordert eine sorgfältige Planung, um Konflikte zu minimieren und die Datenkonsistenz zu gewährleisten.

Zu den Hauptvorteilen zählt die Möglichkeit eingeschränkter Schreibvorgänge bei Abonnenten unter Beibehaltung der Leistungsmerkmale der Transaktionsreplikation. Nachteile sind die erhöhte Komplexität, das Potenzial für Konflikte, die gelöst werden müssen, der Leistungsmehraufwand durch das Zwei-Phasen-Commit-Protokoll im Sofortaktualisierungsmodus und die Voraussetzung, dass alle replizierten Tabellen Primärschlüssel besitzen.

3.7 Vergleich verschiedener Replikationstypen

Replikationstyp	Updatezeit	Anzahl der Herausgeber	Anleitung	Verwenden Sie Szenarien
Schnappschuss	Zeitpunkt	1	Eine Richtung (Herausgeber → Abonnenten)	Selten wechselnde Referenzdaten (Preislisten, Wechselkurse)
Transactional	Fast in Echtzeit	1	Eine Richtung (Herausgeber → Abonnenten)	Szenarien mit hohem Durchsatz (E-Commerce-Lagerbestand, Data Warehousing, Reporting)
Merge	Periodisch (wenn angeschlossen)	1	Bidirektional (Publisher ↔ Subscribers)	Mobile Anwendungen, Offline-Mitarbeiter (Vertriebsautomatisierung, Außendienst)
Peer-to-Peer	Fast in Echtzeit	Mehrere (3 oder mehr)	Bidirektional (alle Knoten)	Globale Multi-Datacenter-Implementierungen (weltweite Niederlassungen mit lokalem Lese- und Schreibzugriff)
bidirektionale	Fast in Echtzeit	2	Bidirektional (beide Server)	Aktiv-Aktiv-Konfigurationen mit zwei Rechenzentren (Hochverfügbarkeit an zwei Standorten)
Aktualisierbare Abonnements	Fast in Echtzeit	1	Vorwiegend in eine Richtung (gelegentlich Aktualisierungen in umgekehrter Richtung)	Zweigstellen, die hauptsächlich lesen, aber gelegentlich aktualisieren (lokale Korrekturen)

4. Einrichten SQL Server Replikation

4.1 Voraussetzungen und Anforderungen

4.1.1 Softwareanforderungen

SQL Server Für die Replikation sind Kompatibilitäten erforderlich. SQL Server Versionen müssen für alle Teilnehmer in der Topologie gelten. Die Version des Distributors muss mindestens der Version des Herausgebers entsprechen, und die Version des Abonnenten darf maximal zwei Versionen von der Version des Herausgebers abweichen. Zum Beispiel: SQL Server Der Herausgeber von 2016 kann replizieren auf SQL Server Abonnenten der Jahre 2012, 2014, 2016, 2017 oder 2019.

4.1.2 Berechtigungsanforderungen

Die Konfiguration der Replikation erfordert spezifische Berechtigungen auf jeder Ebene. Mitglieder der festen Serverrolle „sysadmin“ können alle Konfigurationsaufgaben der Replikation durchführen. Für detailliertere Berechtigungen benötigen Benutzer die Datenbankrolle „db_owner“ für Publisher- und Subscriber-Datenbanken.

4.2 Schritt 1: Verteilung konfigurieren

Die Konfiguration der Verteilung ist der erste Schritt bei der Einrichtung SQL Server Replikation.

Um die Verteilung zu konfigurieren SQL Server Managementstudio:

Verbinde dich mit dem SQL Server Instanz in SQL Server Management-Studio.
Klicken Sie im Objekt-Explorer mit der rechten Maustaste auf das Replikation Ordner und wählen Sie Verteilung konfigurieren.
Klicken Sie im Konfigurationsassistenten für die Verteilung auf Weiter auf der Begrüßungsseite.
Auf dem Vertriebspartner Wählen Sie auf dieser Seite je nach Ihren Topologieanforderungen eine der folgenden Optionen aus:
- Lokaler Distributor: Wählen Sie „Servername soll als eigener Verteiler fungieren“. SQL Server Wenn Publisher und Distributor auf derselben Instanz (der aktuellen Instanz) ausgeführt werden sollen, wird eine Verteilungsdatenbank und ein Protokoll erstellt. Diese Konfiguration ist einfacher einzurichten und eignet sich für kleinere Umgebungen oder wenn Netzwerkverzögerungen zwischen Publisher und Distributor Probleme verursachen würden.
- FernverteilerWählen Sie „Folgenden Server als Verteiler verwenden“ und klicken Sie auf Speichern Um die Verteilungsverarbeitung auf eine separate Instanz auszulagern, geben Sie einen Remote-Verteilerserver an. Diese Konfiguration verbessert die Leistung bei hohem Replikationsvolumen, indem die Arbeitslast auf mehrere Server verteilt wird. Sie müssen den Namen des Remote-Verteilers und ein Kennwort angeben, das der Herausgeber für die Verbindung zum Verteiler verwendet.
Gehen Sie auf Weiter Um den Speicherort des Snapshot-Ordners anzugeben, verwenden Sie einen UNC-Pfad (z. B. \\Servername\Freigabe\Ordner) anstelle eines lokalen Pfads, um die Erreichbarkeit im Netzwerk zu gewährleisten.
Auf dem Verteilungsdatenbank Auf dieser Seite können Sie den Standardnamen der Verteilungsdatenbank (in der Regel „distribution“) übernehmen oder einen benutzerdefinierten Namen angeben und anschließend die Speicherorte für Daten- und Protokolldateien konfigurieren.
Auf dem Publisher Überprüfen Sie auf dieser Seite, ob der aktuelle Server als Publisher aktiviert ist. Wenn Sie den aktuellen Server als Distributor konfigurieren, können Sie weitere Publisher hinzufügen, die diesen Distributor verwenden.
Überprüfen Sie die Aktionen des Assistenten und klicken Sie Farbe Verteilung konfigurieren.

4.3 Schritt 2: Publikation erstellen

Nach der Konfiguration der Verteilung besteht der nächste Schritt darin, eine Publikation zu erstellen, die definiert, welche Datenobjekte an Abonnenten repliziert werden.

Um eine Publikation zu erstellen SQL Server Managementstudio:

Erweitern Sie im Objekt-Explorer die Replikation -Ordner.
Der rechten Maustaste auf Lokale Veröffentlichungen gedrückt und wählen Sie Neue Veröffentlichung.
Der Assistent für neue Veröffentlichungen wird gestartet; klicken Sie Weiter auf der Begrüßungsseite.
Wählen Sie die Datenbank aus, die Sie veröffentlichen möchten. Publikationsdatenbank Seite. Dadurch wird die Veröffentlichung in der ausgewählten Datenbank automatisch aktiviert.
Auf dem Publikationstyp Seite, wählen Sie den Replikationstyp aus: Schnappschuss-Veröffentlichung, Transaktionspublikation, Peer-to-Peer-Veröffentlichungden Veröffentlichung zusammenführen.
Auf dem Artikel erweitern Sie die Tische Knoten und Tabellen auswählen, die als Artikel aufgenommen werden sollen.
Optional erweitern Gespeicherte Prozeduren, Aufrufeoder andere Objekttypen, um zusätzliche Artikel einzuschließen.
Gehen Sie auf Artikeleigenschaften um Filter oder andere artikelspezifische Einstellungen zu konfigurieren.
Auf dem Tabellenzeilen filtern Seite, fügen Sie bei Bedarf Zeilenfilter hinzu.
Auf dem Snapshot-Agent Auf dieser Seite können Sie auswählen, wann der Snapshot erstellt werden soll: sofort, zu einem bestimmten Zeitpunkt oder nach einem Zeitplan.
Auf dem Agentensicherheit Seite, geben Sie den Sicherheitskontext für den Snapshot-Agenten an.
Auf dem Zaubereraktionen Seite auswählen Publikation erstellen.
Geben Sie einen Publikationsnamen ein und klicken Sie auf Farbe.

4.4 Schritt 3: Abonnement erstellen

Nach der Erstellung einer Publikation besteht der nächste Schritt darin, Abonnements zu erstellen, die die Publikation mit den Abonnentendatenbanken verbinden.

Abonnements können Push-Abonnements (vom Distributor verwaltet) oder Pull-Abonnements (vom Abonnenten verwaltet) sein. Die wesentlichen Unterschiede liegen darin, wo das Abonnement erstellt wird und welcher Agentenstandort ausgewählt wird. Dies bestimmt die Art des Abonnements (Push oder Pull).

Für Push-Abonnement (verwaltet vom Vertriebspartner):

Auf dem Herausgeber Server, erweitern Replikation -> Lokale Veröffentlichungen.
Klicken Sie mit der rechten Maustaste auf die Publikation und wählen Sie aus Neue Abonnements.

Für Pull-Abonnement (wird vom Abonnenten verwaltet):

Auf dem Teilnehmer Server, erweitern Replikation, Rechtsklick Lokale Abonnements, und wählen Sie Neue Abonnements.
Auf dem Publikationen Seite, klicken Sie auf Finde SQL Server Publisher und eine Verbindung zum Publisher-Server herstellen.

Gemeinsame Schritte des Assistenten für beide Abonnementtypen:

Klicken Sie im Assistenten für neue Abonnements auf Weiter auf der Begrüßungsseite.
Wählen Sie die Publikation aus und klicken Sie Weiter.
Auf dem Standort des Vertriebsagenten Seite, wählen Sie den Standort des Agenten aus:
- Push-Abonnement: Wählen Sie „Alle Agenten beim Distributor ausführen“ – der Distributor wird die Änderungen an die Abonnenten weitergeben.
- Abonnement ziehen: Wählen Sie „Jeden Agenten auf seinem Abonnenten ausführen“ – jeder Abonnent ruft die Änderungen vom Distributor ab.
Auf dem Abonnenten Seite, vorhandene Abonnentenserver auswählen oder klicken In Subscriber neue hinzuzufügen.
Wählen Sie für jeden Abonnenten die Zieldatenbank aus oder erstellen Sie eine neue Datenbank. Hinweis: Die Abonnementdatenbank muss sich von der Verlagsdatenbank unterscheiden, selbst wenn dieselbe Datenbank verwendet wird. SQL Server Beispiel.
Auf dem Sicherheit des Vertriebsagenten Klicken Sie auf der Seite für jedes Abonnement auf die Schaltfläche „Eigenschaften“, um den Sicherheitskontext zu konfigurieren.
Auf dem Synchronisierungsplan Seite, wählen Sie zwischen kontinuierlicher Synchronisierung und geplanter Synchronisierung.
Auf dem Abonnements initialisieren Seite auswählen Sofort zur Initialisierung während des Abschlusses des Assistenten oder Bei der ersten Synchronisierung.
Überprüfen Sie die Aktionen des Assistenten und klicken Sie Farbe.

5. Überwachung und Steuerung SQL Server Replikation

5.1 Replikation überwachen mit dem Replikationsmonitor

So starten Sie den Replikationsmonitor:

In SQL Server Management Studio erweitern Replikation im Objekt-Explorer.
Der rechten Maustaste auf Replikation gedrückt und wählen Sie Replikationsmonitor starten.
Falls keine Verlage registriert sind, klicken Sie hier Herausgeber hinzufügen im linken Bereich.
Wählen Speichern SQL Server Publisher und eine Verbindung zum Publisher-Server herstellen.
Der Verlag wird im linken Bereich mit ausklappbaren Knoten für Publikationen und Abonnements angezeigt.

5.2 Leistungsüberwachung

5.2.1 Monitorlatenz

Die Replikationslatenz ist die Zeitverzögerung zwischen einer Änderung beim Herausgeber und deren Anwendung beim Abonnenten. Überwachen Sie die Latenz, um sicherzustellen, dass die Datenaktualität den Geschäftsanforderungen entspricht.

Verwenden Sie den Replikationsmonitor, um Latenzmetriken auf der Registerkarte „Alle Abonnements“ anzuzeigen. Die Spalte „Latenz“ zeigt die durchschnittliche Latenz in Sekunden an. Bei der Transaktionsreplikation liefern Tracer-Token präzise Latenzmessungen, indem sie Markierungstransaktionen einfügen, die durch die Replikationspipeline verfolgt werden.

So verwenden Sie Tracer-Token:

Wählen Sie im Replikationsmonitor eine Transaktionsveröffentlichung aus.
Klicken Sie auf Tracer-Tokens Tab.
Gehen Sie auf Tracer einfügen um eine Marker-Transaktion einzufügen.
Verfolgen Sie den Token auf seinem Weg vom Herausgeber über den Distributor zum Abonnenten.
Prüfen Sie die für jedes Segment benötigte Zeit, um Engpässe zu identifizieren.

5.2.2 Monitordurchsatz

Der Durchsatz misst das Datenvolumen, das im Laufe der Zeit repliziert wird, typischerweise ausgedrückt in Transaktionen pro Sekunde oder Befehlen pro Sekunde. Überwachen Sie den Durchsatz, um sicherzustellen, dass die Replikation mit der Aktivität des Herausgebers Schritt halten kann.

Der Replikationsmonitor liefert zwar grundlegende Synchronisierungsstatusinformationen, die Zustellungsrate und detaillierte Durchsatzmetriken sind jedoch in der Benutzeroberfläche nicht sichtbar. Verwenden Sie T-SQL-Abfragen gegen die Verteilungsdatenbank, um den Durchsatz zu überwachen.

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

Statuscodes: 1 = Start, 2 = In Bearbeitung, 3 = Erfolgreich, 4 = Leerlauf, 5 = Wiederholung, 6 = Fehler. Vergleichen Sie die Zustellungsrate mit den Transaktionsraten des Herausgebers, um Situationen zu identifizieren, in denen die Replikation hinterherhinkt. Leistungsindikatoren in Windows-Leistungsmonitor Zusätzliche Durchsatzmetriken für jeden Replikationsagenten bereitstellen.

5.2.3 Engpässe identifizieren

Replikationsengpässe können an mehreren Stellen in der Topologie auftreten. Auf dem Publisher können übermäßig lange Snapshot-Generierungszeiten oder Verzögerungen des Log Reader Agents auf Ressourcenengpässe hinweisen. Überwachen Sie CPU, Arbeitsspeicher und Festplatten-E/A auf dem Publisher während der Replikationsvorgänge.

Prüfen Sie beim Verteiler, ob sich in der Verteilerdatenbank Transaktionen ansammeln. Eine große Anzahl nicht verteilter Befehle deutet darauf hin, dass der Verteiler die Zustellung nicht bewältigen kann. Überwachen Sie die Serverressourcen des Verteilers und erwägen Sie für Szenarien mit hohem Transaktionsvolumen den Einsatz eines dedizierten Remote-Verteilers.

Beim Abonnenten kann eine langsame Anwendung von Änderungen durch unzureichende Ressourcen, fehlende Indizes oder Einschränkungen, die Einfügevorgänge verlangsamen, verursacht werden. Überwachen Sie die Ressourcennutzung des Abonnenten und die Abfrageleistung, während der Verteilungsagent ausgeführt wird. Begrenzte Netzwerkbandbreite zwischen den Komponenten kann ebenfalls zu Engpässen führen, insbesondere bei großen Datenmengen.

5.3 Verwaltung von Replikationsagenten

5.3.1 Agenten starten und stoppen

So starten oder stoppen Sie einen Replikationsagenten:

In SQL Server Management Studio erweitern SQL Server Makler -> Jobs.
Suchen Sie den Replikationsagentenauftrag (die Namen enthalten in der Regel die Publikations- und Abonnenteninformationen).
Klicken Sie mit der rechten Maustaste auf den Auftrag und wählen Sie aus Auftrag starten or Job stoppen.

5.3.2 Agentenprofile konfigurieren

Agentenprofile enthalten Parametersätze, die das Agentenverhalten steuern. SQL Server Es werden Standardprofile bereitgestellt, die für gängige Szenarien optimiert sind, und Sie können benutzerdefinierte Profile für spezielle Anforderungen erstellen.

So ändern Sie Agentenprofile:

Im Objekt-Explorer erweitern Replikation.
Der rechten Maustaste auf Replikation gedrückt und wählen Sie Vertriebseigenschaften.
Klicken Sie auf Profilvorgaben .
Wählen Sie aus der Dropdown-Liste einen Agententyp (Snapshot, Log Reader, Distribution oder Merge) aus.
Wählen Sie ein Profil aus und klicken Sie Eigenschaften im Vergleich Parameterwerte anzeigen.
Gehen Sie auf Neues Profil um ein benutzerdefiniertes Profil auf Basis eines bestehenden Profils zu erstellen.
Passen Sie die Parameter nach Bedarf an und klicken Sie auf „Weiter“. OK.

Weisen Sie einem Agenten ein Profil zu, indem Sie die Abonnementeigenschaften bearbeiten und das gewünschte Profil aus dem Dropdown-Menü „Agentenprofil“ auswählen.

5.3.3 Agentenparameter und -einstellungen

Die Agentenparameter optimieren Leistung und Verhalten. Zu den wichtigsten Parametern des Verteilungsagenten gehören CommitBatchSize (Anzahl der Transaktionen pro Commit), CommitBatchThreshold (Anzahl der Befehle vor dem Commit), SubscriptionStreams (parallele Verbindungen für schnellere Zustellung) und QueryTimeout (Timeout für Befehle).

Für den Log Reader Agent sind folgende Parameter wichtig: ReadBatchSize (Anzahl der pro Scan gelesenen Transaktionen), ReadBatchThreshold (Anzahl der Befehle vor der Zustellung) und PollingInterval (Verzögerung zwischen den Log-Scans). Passen Sie diese Parameter entsprechend dem Transaktionsvolumen und den Latenzanforderungen an.

5.4 Überlegungen zur Datensicherung und -wiederherstellung

Die Sicherung von Datenbanken, die an der Replikation beteiligt sind, erfordert besondere Vorkehrungen. Für die Publisher-Datenbank sind regelmäßige vollständige Sicherungen und Transaktionsprotokollsicherungen unerlässlich. Kennzeichnen Sie die Datenbanksicherung für die Replikationsunterstützung, indem Sie beim Sichern von Datenbanken in der Transaktionsreplikation die Option WITH REPLICATION verwenden. Sichern Sie die Verteilungsdatenbank regelmäßig, um die Replikationskonfiguration zu schützen.

Beim Wiederherstellen einer Publisher-Datenbank auf demselben Server mit demselben Namen verwenden Sie die Option WITH KEEP_REPLICATION, um den Replikationsstatus beizubehalten. Diese Option stellt sicher, dass Transaktionen, die vom Log Reader Agent noch nicht verarbeitet wurden, weiterhin zur Replikation markiert bleiben, sodass die Replikation automatisch fortgesetzt werden kann, ohne dass Abonnements neu initialisiert werden müssen.

In Notfallwiederherstellungsszenarien, in denen Backups nicht verfügbar oder beschädigt sind oder die Datenbankdateien beschädigt sind, können spezielle Wiederherstellungstools erforderlich sein. DataNumen SQL Recovery kann Daten aus beschädigten oder nicht zugänglichen MDF- und NDF-Dateien extrahieren und bietet somit eine letzte Möglichkeit, wenn Standardwiederherstellungsverfahren fehlschlagen.

Weitere Details zu SQL Server Backup, siehe unsere umfassende Anleitung.

6. Häufig gestellte Fragen (FAQ)

F: Worin besteht der Unterschied zwischen Snapshot- und Transaktionsreplikation?

A: Die Snapshot-Replikation erstellt eine vollständige Kopie der Daten zu einem bestimmten Zeitpunkt und wendet diese auf den Abonnenten an. Sie eignet sich für Daten, die sich selten ändern. Die Transaktionsreplikation beginnt mit einem initialen Snapshot und repliziert anschließend kontinuierlich einzelne Transaktionen, sobald diese stattfinden. Dadurch wird eine nahezu Echtzeit-Synchronisierung für häufig geänderte Daten ermöglicht.

F: Kann ich zwischen verschiedenen Systemen replizieren? SQL Server Versionen?

A: Ja, SQL Server Die Replikation unterstützt Versionskompatibilität nur in einem begrenzten Bereich. Die Version des Verteilers muss mindestens der Version des Herausgebers entsprechen, und die Version des Abonnenten darf maximal zwei Versionen von der des Herausgebers abweichen. Wenn der Herausgeber beispielsweise die Version … ist, … SQL Server 2016 kann der Abonnent sein SQL Server 2012, 2014, 2016, 2017 oder 2019.

F: Wie gehe ich mit Konflikten bei der Merge-Replikation um?

A: Die Merge-Replikation bietet integrierte Mechanismen zur Konflikterkennung und -behebung. Sie können Konfliktlöser auf Artikelebene konfigurieren und dabei aus integrierten oder benutzerdefinierten Lösungsmechanismen auswählen. Konflikte werden in der Regel prioritäts- oder zeitstempelbasiert gelöst. Optional können Konflikte zur manuellen Überprüfung protokolliert werden.

F: Welche Auswirkungen hat die Replikation auf die Leistung?

A: Die Replikation beeinflusst die Leistung auf verschiedene Weise: Der Herausgeber hat Mehraufwand durch die Nachverfolgung von Änderungen und die Erstellung von Snapshots, der Verteiler benötigt Ressourcen zum Speichern und Weiterleiten von Transaktionen, und die Netzwerkbandbreite wird während der Datenübertragung beansprucht. Die Auswirkungen variieren je nach Replikationstyp: Snapshot-Replikation verursacht periodische Spitzenlasten, während Transaktionsreplikation eine gleichmäßigere, aber kontinuierliche Last aufrechterhält.

F: Wie sichere ich meine Replikationstopologie?

A: Sichern Sie Ihre Replikationstopologie durch die Implementierung mehrerer bewährter Verfahren: Verwenden Sie Windows-Authentifizierung oder starke Authentifizierung. SQL Server Authentifizierung, Verbindungen mit TLS verschlüsseln, Snapshot-Ordner mit geeigneten Mitteln sichern NTFS Berechtigungen konfigurieren, die Publikationszugriffsliste (PAL) zur Zugriffskontrolle einrichten, separate Dienstkonten mit minimal erforderlichen Berechtigungen für jeden Replikationsagenten verwenden und regelmäßig die Replikationssicherheitseinstellungen überprüfen.

F: Kann ich in eine Azure SQL-Datenbank replizieren?

A: Ja, Sie können mithilfe der Transaktionsreplikation mit einer lokalen Datenbank eine Replikation in eine Azure SQL-Datenbank durchführen. SQL Server Alternativ kann Azure SQL Managed Instance als Herausgeber und Verteiler fungieren. Azure SQL Database kann als Abonnent, aber nicht als Herausgeber oder Verteiler dienen. Zusammenführungsreplikation und Peer-to-Peer-Replikation werden von Azure SQL Database nicht unterstützt.

F: Wie kann ich die Replikationsverzögerung überwachen?

A: Überwachen Sie Replikationsverzögerungen mithilfe des Replikationsmonitors in SQL Server Management Studio zeigt Latenzmetriken für jedes Abonnement an. Sie können außerdem Verteilungsdatenbanktabellen wie MSdistribution_history und MSrepl_commands abfragen, spezifische Leistungsindikatoren für Replikationsagenten verwenden oder Warnungen basierend auf Latenzschwellenwerten einrichten, um Synchronisierungsverzögerungen proaktiv zu erkennen und zu beheben.

F: Was passiert, wenn ein Abonnent offline ist?

A: Wenn ein Abonnent offline ist, hängt das Verhalten vom Replikationstyp ab. Bei der Transaktionsreplikation werden Transaktionen in der Verteilungsdatenbank gesammelt, bis der Abonnent wieder online ist. Anschließend wird die Synchronisierung fortgesetzt. Bei der Mergereplikation werden Änderungen auf beiden Seiten verfolgt und zusammengeführt, sobald die Verbindung wiederhergestellt ist. Die Einstellung der Aufbewahrungsdauer bestimmt, wie lange Daten aufbewahrt werden, bevor sie neu initialisiert werden müssen.

F: Wie füge ich neue Artikel zu einer bestehenden Publikation hinzu?

A: Um einer bestehenden Publikation neue Artikel hinzuzufügen, verwenden Sie SQL Server Verwenden Sie Management Studio, um die Veröffentlichungseigenschaften zu ändern und zusätzliche Objekte auszuwählen, oder nutzen Sie die gespeicherte Prozedur sp_addarticle. Nach dem Hinzufügen von Artikeln erstellen Sie einen neuen Snapshot und initialisieren alle Abonnements neu, um sicherzustellen, dass Abonnenten die neuen Artikel erhalten. Je nach Veröffentlichungseinstellungen kann eine Neuinitialisierung der Abonnements erforderlich sein.

F: Wie entferne ich die Replikation aus einer Datenbank?

A: Entfernen Sie die Replikation aus einer Datenbank, indem Sie zuerst alle Abonnements mit `sp_dropsubscription` löschen, anschließend die Veröffentlichung mit `sp_droppublication` entfernen und schließlich die Veröffentlichung für die Datenbank mit `sp_replicationdboption` deaktivieren. Wenn der Server ein Verteiler ist, deaktivieren Sie die Verteilung mit `sp_dropdistributor`. Sichern Sie die Datenbanken immer, bevor Sie die Replikationskonfiguration entfernen.

F: Was ist der Unterschied zwischen SQL Server Replikation und AlwaysOn-Verfügbarkeitsgruppen?

A: Replikation ist eine Datenverteilungs- und Integrationslösung, die auf Objektebene arbeitet, während Always On-Verfügbarkeitsgruppen ist eine Hochverfügbarkeits- und Disaster-Recovery-Lösung, die auf Datenbankebene arbeitet.

7. Fazit

SQL Server Die Replikation bietet ein robustes Framework für die Verteilung und Synchronisierung von Daten über mehrere Datenbanken und Standorte hinweg. Die Technologie unterstützt verschiedene Szenarien durch unterschiedliche Replikationstypen.

Die Wahl der richtigen Replikationsstrategie hängt von Ihren spezifischen Anforderungen ab. Berücksichtigen Sie die Änderungshäufigkeit der Daten, die Latenzanforderungen, ob Abonnenten Aktualisierungen vornehmen müssen, die Netzwerkeigenschaften und die Anforderungen an die Abonnentenautonomie. Die Snapshot-Replikation eignet sich am besten für selten geänderte Referenzdaten, bei denen die Latenz keine kritische Rolle spielt. Die Transaktionsreplikation ist für Szenarien mit hohem Datenaufkommen geeignet, die geringe Latenz und primär unidirektionalen Datenfluss erfordern.

Wählen Sie die Merge-Replikation, wenn Abonnenten einen autonomen Betrieb mit Offline-Funktionalität und bidirektionaler Synchronisierung benötigen. Implementieren Sie die Peer-to-Peer-Replikation für den Lastausgleich von Leseoperationen auf mehrere aktive Knoten mit nahezu Echtzeitkonsistenz. Ziehen Sie hybride Ansätze in Betracht, die mehrere Replikationstypen kombinieren, um komplexe Szenarien mit unterschiedlichen Anforderungen zu bewältigen.

Referenzen

Über den Autor

Yuan Sheng ist ein erfahrener Datenbankadministrator (DBA) mit über 10 Jahren Erfahrung in SQL Server Umgebungen und Unternehmensdatenbankverwaltung. Er hat Hunderte von Datenbankwiederherstellungsszenarien in Finanzdienstleistungs-, Gesundheits- und Fertigungsunternehmen erfolgreich gelöst.

Yuan ist spezialisiert auf SQL Server Datenbankwiederherstellung, Hochverfügbarkeitslösungen und Leistungsoptimierung. Seine umfangreiche praktische Erfahrung umfasst die Verwaltung von Multi-Terabyte-Datenbanken, die Implementierung von Always On Availability Groups und die Entwicklung automatisierter Backup- und Wiederherstellungsstrategien für unternehmenskritische Geschäftssysteme.

Durch sein technisches Fachwissen und seinen praktischen Ansatz konzentriert sich Yuan auf die Erstellung umfassender Anleitungen, die Datenbankadministratoren und IT-Experten bei der Lösung komplexer SQL Server Herausforderungen effizient. Er bleibt auf dem Laufenden mit den neuesten SQL Server und die sich entwickelnden Datenbanktechnologien von Microsoft und testet regelmäßig Wiederherstellungsszenarien, um sicherzustellen, dass seine Empfehlungen den bewährten Vorgehensweisen der Praxis entsprechen.

Haben Sie Fragen zu SQL Server Wiederherstellung oder benötigen Sie zusätzliche Anleitung zur Datenbank-Fehlerbehebung? Yuan begrüßt Feedback und Vorschläge zur Verbesserung dieser technischen Ressourcen.