• Artikel

Auslagern der Batchverarbeitung

Bestimmte Anwendungen erfordern das Ausführen arbeitsintensiver Batchvorgänge. In vielen Fällen können diese Batchvorgänge nicht auf dem OLTP (Online Transaction Processing)-Server ausgeführt werden, da der zusätzliche Verarbeitungsaufwand andere Vorgänge auf dem Server beeinträchtigen würde. Hier ist es notwendig, die Batchverarbeitung auf einem separaten Server auszuführen. In manchen Fällen wird die Batchverarbeitung einfach ausgelagert; in anderen Fällen werden die Ergebnisse der Batchverarbeitung an den OLTP-Server zurückgegeben.

Das folgende Diagramm zeigt ein typisches Szenario, in dem Daten auf einen Batchverarbeitungsserver repliziert werden:

Replizieren von Daten für die Batchverarbeitung

Beispiel mit Adventure Works Cycles

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

Adventure Works Cycles verwendet die Batchverarbeitung zur Überprüfung von eventuellem Kreditkartenbetrug auf seiner Website. Die aus den Websitetransaktionen gesammelten Daten werden von dem Microsoft SQL Server der Website auf einen SQL Server repliziert, der für verschiedene Anwendungen der Firma Adventure Works Cycles verwendet wird. Auf diesem Batchverarbeitungsserver werden die Daten auf Kreditkartenbetrugsmuster überprüft. Der durch die Betrugserkennung erzeugte Datenumfang ist zwar relativ gering (Aktualisieren von Daten in einer kleinen Anzahl an Spalten, falls ein Konto eine verdächtige Aktivität aufweist), die Überprüfungen sind jedoch arbeitsintensiv und erfordern beträchtliche Serverressourcen. Wenn der Batchverarbeitungsprozess abgeschlossen ist, wird ein geringer Datenumfang mit Angaben zu Konten mit möglicherweise betrügerischen Absichten zurück an den OLTP-Server der Website gesendet.

Allgemeine Anforderungen für dieses Szenario

Batchverarbeitungsanwendungen haben in der Regel die folgenden Anforderungen, die eine entsprechende Replikationslösung berücksichtigen muss:

  • Das System muss die Transaktionskonsistenz aufrechterhalten.

  • Das System muss eine niedrige Latenzzeit aufweisen: Aktualisierungen auf dem Onlineverarbeitungsserver müssen den Batchverarbeitungsserver schnell erreichen.

  • Das System sollte einen hohen Durchsatz haben: Es sollte für die Replikation einer großen Anzahl von Transaktionen ausgelegt sein.

  • Die Replikationsverarbeitung sollte nur einen minimalen Aufwand auf dem Onlineverarbeitungsserver mit sich bringen.

  • Datenänderungen werden eventuell in beiden Richtungen übertragen: Die Ergebnisse der Batchverarbeitung können an den Onlineverarbeitungsserver zurückgegeben werden.

  • Die auf dem Batchverarbeitungsserver 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. Bei den Komponenten handelt es sich um den Verleger, die Abonnenten, 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 der Veröffentlichung enthalten, wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Der Batchverarbeitungsserver ist ein Abonnent der Veröffentlichung, der das Schema und die Daten als Abonnement erhält.

  • Wenn der Batchverarbeitungsserver die Ergebnisse an den Onlineverarbeitungsserver zurückgibt, fungiert er ebenfalls als Verleger (normalerweise mit einer Veröffentlichung, die mit derjenigen auf dem Onlineverarbeitungsserver identisch ist), und der Onlineverarbeitungsserver abonniert diese Veröffentlichung.

Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).

SQL Server bietet verschiedenen Replikationstypen für unterschiedliche Anwendungsanforderungen: die Snapshotreplikation, die Transaktionsreplikation und die 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

  • Minimaler Aufwand

Optionen, die bei diesem Szenario in Betracht gezogen werden können, sind Filtern, Peer-to-Peer-Transaktionsreplikation und bidirektionale Transaktionsreplikation:

Schritte für die Implementierung 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:

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: