Integrieren von Daten aus mehreren Standorten (Server)
Viele Unternehmen besitzen regionale Büros oder Einrichtungen, die Daten sammeln und erfassen, die dann an einen zentralen Standort gesendet werden müssen, z. B.:
Warenbestandsdaten können per "Rollup" von einer Vielzahl von Servern in lokalen Lagern gesammelt und auf einem zentralen Server in der Hauptniederlassung des Unternehmens zusammengefasst werden.
Informationen autonom arbeitender Geschäftseinheiten innerhalb eines Unternehmens können an einen zentralen Server gesendet werden.
Es können Auftragsverarbeitungsinformationen von geografisch verstreut liegenden Standorten zusammengefasst werden.
Mitunter werden auch Daten von einem zentralen Standort an Remotestandorte gesendet. Diese Daten sind in der Regel am Remotestandort nicht änderbar, wie dies z. B. bei Warenbestandstabellen der Fall ist, die nur in der Zentrale aktualisiert werden können.
In der folgenden Abbildung ist ein typisches Szenario dargestellt, in dem ein Rollup von Daten von Remotestandorten ausgeführt wird. Alle Remotestandorte erhalten darüber hinaus schreibgeschützte Daten.
.gif "Replizieren von Daten für regionale Niederlassungen")
Adventure Works Cycles-Beispiel
Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter AdventureWorks-Beispieldatenbanken.
Adventure Works Cycles unterhält eine Reihe regionaler Verkaufsniederlassungen in den USA. Die Niederlassungen verwenden die Replikation mit den folgenden beiden Zielen:
Bereitstellung von Bestellinformationen zum Zweck der Auftragserfüllung und Berichterstellung. Die Daten werden in den einzelnen Verkaufsniederlassungen erfasst und verarbeitet und dann an die Zentrale repliziert.
Bereitstellung von Daten und Bestellmöglichkeiten für die mobilen Vertriebsmitarbeiter. Dieses Szenario wird im Thema Datenaustausch mit mobilen Benutzern beschrieben.
Allgemeine Anforderungen für dieses Szenario
Für die Anwendungen in den regionalen Niederlassungen gelten in der Regel die folgenden Anforderungen, die von einer geeigneten Replikationslösung erfüllt werden müssen:
Das System muss die Transaktionskonsistenz aufrechterhalten.
Das System sollte eine geringe Latenzzeit (Latenz) aufweisen: Aktualisierungen an den Remotestandorten müssen schnell am zentralen Standort eingehen.
Das System sollte einen hohen Durchsatz besitzen: Es sollte für die Replikation einer großen Zahl von Transaktionen ausgelegt sein.
Die Replikationsverarbeitung sollte nur einen minimalen Verwaltungsaufwand an den Remotestandorten erforderlich machen.
Datenänderungen müssen möglicherweise in beide Richtungen fließen können: In einigen Fällen werden nicht nur die Daten von den Remoteniederlassungen am zentralen Standort zusammengefasst, sondern es werden auch schreibgeschützte Daten an die Remotestandorte gesendet.
Bei den Daten, die am zentralen Standort benötigt werden, handelt es sich möglicherweise nur um einen Teilsatz der am Remotestandort verfügbaren Daten.
Für dieses Szenario zu verwendender Replikationstyp
MicrosoftSQL Server verwendet zur Beschreibung der Komponenten des Replikationssystems ein Modell, das sich auf Abläufe aus dem Verlagswesen stützt. Bei den Komponenten handelt es sich um den Verleger, die Abonnenten, Veröffentlichungen und Artikel sowie Abonnements.
In der Abbildung oben ist jeder Remotestandort ein Verleger. Einige oder alle der Daten am Remotestandort sind Teil der Veröffentlichung, und jede Datentabelle ist ein Artikel (als Artikel kommen aber auch andere Datenbankobjekte infrage, wie z. B. gespeicherte Prozeduren). Der zentrale Standort ist ein Abonnent dieser Veröffentlichung. Er erhält im Rahmen seines Abonnements das Schema und die Daten.
Der zentrale Standort dient auch als Verleger für die Daten, die an die Remotestandorte gesendet werden. Jeder Remotestandort ist Abonnent der Veröffentlichung des zentralen Standorts.
Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).
SQL Server bietet für die verschiedenen Anwendungsanforderungen die folgenden Replikationstypen: Snapshotreplikation, Transaktionsreplikation und Mergereplikation. Für das hier beschriebene Szenario mit den im vorherigen Abschnitt genannten Anforderungen eignet sich am besten die Transaktionsreplikation. Weitere Informationen zur Transaktionsreplikation finden Sie unter Transaktionsreplikation (Übersicht) und Funktionsweise der Transaktionsreplikation.
Die Transaktionsreplikation ist von ihrem Wesen her für die Hauptanforderungen dieses Szenarios gut geeignet:
Transaktionskonsistenz
geringe Latenzzeit
hoher Durchsatz
minimale Verwaltung
.gif "Hinweis") Hinweis |
|---|
Ein ähnliches Szenario kann auch mit der Mergereplikation implementiert werden. Wenn Ihre Anwendung die Konfliktlösung und Filter erfordert, mit deren Hilfe den einzelnen Remotestandorten separate Datensätze bereitgestellt werden können, empfiehlt sich die Verwendung der Mergereplikation. Weitere Informationen finden Sie unter Integration von Daten mehrerer Standorte (Client). |
Schritte zum Implementieren dieses Szenarios
Zum Implementieren dieses Szenarios müssen Sie zunächst eine Veröffentlichung und Abonnements erstellen und dann jedes Abonnement einzeln initialisieren. Weitere Informationen zu diesen Schritten finden Sie in den folgenden Themen:
Wenn das Abonnement initialisiert ist und die Daten zwischen dem Verleger und den Abonnenten fließen, benötigen Sie möglicherweise Informationen zu allgemeinen Verwaltungs- und Überwachungsaufgaben. Diese Informationen finden Sie in den folgenden Themen: