Datawarehousing- und Berichtsserver
Die Replikation wird häufig in Datawarehousing- und Berichtsanwendungen für folgende Zwecke verwendet:
Konsolidieren von Daten zum Transformieren und Verschieben in eine Datawarehousingumgebung
Verteilen von Daten in schreibgeschützte Datenbanken zur Berichterstellung
Verteilen von Daten an eine OLAP-Datenbank (Online Analytical Processing)
Obwohl die Replikation keine Microsoft SQL Server 2008 Analysis Services (SSAS)-Objekte repliziert (z. B. Dimensionen oder Cubes), dient sie häufig zum Verteilen von Daten aus OLTP-Datenbanken (Online Transactional Processing, Onlinetransaktionsverarbeitung) an Stagingdatenbanken und an Datenbanken, die für die Berichterstellung, Entscheidungsunterstützung oder für Analysezwecke verwendet werden.
Das folgende Diagramm zeigt ein typisches Szenario, bei dem Daten von einem Onlineverarbeitungsserver auf einen Berichtsserver und einen Stagingserver zur OLAP- und ROLAP-Analyse repliziert werden.
.gif "Replizieren von Daten auf einen Berichtsserver")
Beispiel mit Adventure Works Cycles
Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter AdventureWorks-Beispieldatenbanken.
Adventure Works Cycles verwendet Datawarehousing- und Berichtsserver in einer Reihe von Abteilungen, einschließlich der Fertigung und der Personalabteilung.
Die Fertigung speichert Vergangenheitsdaten zu Fertigungsfehlern sowie verschiedene andere Qualitäts- und Leistungsdaten. Die Daten werden von Servern in der Fertigungsanlage auf einen Stagingserver der Hauptniederlassung repliziert. Von dort aus werden die Daten transformiert und zur Analyse in OLAP-Cubes geladen.
Die Personalabteilung erstellt Berichte mithilfe einer Drittanbieteranwendung. Es ist beabsichtigt, diese Anwendung durch Reporting Services zu ersetzen. Außerdem sollen die Möglichkeiten zur Berichterstellung erweitert und die Voraussetzungen für folgende Analysearten geschaffen werden:
Vergütungsanalyse, einschließlich einer Analyse der Auswirkungen internationaler Wechselkurse
Planung des Personalbestands
Simulationsberechnungen und Prognosen der Lohn- und Gehaltszahlungen
Es wird ein neuer Server online geschaltet, der den erhöhten Berichtsbedarf des Unternehmens verarbeiten soll. Die Daten werden von der Personalabteilung und anderen Abteilungen auf diesen zentralen, schreibgeschützten Berichtsserver repliziert.
Allgemeine Anforderungen für dieses Szenario
Datawarehousing- und Berichtsanwendungen weisen in der Regel die folgenden Anforderungen auf, die eine entsprechende Replikationslösung berücksichtigen muss:
Das System muss die Transaktionskonsistenz aufrechterhalten.
Das System muss eine niedrige Latenzzeit aufweisen: Updates auf dem Onlineverarbeitungsserver müssen die Staging- und Berichtsserver schnell erreichen.
Das System sollte einen hohen Durchsatz sicherstellen: Es sollte in der Lage sein, die Replikation vieler Transaktionen durchzuführen.
Die Replikationsverarbeitung sollte nur einen minimalen Aufwand auf dem Onlineverarbeitungsserver mit sich bringen.
Datenänderungen fließen in eine Richtung, vom Onlineverarbeitungsserver zu den Staging- und Berichtsservern.
Die auf den Staging- und Berichtsservern erforderlichen Daten können eine Teilmenge der auf dem Onlineverarbeitungsserver verfügbaren Daten sein.
Typ der für dieses Szenario zu verwendenden Replikation
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, Veröffentlichungen und Artikel sowie Abonnements.
In dem oben stehenden Diagramm fungiert der Onlineverarbeitungsserver als Verleger. Einige oder sämtliche Daten des Onlineverarbeitungsservers sind in zwei Veröffentlichung enthalten (eine für das Staging und eine für die Berichterstellung), wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Der Stagingserver und der Berichtsserver sind Abonnenten für eine der Veröffentlichungen, wobei jeder Server das Schema und die Daten als Abonnement erhält. 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 Transaktionsreplikation implementiert, da hiermit die im vorherigen Abschnitt aufgeführten Anforderungen optimal erfüllt werden. Weitere Informationen zur Transaktionsreplikation finden Sie unter Transaktionsreplikation (Übersicht) und Funktionsweise der Transaktionsreplikation.
Die Transaktionsreplikation erfüllt die Hauptanforderungen für dieses Szenario programmbedingt:
Transaktionskonsistenz
Geringe Latenzzeit
Hoher Durchsatz
Minimaler Aufwand
Die wichtigste Option, die bei diesem Szenario berücksichtigt werden muss, ist die Filterung. Bei der Transaktionsreplikation können Sie Spalten und Zeilen filtern, sodass die Tabellen auf dem Staging- und dem Berichtsserver nur die für die Anwendung erforderlichen Daten enthalten. Weitere Informationen finden Sie unter Filtern von veröffentlichten Daten.
Schritte für die Implementierung dieses Szenarios
Für die Implementierung dieses Szenarios müssen Sie zunächst eine Veröffentlichung 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:
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: