Auswählen des geeigneten Replikationstyps

Microsoft SQL Server bietet drei Typen der Replikation. Jeder Replikationstyp eignet sich für andere Anwendungsanforderungen. Abhängig von diesen Anwendungsanforderungen können Sie sich für einen oder mehrere Typen der Replikation in einer Topologie entscheiden:

• Snapshotreplikation
• Transaktionsreplikation
• Mergereplikation

Um Ihnen die Auswahl des geeigneten Replikationstyps zu erleichtern, enthält dieses Thema Informationen zu folgenden Punkten:

• Replikationsszenarien
  In diesem Abschnitt werden in Kurzform verschiedene gängige Einsatzgebiete für die Replikation beschrieben. Über entsprechende Hyperlinks gelangen Sie zu ausführlicheren Beschreibungen.
• Replikationstypen
  In diesem Abschnitt werden die Anwendungsgebiete beschrieben, für die die jeweiligen Replikationstypen geeignet sind.
• Aktualisieren von Daten auf Abonnenten
  In diesem Abschnitt werden die Optionen beschrieben, die für Anwendungen zur Verfügung stehen, bei denen Daten auf dem Abonnenten aktualisiert werden müssen.

Sie sollten sich zunächst die Szenarienbeschreibungen durchlesen und so das Szenario herausfinden, das Ihren Anwendungsanforderungen am ehesten entspricht. Klicken Sie dann auf den entsprechenden Hyperlink, um sich weitere Informationen anzeigen zu lassen. Wenn keines dieser Szenarien Ihren konkreten Geschäftsanforderungen ausreichend nahe kommt oder wenn Sie zusätzliche Informationen zu den Replikationstypen benötigen, lesen Sie sich den Abschnitt zu Replikationstypen durch. Wenn Ihre Anwendung eine Aktualisierung auf einem oder mehreren Abonnenten erfordert, lesen Sie sich den Abschnitt zum Aktualisieren von Daten auf Abonnenten durch, um zu bestimmen, wie Sie beim Aktualisieren am besten vorgehen sollten.

Replikationsszenarien

Bei der Replikation kann grob zwischen den folgenden beiden Szenarien unterschieden werden: Replizieren von Daten in einer reinen Serverumgebung (Server-zu-Server-Szenarien) und Replizieren von Daten zwischen einem Server und dessen Clients. Bei Server-zu-Server-Szenarien kommt die Transaktionsreplikation (und mitunter die Snapshotreplikation) zum Einsatz, während beim Replizieren zwischen Servern und Clients die Mergereplikation verwendet wird.

Server-zu-Server-Szenarien

Das Replizieren von Daten zwischen Servern dient in der Regel zur Unterstützung der folgenden Anwendungen und Anforderungen:

Server-und-Client-Szenarien

Das Replizieren von Daten zwischen Servern und Clients (einschließlich Arbeitsstationen, Laptops, Tablet PCs und anderen Geräten) dient in der Regel zur Unterstützung der folgenden Anwendungen:

Replikationstypen

Snapshotreplikation

Die Snapshotreplikation wird üblicherweise verwendet, um den Ausgangsdatensatz und die Ausgangsdatenobjekte für Transaktions- und Mergepublikationen bereitzustellen. Die Snapshotreplikation kann aber auch als eigenständiger Replikationstyp verwendet werden. Die ausschließliche Verwendung der Snapshotreplikation empfiehlt sich vor allem dann, wenn eine oder mehrere der folgenden Bedingungen erfüllt sind:

• Es kommt nur selten zu Datenänderungen.
• Es ist zulässig, dass Kopien der Daten bezüglich des Verlegers für eine bestimmte Zeit nicht aktuell sind.
• Es werden kleine Datenmengen repliziert.
• Große Mengen von Daten werden innerhalb einer kurzen Zeit geändert.

Die Snapshotreplikation ist zu bevorzugen, wenn Datenänderungen zwar umfangreich sind, jedoch selten vorkommen. Wenn z. B. eine Vertriebsorganisation eine Produktpreisliste hat, in der alle Preise gleichzeitig ein- oder zweimal jährlich aktualisiert werden, wird das Replizieren des gesamten Snapshots der Daten nach der Änderung empfohlen.

Transaktionsreplikation

Die Transaktionsreplikation wird typischerweise in reinen Serverumgebungen verwendet und ist für die folgenden Fälle geeignet:

• Inkrementelle Änderungen sollen an Abonnenten weitergegeben werden, wenn sie auftreten.
• Die Anwendung benötigt eine niedrige Wartezeit zwischen dem Zeitpunkt, zu dem Änderungen auf dem Verleger vorgenommen werden, und dem Zeitpunkt, zu dem die Änderungen auf dem Abonnenten eintreffen.
• Die Anwendung benötigt Zugriff auf Zwischenstufen von Datenänderungen. Wenn eine Zeile sich z. B. fünfmal ändert, kann die Anwendung bei Verwendung der Transaktionsreplikation auf jede Änderung reagieren (indem sie z. B. einen Trigger auslöst) und nicht nur auf das endgültige Ergebnis aller Zeilenänderungen.
• Auf dem Verleger kommt es sehr häufig zu Einfüge-, Aktualisierungs- und Löschaktivitäten.
• Der Verleger bzw. Abonnent ist keine SQL Server-Datenbank, sondern z. B. eine Oracle-Datenbank.

Standardmäßig sind Abonnenten von Transaktionspublikationen schreibgeschützt, da Änderungen nicht an den Verleger zurückgegeben werden. Die Transaktionsreplikation bietet aber auch Optionen, die Aktualisierungen auf dem Abonnenten ermöglichen. Weitere Informationen dazu finden Sie im Abschnitt zum Aktualisieren von Daten auf Abonnenten in diesem Thema.

Mergereplikation

Die Mergereplikation wird typischerweise in Server-und-Client-Umgebungen verwendet. Ihre Verwendung empfiehlt sich in den folgenden Situationen:

• Mehrere Abonnenten aktualisieren dieselben Daten zu verschiedenen Zeitpunkten und geben diese Änderungen an den Verleger und an andere Abonnenten weiter.
• Abonnenten müssen Daten empfangen, Änderungen offline vornehmen und Änderungen später mit dem Verleger und anderen Abonnenten synchronisieren.
• Jeder Abonnent benötigt eine andere Datenpartition.
• Es kann zu Konflikten kommen, und Sie müssen in der Lage sein, die Konflikte zu erkennen und zu lösen.
• Die Anwendung muss nicht auf die einzelnen Zwischenstufen von Datenänderungen, sondern nur auf das endgültige Ergebnis der Datenänderung zugreifen können. Wenn sich eine Zeile auf dem Abonnenten z. B. fünfmal ändert, bevor sie mit einem Verleger synchronisiert wird, ändert sich die Zeile auf dem Verleger lediglich einmal und übernimmt so nur die endgültige Änderung (in diesem Fall also den fünften Wert).

Die Mergereplikation ermöglicht es verschiedenen Standorten, autonom zu arbeiten und die Aktualisierungen zu einem späteren Zeitpunkt zu einem einzelnen, einheitlichen Ergebnis zusammenzuführen. Da Aktualisierungen auf mehr als einem Knoten ausgeführt werden, sind dieselben Daten möglicherweise vom Verleger und von mindestens einem Abonnenten aktualisiert worden. Daher kann es beim Zusammenführen von Aktualisierungen zu Konflikten kommen, für deren Lösung die Mergereplikation aber eine Reihe von Möglichkeiten bietet.

Aktualisieren der Daten auf Abonnenten

Mit den folgenden Replikationstypen und Replikationsoptionen können Sie Änderungen auf einem Abonnenten vornehmen und diese Änderungen an den Verleger weitergeben:

Siehe auch

Andere Ressourcen

Implementieren der Replikation
Überlegungen zur Implementierung der Replikation

Hilfe und Informationen

Informationsquellen für SQL Server 2005