Dieses Kapitel beschreibt typische Konfigurationen zur Datenreplikation und enthält Beispiele für Replikationslösungen für allgemeine Geschäftsanwendungen. Einige dieser Konfigurationen zeigen, wie andere Produkte zusammen mit DB2 DataPropagator verwendet werden können, um spezifische Replikationslösungen zu erstellen. Die hier dargestellten Replikationskonfigurationen erheben keinen Anspruch auf Vollständigkeit, weil Benutzer immer wieder neue und kreative Einsatzmöglichkeiten finden.
Wichtig: Bei der DB2-Lösung zur Datenreplikation erfolgt die Replikation asynchron. Sie ist daher nicht für die folgenden Anwendungsfälle geeignet:
Sie können individuelle Konfigurationen zusammenstellen, die Ihren speziellen Geschäftserfordernissen gerecht werden. In den folgenden Abschnitten werden die in der Liste aufgeführten Konfigurationen sowie einige Varianten dieser Konfigurationen beschrieben:
Die Replikationskonfigurationen zur Datenverteilung und zur Datenkonsolidierung sind einfacher zu konfigurieren und zu pflegen als Umgebungen zur beliebigen Tabellenreplikation (Update-Anywhere Replication) und Umgebungen mit zeitweise verbundenen Systemen.
In Konfigurationen zur Datenverteilung befindet sich eine primäre Datenquelle auf einem Quellen-Server (siehe Abbildung 2). Alle an der Datenquelle vorgenommenen Änderungen werden in eine oder mehrere Zieltabellen repliziert, die sich an einer beliebigen Position in einem verteilten Netzwerk befinden. Auf die Zieltabellen besteht nur Lesezugriff, d. h., Sie brauchen keine Konflikterkennung zu konfigurieren, weil während der Replikation keine Aktualisierungskonflikte entstehen können. Anwendungen können auf die Zieltabellen zugreifen, die als lokale Kopien vorliegen, d. h., das Netzwerk oder der zentrale Server werden nicht unnötig belastet. Diese Konfiguration verhindert, dass die Leistung Ihrer Anwendungen bei gemeinsamer Datenbenutzung von mehreren Standorten aus gemindert wird.
Abbildung 2. Datenverteilung. An einer Quellentabelle vorgenommene Änderungen werden in Zieltabellen repliziert, für die nur Lesezugriff besteht.
In Konfigurationen zur Datenkonsolidierung wird ein zentraler Server als Repository für Daten aus vielen Datenquellen verwendet (siehe Abbildung 3). Darum besteht diese Konfiguration aus vielen Quellentabellen oder -sichten und einer Zieltabelle mit mehreren untergeordneten Sichten. An den einzelnen Datenquellen vorgenommene Änderungen werden auf den zentralen Daten-Server repliziert, für den nur Lesezugriff besteht.
Einschränkung: Wenn Sie Daten von mehreren Servern in einer CCD-Zieltabelle konsolidieren, dürfen Sie die CCD-Zieltabelle nicht als Replikationsquelle für andere Zieltabellen verwenden. Die Ausgangs-Server verwenden verschiedene Protokollierungsfolgen, die bei der weiteren Replikation nicht voneinander getrennt werden können.
Konfigurationen zur Datenkonsolidierung sind zur Verwaltung eines lokalen Entscheidungshilfesystems geeignet und bieten den Vorteil, dass für die Datenanalyse keine operativen Datenbankressourcen beansprucht werden müssen. Um Aktualisierungskonflikte auszuschließen, müssen Sie die Replikationsumgebung so gestalten, dass für jedes Datenelement nur eine Quelle vorhanden ist. Wenn jede Quelle einen eindeutig definierten Zeilenbereich aktualisiert, können keine Aktualisierungskonflikte entstehen.
Abbildung 3. Datenkonsolidierung. Jede Quellentabelle kann einen eindeutig definierten Zeilenbereich in einer Zieltabelle mit Lesezugriff aktualisieren.
In Konfigurationen zur beliebigen Tabellenreplikation (Update-Anywhere Replication) verfügt eine Replikationsquelle über Zieltabellen mit Schreib-/Lesezugriff. An einer Zieltabelle vorgenommene Änderungen werden auf die Quellentabelle angewendet, die stets den neuesten Stand der Daten enthält. Bei Konflikten zwischen Quelle und Ziel hat die Quelle stets Vorrang. Die Quellentabelle wendet die Änderungen anschließend auf alle zugeordneten Zieltabellen an. Wenn Sie Ihre Anwendung nicht richtig konzipiert haben, können bei der Datenreplikation Konflikte auftreten (siehe Abbildung 4). Optimalerweise sollte die Anwendung so ausgelegt werden, dass beim Replizieren aus der Quellentabelle in alle Zieltabellen keine Konflikte entstehen können (siehe Abbildung 5). Sie haben die Möglichkeit, Konflikte zu ignorieren und Aktualisierungen, die Konflikte verursachen, zurückzuweisen. Beim Zurückweisen von in Konflikt stehenden Aktualisierungen besteht das Risiko von Datenverlusten.
Abbildung 4. Beliebige Tabellenreplikation mit Konfliktrisiko zwischen Zieltabellen. Für diese Konfiguration ist eine Konflikterkennung erforderlich, weil alle Zeilen in der Quellentabelle oder in jeder Zieltabelle aktualisiert werden können.
Abbildung 5. Beliebige Tabellenreplikation ohne Konfliktrisiko zwischen Zieltabellen. Jede Zieltabelle mit Schreib-/Lesezugriff verfügt über einen eindeutigen Zeilenbereich, der lokal aktualisiert werden kann, und in der Quellentabelle auf dem Quellen-Server sind die aktuellsten Daten enthalten.
In Konfigurationen mit zeitweise verbundenen Systemen besteht die Möglichkeit, bei Bedarf Datenverbindungen herzustellen und Daten von bzw. zu einer primären Quelle zu übertragen. Bei solchen Konfigurationen brauchen die Benutzer eine Verbindung zur primären Datenquelle nur genau so lange herzustellen, dass ihre lokale Datenbank synchronisiert werden kann, d. h., die Datenquelle benötigt keine ständige Verbindung für die Replikationsverwaltung (siehe Abbildung 6).
Konfigurationen für zeitweise verbundene Systeme eignen sich besonders zum Synchronisieren von Daten auf Laptop-Computern oder auf Computern an Heimarbeitsplätzen, weil dadurch die Häufigkeit und Dauer der Verbindungen über Kommunikationsleitungen minimiert und die Kosten für Telekommunikationsverbindungen reduziert werden, die Daten aber für die Aktualisierung zur Verfügung stehen. Dieser Konfigurationstyp eignet sich außerdem für die Datenreplikation auf Computern vor Ort, die nicht ständig mit dem Netzwerk verbunden sind (z. B. wenn Mitarbeiter nur drei Tage pro Woche im Büro arbeiten).
Abbildung 6. Zeitweise verbundene Systeme. Die Ziel-Server sind nicht ständig mit dem Quellen-Server verbunden. An den Tabellen vorgenommene Änderungen werden repliziert, wenn der Ziel-Server mit dem Quellen-Server verbunden ist.
Sie können DB2 Universal Database Satellite Edition (oder einen beliebigen anderen DB2-Server, der an einer Satellitenumgebung teilnimmt) zur Verwaltung von Satelliten einsetzen, die zeitweise mit DB2-Servern verbunden sind. Die DB2-Lösung zur Datenreplikation synchronisiert Daten zwischen einem zentralen Steuerungsstandort und vielen Satelliten. Sie richten die Replikationsumgebung an Ihrem Heimarbeitsplatz ein und führen die entsprechenden Tests durch. Wenn die Umgebung dann betriebsbereit ist und für die Zusammenarbeit mit zeitweise verbundenen Systemen vorbereitet ist, speichern Sie die Konfiguration in der Satellitenverwaltungszentrale. Sie greifen nicht direkt auf die zeitweise verbundenen Systeme zu und brauchen die Umgebung nur einmal einzurichten.
Weitere Informationen zum Einrichten einer Replikationsumgebung für Satelliten, zum Aktivieren der Umgebung für die Replikation und zum Durchführen von Replikationstests für einen Satelliten enthält die Veröffentlichung DB2 Universal Database Administering Satellites Guide and Reference.
Auf der Grundlage der beschriebenen allgemeinen Replikationskonfigurationen können Sie Replikationsmodelle erstellen, die Ihren speziellen Erfordernissen entsprechen. Dieser Abschnitt enthält Beispiele für einige, in vielen Unternehmen anzutreffende Geschäftsanforderungen und entsprechende DB2-Replikationslösungen. Dabei werden auch die spezifischen Entwurfsanforderungen der einzelnen Replikationslösungen beschrieben.
Anforderungen: Ein Kunde, der in einer Systemumgebung mit dem DB2-IMS-Transaktionsmanager (TM) arbeitet, generiert Prüfprotokolldaten (Audit Information) durch Aufzeichnen von Prüfinformationen im IMS-Protokoll. Neue Anwendungen greifen über DRDA auf DB2 zu und umgehen dabei den IMS-Transaktionsmanager. Der Kunde muss alle Änderungen an relationalen Tabellen zu Prüfzwecken protokollieren, um zu ermitteln, welche Benutzer jeweils bestimmte Änderungen an den Daten vorgenommen haben.
Replikationslösung: Mit den Programmen Capture und Apply für DB2 DataPropagator werden die von DB2 für OS/390 vorgenommenen Änderungen in Zieltabellen erfasst und gespeichert (siehe Abbildung 7).
Abbildung 7. Prüfprotokolldaten. Die Prüfprotokolldaten werden in eine Zieltabelle repliziert, die von der Anwendung des Kunden gelesen werden kann.
Besondere Merkmale des Entwurfs: Die Vorabbild- und Nachabbildwerte jeder Zeile werden erfasst und gespeichert. Die Berechtigungs-ID des Benutzers, von dem die Daten geändert wurden, wird ebenfalls in den Prüfprotokolltabellen gespeichert. Diese Informationen werden aus dem DB2 für OS/390-Protokoll erfasst.
Anforderungen: Eine große Handelskette hat landesweit etwa 500 Geschäftsstellen, die alle über ein elektronisches Kassensystem (EPOS) Verkaufsdaten sammeln. Jede Geschäftsstelle speichert ihre Daten in lokalen Datenbanken unter DB2 für AIX. Die Daten werden jede Nacht mit einem bereits vorhandenen Dateiübertragungsverfahren von den EPOS-Terminals an einen zentralen DB2 für OS/390-Standort übertragen. Das Unternehmen möchte die Daten in der Zentrale aufbereiten.
Replikationslösung: Die Datenänderungen von jeder Zweigstelle werden mit dem Capture-Programm unter DB2 für AIX erfasst und gespeichert (siehe Abbildung 8). Das Apply-Programm unter DB2 für OS/390 konsolidiert die Daten von allen Zweigstellen und fasst sie zusammen.
Abbildung 8. Konsolidieren von Daten aus verteilten Datenbanken. Daten von drei Quellen-Servern werden in zwei Zieltabellen auf einem Ziel-Server repliziert.
Besondere Merkmale des Entwurfs: Das Apply-Programm verwendet Basisergebnistabellen und CA-Tabellen, um die konsolidierten Daten der Zweigstellen zusammenzufassen. Die Basisergebnistabellen fassen den Inhalt der Quellendateien zusammen. Die CA-Tabellen fassen die Ergebnisse der Änderungen zusammen, die zwischen den einzelnen Aktualisierungen der Zieltabelle durch das Apply-Programm vorgenommen wurden.
Anforderungen: Ein kleineres Bankhaus hat einige neue Client/Server-Anwendungen unter Windows NT in seinen 85 Geschäftsstellen installiert. Eine Hauptdatenquelle für diese neuen Anwendungen sind die Kunden- und Finanzdaten, die an einem Host-Standort in zwei operativen Systemen (eines unter DB2 für OS/390 und ein weiteres unter DB2 für AIX) gespeichert werden. Wenn Geschäftsstellen direkt vom Host-Standort auf die Daten zugreifen würden, käme es zu Engpässen beim Datenaustausch über das Netzwerk, was sich nachteilig auf die Verfügbarkeit der operativen Daten auswirken könnte.
Replikationslösung: Um den Datenaustausch auf dem Netzwerk auf ein Minimum zu reduzieren, wird in jeder Geschäftsstelle eine lokale Kopie der Datenbank verwaltet (siehe Abbildung 9). Dadurch fungiert jede Geschäftsstelle als ein Ziel-Server. Änderungen werden aus DB2 für OS/390 und DB2 für AIX erfasst, in Steuertabellen unter DB2 für AIX komprimiert und jeweils nachts in die Geschäftsstellen repliziert.
Abbildung 9. Verteilen von Daten an ferne Standorte. Quellendaten werden auf einem AIX-Server konsolidiert und in die Geschäftsstellen repliziert. Jede Geschäftsstelle erhält sämtliche Finanzdaten sowie bestimmte Kundendaten. Durch die Verwendung von WHERE-Klauseln wird sichergestellt, dass jede Geschäftsstelle nur die Datensätze für ihre eigenen Kunden erhält.
Besondere Merkmale des Entwurfs: Ein Apply-Programm unter AIX repliziert Daten von DB2 für OS/390 und DB2 für AIX. Es gibt eine Subskriptionsgruppe zum Replizieren der Daten von DB2 für OS/390 in DB2 für AIX und eine für die Datenreplikation von DB2 für AIX in DB2 für AIX.
Ein Apply-Programm befindet sich auf den Ziel-Servern in den einzelnen Geschäftsstellen. Das Apply-Programm auf den Quellen-Servern wird unabhängig von den Apply-Programmen auf den Ziel-Servern ausgeführt. Das Apply-Programm in den einzelnen Geschäftsstellen repliziert Daten aus den Steuertabellen unter DB2 für AIX am Host-Standort. Jedes der Apply-Programme auf den Ziel-Servern verfügt über eine Subskriptionsgruppe zur Replikation vom Host-Standort in die lokale Datenbank. Jede Geschäftsstelle erhält sämtliche Finanzdaten, aber nur bestimmte Kundendaten. Durch die Verwendung von WHERE-Klauseln wird sichergestellt, dass jede Geschäftsstelle nur die Datensätze für ihre eigenen Kunden erhält.
Die Programme Capture und Apply verwalten vollständige, komprimierte CCD-Tabellen unter DB2 für AIX. In dem konkreten Fall wählte der Administrator eine komprimierte CCD-Tabelle, weil diese Art von Zwischenspeichertabelle jeweils nur die zuletzt an der Zeile vorgenommene Änderung enthält und dadurch den Datenaustausch über das Netzwerk während der Replikation reduziert.
Beim Erstellen der Subskriptionsgruppen für jede Geschäftsstelle wurde der Steuerungs-Server vom Administrator auf dem Windows NT-Server platziert. Hätte der Administrator den Steuerungs-Server unter DB2 für AIX installiert, müsste das Apply-Programm jedes Windows NT-Servers über das Netzwerk eine Verbindung zum Host-Standort herstellen, um die Steuerungsinformationen für die Subskriptionsgruppe zu lesen bzw. zu aktualisieren und Änderungen an den Steuerungsinformationen der Subskriptionsgruppe zu erkennen.
Anforderungen: Ein großes Finanzinstitut beabsichtigt, den Informationsfluss aus zwei älteren operativen Systemen in seine OS/2-gestützten Geschäftsstellen zu optimieren. Dabei sollen die Daten zur Unterstützung bei Rechercheaktivitäten für die Kreditvergabe und zur Aufdeckung von Kreditkartenbetrug zuverlässiger und rechtzeitiger bereitgestellt werden. Die Daten für die Kreditvergabe befinden sich auf einem DB2 für OS/390-System, die Einzeldaten zu den Kreditkarten auf einem IMS-System. Frühere Versuche, die vorhandenen Datenbestände zu kopieren, kombinierten punktuelle Berichte und Dateiübertragungsverfahren, sie erwiesen sich aber als nicht praxistauglich.
Replikationslösung: Mit IMS DataPropagator werden die Änderungen an IMS-Daten erfasst und in CCD-Tabellen unter DB2 für OS/390 gespeichert (siehe Abbildung 10). Mit dem Capture-Programm werden die Änderungen erfasst und als DB2 für OS/390-Daten gespeichert. Die gespeicherten Protokolldaten (Historical Data) zeichnen jede vorgenommene Änderung auf. Das in den Geschäftsstellen ausgeführte Apply-Programm verwendet die Protokolldaten von IMS und DB2 für OS/390 zur Verwaltung von DB2 für OS/2-Tabellen.
Abbildung 10. Verteilen von IMS-Daten an relationale Datenbanken. IMS DataPropagator repliziert IMS-Daten in Zieltabellen auf einem OS/390-Quellen-Server. DB2 DataPropagator erfasst Daten auf dem OS/390-Quellen-Server und repliziert sie auf OS/2-Server.
Besondere Merkmale des Entwurfs: IMS DataPropagator erfasst Änderungen aus dem IMS-Protokoll und erstellt eine nicht komprimierte CCD-Tabelle im DB2 DataPropagator-Format auf dem OS/390-Quellen-Server. DB2 DataPropagator verwendet diese CCD-Tabelle als Replikationsquelle. Das Capture-Programm auf dem OS/390-Server erfasst Informationen in den lokalen Tabellen, die die Kreditkartendaten und die Daten zur Kreditvergabe enthalten. Das Apply-Programm auf dem OS/2-Ziel-Server überträgt die Änderungsdaten im Pull-Modus in die Zieltabellen.
Anforderungen: Eine international tätige Bank möchte ihr Online-System rund um die Uhr betriebsbereit halten. Derzeit ist das System 23 Stunden und 45 Minuten pro Tag online. Einmal am Tag muss das System für eine Stapelanwendung stillgelegt werden, die exakt die Datenmenge eines Arbeitstages verarbeitet. Während der fünfzehnminütigen Stilllegung des Systems werden die erforderlichen Tabellen extrahiert. Sobald die Extraktion erfolgt ist, wird das Online-System für den nächsten Geschäftstag verfügbar gemacht.
Replikationslösung: Die im Laufe des Geschäftstages vorgenommenen Änderungen werden erfasst und in CCD-Tabellen gespeichert (siehe Abbildung 11). Die Stapelanwendung wurde im vorliegenden Fall so geändert, dass sie nun Änderungsdaten aus den CCD-Tabellen anstatt aus Extraktionstabellen verarbeitet. Das Online-System muss nicht mehr stillgelegt werden, um konsistente Daten für die Stapelanwendung bereitzustellen.
Abbildung 11. Stapelanwendung, die replizierte Daten verwendet. Die Quellendaten werden in eine CCD-Tabelle repliziert. Die Stapelanwendung extrahiert die Daten aus der CCD-Tabelle, wenn die Quellentabelle nicht verfügbar ist.
Besondere Merkmale des Entwurfs: Die CCD-Tabelle beinhaltet eine Zeitmarke zur Identifizierung der Änderungen, die in einem bestimmten Zeitraum (in diesem Fall ein Tag) vorgenommen wurden.
Anforderungen: Ein Finanzinstitut beabsichtigt, Aktualisierungen seiner Kundendatenbank unter DB2 für AS/400 in ein Entscheidungshilfesystem zu replizieren, das ebenfalls unter DB2 für AS/400 ausgeführt wird. Protokolldaten (Historical Data) zu Aktualisierungen müssen gesichert und ohne Codeänderungen in Geschäftsanwendungen gespeichert werden, ohne die Leistung dieser Anwendungen zu beeinträchtigen.
Replikationslösung: Aktualisierungen der wichtigsten operativen Tabellen werden stündlich erfasst und in CCD-Tabellen des Entscheidungshilfesystems repliziert (siehe Abbildung 12).
Abbildung 12. Replizieren operativer Daten an Systeme zur Entscheidungshilfe. Mit Hilfe der nicht komprimierten CCD-Zieltabelle werden alle an der Quellentabelle vorgenommenen Änderungen aufgezeichnet.
Besondere Merkmale des Entwurfs: Die Programme Capture und Apply verwalten unvollständige, nicht komprimierte CCD-Tabellen. Es werden nicht komprimierte CCD-Tabellen verwendet, weil darin sämtliche, an der Kundendatenbank vorgenommenen Änderungen erfasst werden. Außerdem werden unvollständige CCD-Tabellen verwendet, weil das Finanzinstitut nicht den ursprünglichen Inhalt der Quelle, sondern nur die Änderungen aufzeichnen möchte.
Die Programme Capture und Apply erhalten Jobprioritäten, so dass die Replikation keine operativen CPU-Ressourcen beansprucht. Das Entscheidungshilfesystem könnte genauso einfach auf allen unterstützten Zielplattformen implementiert und bei Bedarf auch auf andere Plattformen übertragen werden.
Anforderungen: Ein Finanzinstitut beschäftigt in mehreren Geschäftsstellen Hunderte von Mitarbeitern, die Kundenkonten durch das Ausfüllen von Online-Formularen einrichten und ändern. Die Mitarbeiter erstellen Ihre Angebote auf der Grundlage von Daten, die von der Hauptgeschäftsstelle generiert und an die Geschäftsstellen übermittelt werden. Des Weiteren senden die Mitarbeiter ihre Berichte zurück an die Hauptgeschäftsstelle, und die Freigabe der Konten erfolgt erst nach Prüfung der Daten durch die Hauptgeschäftsstelle. Dabei wird deutlich, dass die Mitarbeiter noch effizienter arbeiten könnten, wenn sie direkten Zugriff auf die aktuellen Daten hätten und so die Netzwerkprobleme beim Zugriff auf die zentrale Datenbank umgangen werden könnten.
Replikationslösung: Mit Hilfe einer speziellen Art von Zieltabelle, der so genannten Replikattabelle, werden Subskriptionen für eine rückwirkende Replikation eingerichtet (Abbildung 13). Hierbei werden Änderungen an der Replikattabelle in die primäre Replikationsquelle, die eine Benutzertabelle ist, zurückrepliziert. Eine an einem Standort vorgenommene Aktualisierung wird in die Datenbanken an anderen Standorten übernommen. Die Mitarbeiter erhalten aktuelle Informationen und können die Konten direkt beim Kundengespräch fertig stellen, und die Hauptgeschäftsstelle verfügt über neue Geschäftsdaten, die noch an demselben Tag generiert werden.
Abbildung 13. Beliebige Tabellenreplikation. Die primäre Datenquelle (das Elternreplikat) befindet sich auf einem OS/390-Server, die abhängigen Replikate befinden sich auf Windows NT-Client-Systemen.
Besondere Merkmale des Entwurfs: Die primäre Replikationsquelle ist eine Benutzertabelle. Sie enthält die aktuellsten Daten.
Replikationsszenarios dieser Art arbeiten optimal, wenn Transaktionskonflikte zwischen der zentralen Datenbank und den aktualisierbaren Kopien vermieden werden (z. B. wenn Replikate nur Schlüsselbereiche an bestimmten Standorten aktualisieren können oder wenn die verschiedenen Standorte nur zu bestimmten Zeiten Aktualisierungen vornehmen können).
DB2 DataPropagator erkennt Konflikte, die beim Aktualisieren der gleichen Zeile auf dem Host-System und auf einem System in einer Geschäftsstelle entstehen, wenn keine dieser Änderungen repliziert wurde. Wenn von einem Mitarbeiter Aktualisierungen vorgenommen wurden, die zu einem Konflikt führen, werden diese Aktualisierungen beim Replizieren gelöscht, um die Datenintegrität zu gewährleisten. Die Transaktion, die den Konflikt beinhaltet, und alle von ihr abhängigen Transaktionen werden zurückgesetzt.
Anforderungen: Ein Versicherungsunternehmen beabsichtigt, seine Mitarbeiter im Außendienst und die Versicherungsagenten, die nur selten in die Unternehmenszentrale kommen, mit attraktiven Angeboten für Kunden und Interessenten (spezielle Einführungsangebote und individuelle Paketangebote) auszustatten. Die Computer der Mitarbeiter sind jeweils nur für kurze Zeit mit dem Computer der Firmenzentrale verbunden. Während dieser Verbindungszeit müssen alle aktualisierten Informationen von der zentralen Datenbank übermittelt werden. Hier ist eine Lösung zum Beheben möglicher Änderungsrückstände erforderlich.
Replikationslösung: Die Außendienstmitarbeiter verfügen über Laptop-Computer mit DB2 Universal Database Satellite Edition. Beim Start einer Verkaufskampagne kann jeder Agent die Kundenprofile und statistischen Daten sowie die neuesten Produktangebote abrufen. Die DB2-Lösung zur Datenreplikation sorgt auch hier dafür, dass die Daten auf dem neuesten Stand gehalten werden. Nur neue und geänderte Datenzeilen werden über das Netzwerk repliziert.
Besondere Merkmale des Entwurfs: Das Produkt DB2 Universal Database Satellite Edition wird verwendet, weil es die Replikationsanforderungen erfüllt und von einem zentralen Administrator verwaltet werden kann. Ein Administrator in der Unternehmenszentrale konfiguriert die Replikationsumgebung, testet sie und kopiert sie auf die zeitweise verbundenen Systeme. Der Administrator stellt außerdem die Benutzer-IDs und Kennwörter bereit, mit denen die Mitarbeiter im Außendienst über ihre Laptop-Computer die Verbindung zum Server in der Unternehmenszentrale herstellen können. Wenn die Verbindung besteht, können die Mitarbeiter auf Knopfdruck die Daten ihrer Laptop-Computer mit den Daten des Quellen-Servers synchronisieren.
Anforderungen: Ein Fertigungsunternehmen verwendet eine Oracle-Anwendung zur Verarbeitung von Kundenaufträgen und DB2 für OS/390 für den zentralen operativen Datenspeicher. Neue Auftragsinformationen werden über Nacht im Stapelbetrieb in die DB2-Datenbank hochgeladen. Das Unternehmen möchte nun, dass die Daten früher repliziert werden, um die Aufträge der Kunden schneller bearbeiten zu können.
Replikationslösung: So genannte Auslöser in den Oracle-Tabellen simulieren das Capture-Programm, indem sie die geänderten Sätze in CCD-Tabellen auf dem Oracle-Server speichern. Unter Verwendung von Kurznamen in DataJoiner erscheinen die Oracle-Quellentabellen und CCD-Tabellen wie Tabellen in einer DB2-Datenbank, so dass sie das Apply-Programm für OS/390 in DB2 für OS/390-Tabellen replizieren kann. Im vorliegenden Fall wird das Apply-Programm so eingestellt, dass es die Daten während der Geschäftszeiten stündlich repliziert.
Abbildung 14. Abrufen von Daten aus einem verteilte Datenspeicher eines anderen Herstellers. Zur Erfassung der Änderungen an den Quellentabellen in Oracle werden Auslöser verwendet, und DataJoiner übernimmt die Aufgabe, die Daten in die DB2 für OS/390-Zieltabellen zu replizieren.
Besondere Merkmale des Entwurfs: Mit DataJoiner Replication Administration (DJRA) werden die Capture-Auslöser und die CCD-Tabellen in der Oracle-Datenbank definiert. DJRA generiert außerdem SQL-Anweisungen, mit denen alle Datenbankobjekte und Datentypzuordnungen (Data Type Mappings) erstellt werden können. DataJoiner ermöglicht dem Apply-Programm denselben Zugriff auf Daten in Datenbanken anderer Hersteller, wie er bei DB2-Datenbanken möglich ist. Das Apply-Programm kann zudem unter DB2 für OS/390 im Pull-Modus verwendet werden.
Anforderungen: Eine große Einzelhandelskette betreibt ihre Anwendung für das operative Geschäft auf einem Großrechner, der ein DB2 für OS/390-Subsystem verwendet. Die Mitarbeiter in den Filialen und in der Zentrale müssen die operativen Daten abfragen, um Berichte erstellen zu können. Das Einzelhandelsunternehmen benötigt nun eine Lösung, mit der die Daten, die für Abfrage und Berichterstellung erforderlich sind, in ein Informix-Datenbankverwaltungssystem auf einem UNIX-Server repliziert werden können. Dabei dürfen die Daten, auf denen die Berichte und Abfrageergebnisse basieren, nicht älter als vier Stunden sein.
Replikationslösung: Das Capture-Programm speichert die Änderungen an den operativen Daten in DB2 für OS/390-Tabellen. Die Ablaufsteuerung für die Subskription wird auf ein 4-Stunden-Intervall eingestellt, um zu gewährleisten, dass die Abfrageergebnisse und Berichte auf aktuellen operativen Daten basieren. Unter Verwendung von DataJoiner-Kurznamen repliziert das Apply-Programm die Änderungen in den DB2-Tabellen in die Abfrage- und Berichtstabellen in der Informix-Datenbank.
Abbildung 15. Beispiel für die Replikation operativer Daten in eine Berichts- und Abfragedatenbank eines anderen Herstellers. Die Änderungen an den DB2 für OS/390-Quellentabellen werden unter Verwendung von DataJoiner-Kurznamen erfasst und in die Informix-Zieltabellen repliziert.
Besondere Merkmale des Entwurfs: Mit DataJoiner Replication Administration (DJRA) werden die Informix-Zieltabellen mit den richtigen Informix-Datentypen erstellt. Das Apply-Programm repliziert die Daten unter Verwendung von DataJoiner in die Informix-Datenbank und nimmt dabei alle erforderlichen Datentypumsetzungen vor.