Integration von Daten mehrerer Standorte (Client)

Viele Unternehmen verfügen über regionale Niederlassungen oder Stellen, in denen Daten erfasst und verarbeitet werden, die dann an einen zentralen Standort gesendet werden müssen. Beispiel:

• Inventardaten können aus einer Reihe von Servern in lokalen Warenlagern auf einem zentralen Server in der Hauptniederlassung zusammengeführt werden.
• Informationen aus autonomen Geschäftsabteilungen innerhalb eines Unternehmens können an einen zentralen Server gesendet werden.
• Informationen zur Auftragsabwicklung aus verteilten Standorten können zusammengeführt werden.

In einigen Fällen werden Daten auch vom zentralen Standort an Remotestandorte gesendet. In der Regel handelt es sich dabei um Daten, die am Remotestandort schreibgeschützt sind, wie z. B. eine Gruppe von Produkttabellen, die lediglich zentral aktualisiert werden.

Das folgende Diagramm zeigt ein typisches Szenario, bei dem Daten zwischen einem zentralen Standort und Remotestandorten in zwei Richtungen fließen:

In dieser Darstellung fließen die Daten zuerst zu einem Hub und dann zu den von diesem Hub bedienten regionalen Niederlassungen. Die Daten können auch direkt zwischen dem zentralen Standort und den regionalen Niederlassungen übertragen werden, wenn das Unternehmensnetzwerk über keine Zwischenschicht verfügt.

Beispiel mit Adventure Works Cycles

Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter Beispiele und Beispieldatenbanken.

Adventure Works Cycles besitzt weltweit eine große Zahl von Vertriebsbüros. In jedem Vertriebsbüro werden die Daten der jeweiligen Vertiebsmitarbeiter gesammelt. Die Daten werden an regionale Hubs übertragen und dann täglich bei Geschäftsschluss an den zentralen Standort übertragen. Gleichermaßen werden die Daten vom zentralen Standort an die Hubs der einzelnen Vertriebsbüros übertragen, sodass das Vertriebsbüro die neuesten Informationen zu Preisen und Werbeaktionen verfügbar hat.

Allgemeine Anforderungen für dieses Szenario

Anwendungen regionaler Niederlassungen weisen in der Regel die folgenden Merkmale auf, die eine entsprechende Replikationslösung berücksichtigen muss:

• Daten werden an einem zentralen Standort und an Remotestandorten eingegeben und aktualisiert.
• Remotebenutzer müssen Aktualisierungen eigenständig vornehmen können, ohne dass eine Verbindung mit dem zentralen Standort erforderlich ist.
• Da mehrere Benutzer dieselben Daten möglicherweise unabhängig voneinander aktualisieren, können Datenkonflikte auftreten, die gelöst werden müssen.
• Einige Daten sollten nur am zentralen Standort aktualisiert werden, z. B. Daten in Preistabellen.
• Benutzer sollten in der Lage sein, Daten bei Bedarf oder nach einem Zeitplan zu aktualisieren.
• Die Anwendung muss die Dauer steuern, die ein Remotestandort ohne Synchronisierung bleiben kann.
• Bei einigen Tabellen müssen Filter angewendet werden, damit die einzelnen Benutzer unterschiedliche Daten für eine oder mehrere Tabellen erhalten. Eine regionale Niederlassung empfängt beispielsweise nur für die Kunden in der Region der Niederlassung Kontaktdaten.
• Einige Daten müssen beim Übertragen zwischen den Standorten als Einheit behandelt werden. Wenn z. B. ein Auftrag von einem Remotebenutzer an einen zentralen Standort gesendet wird, muss zuerst für die Auftragskopfzeile ein Commit ausgeführt werden und dann für die Auftragsdetails.
• Gegebenenfalls muss die Anwendung beim Synchronisieren von Daten benutzerdefinierte Geschäftslogik ausführen.
• Die Anwendung macht es möglicherweise erforderlich, dass Daten über das Internet und nicht über eine dedizierte Verbindung synchronisiert werden.
• Das Unternehmen könnte so organisiert sein, dass Daten über eine oder mehrere Zwischenschichten zwischen dem zentralen Standort und den Remotestandorten fließen (wie im Diagramm weiter oben in diesem Thema dargestellt).

Das folgende Diagramm zeigt die mit diesem Szenario verbundenen Filter:

Typ der für dieses Szenario zu verwendenden Replikation

Microsoft SQL Server verwendet ein Modell, das sich auf Abläufe aus dem Verlagswesen stützt, um die Komponenten des Replikationssystems zu beschreiben. Zu den Komponenten zählen der Verleger, der Abonnent, Publikationen und Artikel sowie Abonnements. In dem oben stehenden Diagramm fungiert der zentrale Standort als Verleger. Die Daten des zentralen Standortes stellen die Publikation dar, wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Jeder Hub ist ein Abonnent der Publikation, der das Schema und die Daten als Abonnement erhält. Die Hubs veröffentlichen die Daten dann erneut, und die regionalen Niederlassungen abonnieren diese Daten. Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).

SQL Server bietet verschiedene Replikationstypen für unterschiedliche Anwendungsanforderungen: die Snapshotreplikation, die Transaktionsreplikation und die Mergereplikation. Für dieses Szenario wird am besten die Mergereplikation implementiert, da sie die im vorherigen Abschnitt erläuterten Anforderungen optimal erfüllt. Weitere Informationen zur Mergereplikation finden Sie unter Mergereplikation (Übersicht) und Funktionsweise der Mergereplikation.

Wichtig:

Es gibt zwei Möglichkeiten zum Implementieren dieses Szenarios: die zentrale Niederlassung ist ein Verleger und die Remoteniederlassungen sind Abonnenten, oder die zentrale Niederlassung ist ein Abonnent und die Remoteniederlassungen sind Verleger. Die Mergereplikation unterstützt keine zentralen Abonnententopologien. Auch wenn alle Änderungen an den Remotestandorten stattfinden, sollte die zentrale Niederlassung als Verleger mit den Remotestandorten als Abonnenten konfiguriert werden. Ein ähnliches Szenario kann bei der Transaktionsreplikation implementiert werden, wenn eine zentrale Abonnententopolgie verwendet wird. Wenn die Anwendung keine Konfliktlösung oder Filter erfordert, die für jeden Remotestandort einen eindeutigen Satz Daten bereitstellen, sollten Sie die Transaktionsreplikation verwenden. Weitere Informationen finden Sie unter Integrieren von Daten aus mehreren Standorten (Server).

Für dieses Szenario relevante Optionen der Mergereplikation

Die Mergereplikation stellt verschiedene Optionen bereit, mit denen die oben in diesem Thema erläuterten Anforderungen erfüllt werden können. Die folgende Liste enthält die einzelnen Anforderungen und die Optionen der Mergereplikationen zu deren Erfüllung.

• Daten werden an einem zentralen Standort und an Remotestandorten eingegeben und aktualisiert.
  Die Mergereplikation stellt diese Möglichkeit bereit, ohne dass weitere Optionen angegeben werden müssen.
• Remotebenutzer müssen Aktualisierungen eigenständig vornehmen können, ohne dass eine Verbindung mit dem zentralen Standort erforderlich ist.
  Die Mergereplikation stellt diese Möglichkeit bereit, ohne dass weitere Optionen angegeben werden müssen.
• Da mehrere Benutzer dieselben Daten möglicherweise unabhängig voneinander aktualisieren, können Datenkonflikte auftreten, die gelöst werden müssen.
  Die Mergereplikation ermöglicht die Konflikterkennung und -lösung für Fälle, in denen Datenkonflikte erwartet werden. Am besten werden Anwendungen entworfen, bei denen keine Konflikte auftreten. Wenn dies jedoch nicht möglich ist, können Sie den Standardmechanismus für die Konfliktlösung auswählen (Erste gewinnen) oder die benutzerdefinierte Konfliktlösung verwenden. Weitere Informationen finden Sie unter Erkennen und Beseitigen von Konflikten bei der Mergereplikation.
• Einige Daten sollten nur am zentralen Standort aktualisiert werden, z. B. Daten in Preistabellen.
  Die Mergereplikation stellt nur downloadbare Artikel für die Tabellen bereit, die lediglich auf dem Verleger aktualisiert werden sollten. Weitere Informationen finden Sie unter Optimieren der Leistung der Mergereplikation durch nur downloadbare Artikel.
• Benutzer sollten in der Lage sein, Daten bei Bedarf oder nach einem Zeitplan zu aktualisieren.
  Die Replikation stellt zwei Abonnementtypen bereit: Pushabonnements und Pullabonnements. Pullabonnements eignen sich für die bedarfsgesteuerte Synchronisierung besser. Weitere Informationen zu Abonnementtypen und zum Planen der Synchronisierung finden Sie unter Abonnieren von Publikationen und Synchronisieren von Daten.
• Die Anwendung muss die Dauer steuern, die ein Remotestandort ohne Synchronisierung bleiben kann.
  Bei der Mergereplikation können Sie ein Ablaufdatum für Abonnements festlegen, um sicherzustellen, dass alle Abonnenten innerhalb einer bestimmten Zeitspanne synchronisiert wurden. Weitere Informationen finden Sie unter Abonnementablauf und -deaktivierung.
• Bei einigen Tabellen müssen Filter angewendet werden, damit die einzelnen Benutzer unterschiedliche Daten für eine oder mehrere Tabellen erhalten. Eine Vertriebsmitarbeiterin erhält beispielsweise nur Kontaktinformationen für ihre Kunden.
  Die Mergereplikation ermöglicht Ihnen das Filtern von Spalten und Zeilen. Zeilenfilter können statisch oder parametrisiert sein. Ein statischer Filter wird nur beim Erstellen einer Publikation angewendet; er ergibt ein Dataset. Ein parametrisierter Filter wird bei jedem Synchronisieren eines Abonnenten angewendet; er ergibt verschiedene Datasets für jeden Abonnenten. Anwendungen regionaler Niederlassungen verwenden häufig parametrisierte Filter, könnten jedoch statische Filter verwenden. Weitere Informationen finden Sie unter Filtern veröffentlichter Daten für die Mergereplikation.
• Einige Daten müssen beim Übertragen zwischen den Standorten als Einheit behandelt werden. Wenn z. B. ein Auftrag von einem Remotebenutzer an einen zentralen Standort gesendet wird, muss zuerst für die Auftragskopfzeile ein Commit ausgeführt werden und dann für die Auftragsdetails.
  Bei der Mergereplikation können Sie angeben, dass eine Gruppe verbundener Tabellen als Einheit verarbeitet wird. Diese Einheit wird als logischer Datensatz bezeichnet. Weitere Informationen finden Sie unter Gruppieren von Änderungen an verknüpften Zeilen mithilfe von logischen Datensätzen.
• Gegebenenfalls muss die Anwendung beim Synchronisieren von Daten benutzerdefinierte Geschäftslogik ausführen.
  Die Mergereplikation ermöglicht es Ihnen, Code anzugeben, der während der Synchronisierung ausgeführt wird. Dieser Code kann eine Vielzahl von Ereignissen beantworten und kann auf die Daten zugreifen, die synchronisiert werden. Weitere Informationen finden Sie unter Ausführen der Geschäftslogik während der Mergesynchronisierung.
• Die Anwendung macht es möglicherweise erforderlich, dass Daten über das Internet und nicht über eine dedizierte Verbindung synchronisiert werden.
  Bei der Verwendung von SQL Server Compact Edition (SQL Server 2005 Compact Edition) werden Daten über eine HTTP- oder HTTPS-Verbindung synchronisiert. Für andere Versionen von SQL Server können Sie die Websynchronisierung verwenden, die HTTPS erfordert. Weitere Informationen finden Sie unter Websynchronisierung für die Mergereplikation.
• Das Unternehmen könnte so organisiert sein, dass Daten über eine oder mehrere Zwischenschichten zwischen dem zentralen Standort und den Remotestandorten fließen.
  Die Mergereplikation erfüllt diese Anforderung durch erneutes Veröffentlichen. Bei diesem Konzept veröffentlicht ein zentraler Verleger Daten für einen oder mehrere Abonnenten, die wiederum Daten für weitere Abonnenten veröffentlichen. Weitere Informationen finden Sie unter Wiederveröffentlichen von Daten.

Schritte für die Implementierung dieses Szenarios

Für die Implementierung dieses Szenarios müssen Sie zunächst eine Publikation und Abonnements erstellen und anschließend die einzelnen Abonnements initialisieren. Klicken Sie auf die folgenden Links, um weitere Informationen zu den einzelnen Schritten zu erhalten:

• Konfigurieren der Verteilung
• Veröffentlichen von Daten und Datenbankobjekten
• Abonnieren von Publikationen
• Initialisieren eines Abonnements

Nachdem das Abonnement initialisiert wurde und Daten zwischen dem Verleger und den Abonnenten fließen, müssen Sie möglicherweise folgende Themen zurate ziehen, um Informationen zu allgemeinen Verwaltungs- und Überwachungsaufgaben zu erhalten:

• Überwachen der Replikation
• Strategien zum Sichern und Wiederherstellen einer Mergereplikation
• Problembehandlung für die Replikation
• Entfernen der Replikation

Siehe auch

Konzepte

Replizieren von Daten zwischen einem Server und Clients

Hilfe und Informationen

Informationsquellen für SQL Server 2005