Dieses Kapitel enthält alle Informationen, die Sie benötigen, um Ihre Replikationsumgebung zu planen. Dazu gehören Informationen zur Kapazitäts-, Speicher- und Netzwerkplanung, zum Festlegen der zu replizierenden Daten und zur Protokollierung zu Prüfzwecken sowie zum Zwischenspeichern von Daten und zur Migrationsplanung.
Das Capture-Programm nimmt in der Regel keinen Einfluss auf andere Anwendungen und hat nur einen minimalen Bedarf an CPU-Ressourcen bzw. CPC-Kapazität (CPC = Central Processing Complex). Sie können Capture für OS/390 zum Beispiel mit einer geringeren Priorität ausführen als Anwendungsprogramme, die Quellentabellen aktualisieren. In diesem Fall wird das Capture-Programm verzögert ausgeführt, wenn nur begrenzte CPU-Ressourcen zur Verfügung stehen.
Das Capture-Programm beansprucht CPU-Ressourcen zum Bereinigen der CD-Tabellen und der UOW-Tabelle; diese Aktivität kann jedoch verzögert ausgeführt werden, um das System zu entlasten.
Das Apply-Programm wirkt sich auf die Auslastung der CPU abhängig von der Replikationsfrequenz aus, d. h. abhängig von den Anforderungen der Zieldatenbank an die Aktualität der Daten. Das Apply-Programm liest Daten vom Quellen-Server und kopiert sie auf den Ziel-Server. Dadurch werden CPU-Ressourcen auf beiden Systemen beansprucht.
Die DB2-Steuerzentrale und DJRA (DataJoiner Replication Administration) beanspruchen im Allgemeinen nur wenig lokale CPU-Ressourcen. Beim Generieren des SQL-Codes für Replikationsquellen und Subskriptionsgruppendefinitionen führt DB2 DataPropagator jedoch umfangreiche Suchvorgänge in den Katalogen des Quellen-Servers aus. Bei Standorten mit großen Datenbeständen kann dies zu einer deutlich höheren Auslastung der CPU oder des Datenbanksystems führen.
Empfehlungen: Die Aktivitäten der Replikationsverwaltung sollten für einen Zeitpunkt geplant werden, zu dem die Auslastung der Quellen- und Zieldatenbanksysteme gering ist. Minimieren Sie durch Filtern die vom Quellen-Server zurückgegebene Datenmenge.
Neben dem für DB2 erforderlichen Speicherbedarf wird bei der Replikation zusätzlicher Speicherplatz benötigt, und zwar für
Wenn nicht genug Plattenspeicherplatz für die Übergabedateien vorhanden ist, wird das Apply-Programm beendet. Wenn Sie angeben, dass das Apply für OS/390 Hauptspeicher verwenden soll, der verfügbare Hauptspeicher jedoch für die Übergabedateien nicht ausreicht, wird das Apply-Programm abgebrochen. Geben Sie in diesem Fall an, dass das Apply-Programm Plattenspeicherplatz verwenden soll, und starten Sie das Programm erneut. Weitere Informationen hierzu finden Sie im Abschnitt Übergabedateien.
Alle Größenangaben in den folgenden Abschnitten sind Schätzwerte. Beim Vorbereiten und Einrichten eines betriebsbereiten Systems müssen noch weitere Faktoren (wie z. B. Maßnahmen zur Fehlervermeidung) berücksichtigt werden. Beispielsweise könnte es erforderlich sein, den Aufbewahrungszeitraum für Daten (dieser wird im Abschnitt Zieltabellen und Steuertabellen behandelt) zu verlängern, um möglichen Leitungsausfällen zu begegnen.
Wenn die Schätzwerte für den Speicherbedarf zu hoch erscheinen, sollten Sie die Häufigkeit der Ausführung des Apply-Programms (d. h. Ihrer Subskriptionen) und der Bereinigung nochmals überprüfen. Die Faktoren Speicherauslastung, Kapazität für die Fehlertoleranz und CPU-Systemaufwand müssen immer wieder gegeneinander abgewogen werden.
Bevor Sie eine Tabelle replizieren können, müssen Sie sie mit den Schlüsselwörtern DATA CAPTURE CHANGES erstellen (oder ändern). Eine Auswirkung der Angabe dieser Schlüsselwörter ist, dass DB2 für jede UPDATE-Anweisung vollständige Zeilenabbilder protokolliert. Für eine Replikattabelle (in einem Szenario mit beliebiger Tabellenreplikation) protokolliert DB2 außerdem Vorabbilder für jede Aktualisierung der Tabelle. Zusätzliche Protokoll- oder Journaldaten werden außerdem generiert, wenn DB2 das Einfügen oder Löschen von Daten in UOW-Tabellen (Unit-Of-Work Tables) und CD-Tabellen (Change Data Tables) protokolliert.
Obwohl die Zunahme der Protokoll- oder Journaldaten nicht leicht abzuschätzen ist, kann davon ausgegangen werden, dass zusätzlich das Dreifache des aktuellen Protokollvolumens für alle an der Replikation beteiligten Tabellen erforderlich ist.
Für eine genauere Schätzung des Speicherbedarfs werden Detailkenntnisse der Aktualisierungsanwendung und der Replikationsanforderungen benötigt. Wenn in der Regel 60% der Spalten einer Tabelle von einer Anwendung aktualisiert werden, könnte sich auf Grund dieser Replikationsanforderungen im Vergleich zu einer ähnlichen Tabelle, die nicht repliziert wird, bei den Protokollsätzen ein Zuwachs von mehr als der Hälfte ergeben. Eine der Replikationsanforderungen, die das Protokoll am stärksten anwachsen lässt, ist das Erfassen der Vor- und Nachabbilder (wie z. B. in Szenarios für die beliebige Replikation). Eine Möglichkeit zum Reduzieren des Protokollspeicherbedarfs ist das Verringern der für die Replikationsquelle definierten Spaltenzahl.
Eine Protokollierung wird nicht nur für die Quellendatenbank, sondern auch für die Zieldatenbank ausgeführt, in der die Zeilen angewendet werden. Da das Apply-Programm keine Zwischenprüfpunkte anlegt, sollten Sie die maximale Datenmenge, die vom Apply-Programm innerhalb eines Zeitintervalls verarbeitet wird, schätzen und den Speicherbereich für die Protokollierung (bei AS/400 den Speicherbereich des aktuellen Empfängers) so dimensionieren, dass er diese Datenmenge aufnehmen kann.
Wenn unter VM und VSE die aktive Protokolldatei voll ist, archiviert DB2 deren Inhalt. Wenn auf einem System IBM AS/400 der aktuelle Empfänger voll ist, schaltet das System auf einen neuen Empfänger um; wahlfrei können Sie ältere Empfänger, die nicht mehr für die Replikation benötigt werden, sichern und löschen. Wenn das System eine große Anzahl Transaktionen verarbeiten muss, kann dies zu einem Verarbeitungsrückstand des Capture-Programms führen. Ist das Protokoll zu klein, könnte ein Teil der Protokollsätze vor der Erfassung archiviert werden. Capture für VSE und VM kann bei Ausführung unter DB2 für VSE & VM keine Archivprotokolldateien wiederherstellen. 13
Wenn Sie mit DB2 für VSE & VM arbeiten, muss das Protokoll so groß sein, dass es mindestens für die innerhalb von 24 Stunden anfallenden Transaktionsdaten ausreicht. Wenn Sie mit DB2 für AS/400 arbeiten, muss der aktuelle Empfänger mindestens die Daten verarbeiten können, die innerhalb von 24 Stunden anfallen.
Der Speicherbedarf für eine Zieltabelle ist normalerweise nicht größer als für die Quellentabelle (oder -tabellen). Er kann jedoch deutlich höher sein, wenn die Zieltabelle entnormalisiert wird bzw. Vorabbilder (zusätzlich zu Nachabbildern) oder Protokolldaten enthält. Die folgenden Faktoren beeinflussen ebenfalls den Speicherbedarf für eine Zieltabelle: die Anzahl der replizierten Spalten, der Datentyp der replizierten Spalten, die für den Subskriptionsgruppeneintrag definierten Zeilenuntermengen und die während der Replikation ausgeführten Datenumsetzungen.
Die CD-Tabellen und die UOW-Tabelle beeinflussen ebenfalls den Speicherbedarf für eine Quellendatenbank. Der Speicherbedarf der Replikationssteuertabellen ist normalerweise gering, da jede Tabelle nur aus wenigen Zeilen besteht.
Die Größe der CD-Tabellen nimmt entsprechend der Datenmenge zu, die bis zu der vom Capture-Programm ausgeführten Bereinigung repliziert wird. Um den Speicherbedarf der CD-Tabellen zu schätzen, ermitteln Sie zunächst, wie lange die Daten aufbewahrt werden sollen, bevor sie gelöscht werden, und geben Sie danach an, wie häufig das Capture-Programm diese Tabellen bereinigen soll bzw. wie häufig der Befehl prune abgesetzt wird. Die Mindestgröße der CD-Tabelle können Sie anhand der folgenden Formel ermitteln:
mindestgröße der CD-tabelle = ( (21 byte) + summe(länge aller registrierten spalten) ) * (anzahl der einfügungen, aktualisierungen und löschungen in quellentabelle) ) * (ausnahmefaktor)
Beim Berechnen der replizierten Datenmenge (in Byte) müssen Sie 21 Byte für zusätzliche Daten (Overhead) einplanen, die den CD-Tabellen vom Capture-Programm hinzugefügt werden. Die Anzahl der in der obigen Formel angegebenen Einfügungen, Aktualisierungen und Löschvorgänge in der Quellentabelle beziehen sich auf das Intervall zwischen dem Erfassen und Bereinigen der Daten. Der Ausnahmefaktor berücksichtigt unvorhersehbare Ereignisse wie z. B. Netzwerkausfälle oder andere Störungen, die das Apply-Programm daran hindern, Daten zu replizieren. Verwenden Sie zunächst den Wert 2, und passen Sie diesen Wert später an die Verarbeitungsleistung Ihrer Replikationsumgebung an.
Beispiel: Wenn das Capture-Programm die angewendeten Zeilen der CD-Tabelle einmal täglich bereinigt, dauert Ihr Intervall 24 Stunden. Wenn die Zeilen in der CD-Tabelle 100 Byte lang sind (plus 21 Byte für Systemaufwand) und innerhalb von 24 Stunden 100 000 Aktualisierungen erfolgen, beträgt der Speicherbedarf der CD-Tabelle etwa 12 MB.
Die maximale Größe einer CD-Tabelle hängt davon ab, welche maximale
Spaltenzahl und Zeilengröße in DB2 für die verwendete Plattform zulässig
ist. Tabelle 4 zeigt, wie die maximale Größe für eine CD-Tabelle
berechnet wird. Für Replikattabellen sind die maximale Spaltenzahl und
die maximale Zeilenlänge durch zwei zu dividieren, da die CD-Tabelle für eine
Replikattabelle auch Spalten für Vorabbilder enthält.
Tabelle 4. Maximalgröße für CD-Tabelle berechnen
Der Wert maxCols gibt die maximale in DB2 für eine Tabelle zulässige Spaltenzahl an, der Wert maxLength gibt die in DB2 zulässige maximale Zeilenlänge an. | ||
Für Zieltabellen mit Lesezugriff | Für Zieltabellen (Replikat) mit Schreib- und Lesezugriff | |
---|---|---|
Anzahl Spalten | maxCols - 3 Spalten | (maxCols - 3 Spalten) / 2 |
Zeilenlänge | maxLength - 21 Byte | (maxLength - 21 Byte) / 2 |
Die UOW-Tabelle nimmt entsprechend der innerhalb eines bestimmten Zeitintervalls eingefügten Zeilen zu bzw. ab (d. h. entsprechend der Anzahl der in diesem Intervall erfolgten Festschreibungen, die durch Transaktionen zur Aktualisierung von Quellentabellen oder durch das Programm Capture für AS/400 ausgeführt wurden). Setzen Sie den Schätzwert für die erforderliche Größe zunächst etwas höher an, und überwachen Sie dann den tatsächlich genutzten Speicherplatz, um festzustellen, ob Speicherplatz eingespart werden kann. Die Zeilengröße in der UOW-Tabelle ist auf 79 Byte festgesetzt (außer bei DB2 für AS/400: dort beträgt die Größe 109 Byte). Einen ersten Näherungswert für den Speicherbedarf der UOW-Tabelle erhalten Sie durch Multiplizieren des Werts von 79 Byte (bzw. 109 Byte) mit der Anzahl der Aktualisierungen, die im Zeitraum von zwei Stunden ausgeführt werden. Anhand einer Formel, die der oben für CD-Tabellen angegebenen Formel ähnlich ist, können Sie einen genaueren Schätzwert für den Speicherbedarf der UOW-Tabelle ermitteln. Weitere Informationen finden Sie im Abschnitt UOW-Tabelle (Unit-Of-Work Table).
Das Apply-Programm speichert Aktualisierungen von Zieltabellen in temporären Dateien, die als Übergabedateien bezeichnet werden. 14 In diesen Dateien werden die Aktualisierungen aufbewahrt, bis sie vom Apply-Programm auf die Zieltabellen angewendet werden. Das Apply-Programm verwendet für Subskriptionsgruppen mit mehreren Subskriptionsgruppeneinträgen eine Übergabedatei pro Zieltabelle. Die Übergabedatei wird bei allen Betriebssystemen auf den Plattenspeicher gestellt, nur das Programm Apply für OS/390 kann hierfür stattdessen virtuellen Speicher verwenden. Sofern genügend virtueller Speicher vorhanden ist, sollten Sie die Übergabedatei unbedingt in den virtuellen Speicher stellen und nicht auf die Platte.
Die Größe der Übergabedatei entspricht der Datenmenge, die innerhalb eines Replikationsintervalls zum Replizieren ausgewählt wird. Einen Schätzwert für den Speicherbedarf der Übergabedatei erhalten Sie durch einen Vergleich des für das Apply-Programm geplanten Ausführungsintervalls (auch Datenblockungsintervall, vgl. Abschnitt Datenblockung bei hohem Änderungsaufkommen) mit dem Änderungsaufkommen innerhalb dieses Zeitraums (oder eines Zeitraums mit besonders vielen Änderungen). Die Zeilenlänge der Übergabedatei ergibt sich aus der Länge der Zielzeile einschließlich aller zusätzlichen Spalten (Overhead Columns), die von DB2 DataPropagator benötigt werden. Diese Zeilenlänge basiert nicht auf dem komprimierten internen DB2-Format, sondern auf dem erweiterten interpretierten Zeichenformat, das beim Auswählen (SELECT) abgerufen wird. Die Zeile enthält außerdem eine Zeilenlängenangabe und Nullabschlusszeichen für einzelne Spaltenzeichenfolgen.
Beispiel: Wenn der Spitzenwert bei 12 000 Aktualisierungen pro Stunde liegt und das Apply-Programm jede Stunde ausgeführt wird, muss die Übergabedatei alle in einer Stunde auflaufenden Aktualisierungen (also 12 000 Aktualisierungen) aufnehmen können. Wenn jede Aktualisierung einer Datenmenge von 100 Byte entspricht, beträgt die Größe der Übergabedatei 1,2 MB.
In diesem Abschnitt werden verschiedene Konnektivitätsanforderungen und die durch Datenblockung mögliche Leistungsoptimierung behandelt. Außerdem werden verschiedene Möglichkeiten zur Ausführung des Apply-Programms (mit Push- oder Pull-Konfiguration) beschrieben.
Da die Datenreplikation normalerweise in physisch getrennten Datenbanken erfolgt, sind die Konnektivitätsanforderungen ein wichtiger Faktor bei der Planung. Die Workstation, auf der die DB2-Steuerzentrale oder DJRA ausgeführt wird, und das Apply-Programm müssen eine Verbindung zu den Steuerungs-, Quellen- und Ziel-Server-Datenbanken herstellen können.
Wenn die Datenbanken an ein Netzwerk angeschlossen sind, ergeben sich je nach Plattform die folgenden Möglichkeiten der Konnektivität:
Wenn Sie unter DB2 für OS/390 mit der Funktion zur Schlüsselwortprüfung arbeiten, verwenden Sie DCS (Data Communication Service), indem Sie die Angabe DCS zur Anweisung CATALOG DB hinzufügen. Wenn Sie die Verbindung über das SNA-Protokoll herstellen, fügen Sie der Anweisung CATALOG APPC NODE die Angabe SECURITY PGM hinzu. Wenn der Verbindungsaufbau jedoch über TCP/IP erfolgt, gibt es kein gleichwertiges Sicherheitsschlüsselwort für die Anweisung CATALOG TCPIP NODE.
Wenn Ihr Replikationsentwurf das Bereitstellen von Daten auf einem Server beinhaltet, der nicht mit der Quellendatenbank identisch ist, müssen Sie die Kommunikation zwischen den verschiedenen Servern sorgfältig planen. Beispiel: In einem Replikationsszenario für zeitweise verbundene Systeme, bei dem eine Verbindung zwischen DB2 Universal Database unter Windows 95 auf einem Laptop-Computer und DB2 für OS/390 hergestellt wird, sollte sich die mobile Windows 95-Maschine zunächst unter Verwendung eines Modems über das TCP/IP-Protokoll bei einem lokalen Server (beispielsweise einem AIX-Server mit DB2 Universal Database Enterprise Edition) einwählen. Die AIX-Workstation stellt anschließend die Verbindung zu DB2 für OS/390 her, um die Anfrage der Windows 95-Maschine zu erfüllen.
Begrenzen Sie auf jeden Fall die erforderlichen Emulationsebenen, LAN-Brücken und Router-Verbindungen, weil sie sich nachteilig auf die Replikationsleistung auswirken können.
Sie können das Apply-Programm auf dem Quellen-Server oder auf dem Ziel-Server ausführen. Wenn das Apply-Programm auf dem Quellen-Server ausgeführt wird, liegt eine Push-Konfiguration vor, d. h., das Apply-Programm überträgt die Aktualisierungen vom Quellen-Server zum Ziel-Server. Wenn das Apply-Programm auf dem Ziel-Server ausgeführt wird, liegt eine Pull-Konfiguration vor, d. h., das Apply-Programm ruft die Aktualisierungen vom Quellen-Server ab und überträgt sie auf den Ziel-Server.
Das Apply-Programm kann in einer der beschriebenen Konfigurationen oder auch in einer Kombination aus Push- und Pull-Konfiguration ausgeführt werden, d. h., es kann Aktualisierungen für bestimmte Subskriptionsgruppen im Pull-Modus ausführen und für andere Subskriptionsgruppen im Push-Modus.
Wenn die Zieltabelle keine IBM Datenbank ist, stellt das Apply-Programm die Verbindung zu einer DB2 DataJoiner-Datenbank her (wobei DB2 DataJoiner mit der Datenbank des anderen Herstellers verbunden ist) und wendet die Änderungen über DB2 DataJoiner-Kurznamen auf die Zieltabelle an. In diesem Fall überträgt das Apply-Programm die Aktualisierungen im Push-Modus vom DB2 DataJoiner-Quellen-Server auf den Ziel-Server oder im Pull-Modus vom DB2 DataJoiner-Quellen-Server auf den Ziel-Server. Das Apply-Programm kann weder im Push- noch im Pull-Modus Aktualisierungen direkt von einem Server eines anderen Herstellers übertragen.
Abbildung 16 zeigt die Unterschiede zwischen der Push- und der Pull-Konfiguration.
Abbildung 16. Push- oder Pull-Konfiguration
Bei der Push-Konfiguration stellt das Apply-Programm eine Verbindung zum lokalen Quellen-Server (bei Quellen anderer Hersteller zu einem DB2 DataJoiner-Quellen-Server) her, um die Daten abzurufen. Danach stellt es eine Verbindung zu dem fernen Ziel-Server her und überträgt die Aktualisierungen im Push-Modus in die Zieltabelle. Das Apply-Programm überträgt die Aktualisierungen zeilenweise. Dabei kann es nicht auf den DB2-Blockabruf (Block Fetch) zurückgreifen, um eine effizientere Netzwerknutzung zu erzielen.
Bei der Pull-Konfiguration stellt das Apply-Programm eine Verbindung zu dem fernen Quellen-Server (bei Quellen anderer Hersteller zu einem DB2 DataJoiner-Quellen-Server) her, um die Daten abzurufen. DB2 kann dabei den Blockabruf (Block Fetch) verwenden, um die Daten effizient über das Netzwerk zu übermitteln. Sobald alle Daten abgerufen wurden, stellt das Apply-Programm eine Verbindung zu dem lokalen Ziel-Server her und wendet die Änderungen auf die Zieltabelle an.
In der Regel werden bei der Pull-Konfiguration bessere Leistungswerte erzielt als bei der Push-Konfiguration, weil das Netzwerk effizienter genutzt wird. In den folgenden Fällen ist jedoch die Push-Konfiguration vorzuziehen:
Zum Einrichten einer Push- oder Pull-Konfiguration sind keine speziellen Konfigurationsschritte erforderlich. Sie müssen nur festlegen, wo das Apply-Programm ausgeführt wird. DB2 DataPropagator, die DB2-Steuerzentrale und DJRA erkennen beide Konfigurationen.
Replikationssubskriptionen, die umfangreiche Änderungsblöcke in einem einzigen Apply-Zyklus replizieren, können zu einem Überlauf der Übergabedateien oder der Protokolldatei (für die Zieldatenbank) führen. Beispielsweise können Szenarios mit Apply-Stapelverarbeitung zu einem erheblichen Verarbeitungsrückstand anstehender Transaktionsreplikationen führen. Oder durch einen längeren Ausfall des Netzwerks kann in den CD-Tabellen ein umfangreicher Datenblock zur Verarbeitung auflaufen, der einen Überlauf der Übergabedateien verursacht.
Auf der Seite Datenblockung im Notizbuch Ablaufsteuerung für Subskription der DB2-Steuerzentrale oder im Feld Blocking Factor des DJRA-Fensters Create Empty Subscription Sets können Sie angeben, wie viele Änderungsdaten (die einer bestimmten Anzahl von Minuten entsprechen) in einem Subskriptionszyklus vom Apply-Programm repliziert werden können. Die von Ihnen angegebene Zeitdauer (Anzahl Minuten) entscheidet über die Größe des Datenblocks. 15 Dieser Wert wird in der Spalte MAX_SYNCH_MINUTES der Tabelle für Subskriptionsgruppen gespeichert. Wenn die aufgelaufenen Änderungsdaten die Größe des Datenblocks überschreiten, unterteilt das Apply-Programm einen Subskriptionszyklus in mehrere kürzere Zeitabschnitte (Mini-Cycles), um den Rückstand zu verringern und verarbeitungsfähige Mengen zu erzielen. Außerdem wiederholt das Programm alle nicht erfolgreich ausgeführten Abschnitte und passt die Größe des Datenblocks an die verfügbaren Systemressourcen an. Wenn die Replikation eines solchen Zeitabschnitts fehlschlägt, wiederholt das Apply-Programm die Subskriptionsgruppe ab dem letzten erfolgreichen Abschnitt. Abbildung 17 zeigt, wie die geänderten Daten in Untermengen aufgeteilt werden.
Abbildung 17. Datenblockung. Der Datenaustausch über das Netzwerk kann durch Angabe eines Werts für die Datenblockung reduziert werden.
Standardmäßig verwendet das Apply-Programm keine Datenblockung, d. h., es kopiert alle verfügbaren festgeschriebenen Daten, die erfasst wurden. Wenn Sie einen Wert für die Datenblockung definieren, sollte die von Ihnen angegebene Dauer (Anzahl Minuten) so kurz sein, dass sämtliche in diesem Zeitraum für die Subskriptionsgruppe ausgeführten Transaktionen kopiert werden können, ohne eine Kapazitätsüberschreitung der Übergabedateien oder des Protokolls zu verursachen. Stellen Sie beim Arbeiten in einer AS/400-Umgebung sicher, dass die Gesamtsumme der in diesem Zeitraum zu replizierenden Daten nicht größer als 4 MB ist.
Einschränkungen:
Bei der Replikationsplanung ist unter anderem auch zu berücksichtigen, wie die Daten am Zielstandort verwendet werden sollen. In vielen Fällen müssen die Quellendaten für Entscheidungshilfeprogramme oder Data Warehousing-Anwendungen unterteilt, umgesetzt oder modifiziert werden. In diesem Abschnitt wird dargestellt, welche dieser Aufgaben mit der DB2-Steuerzentrale oder DJRA ausgeführt werden können und welche ein direktes Bearbeiten der Steuertabellen erfordern.
Die Steuerzentrale und DJRA unterstützen folgende Aktivitäten zur Datenbearbeitung:
In den folgenden Abschnitten wird dargestellt, welche Datenbearbeitungsaktivitäten mit der Steuerzentrale oder DJRA ausgeführt werden können. Außerdem werden in diesem Kapitel die Replikation großer Objekte (LOB), Begrenzungen für die Spaltennamen bei Vorabbilddaten und allgemeine Einschränkungen bei der Datenreplikation behandelt.
Die DB2-Lösung zur Datenreplikation ermöglicht die Unterteilung der Quellentabelle in Spaltenuntermengen (vertikale Unterteilung) und in Zeilenuntermengen (horizontale Unterteilung). Das heißt, Sie können angeben, dass nur ein Teil der Spalten und Zeilen aus der Quellentabelle in die Zieltabelle repliziert wird (und nicht alle Spalten und Zeilen):
Zu folgenden Zeitpunkten können Sie Spaltenuntermengen definieren:
Wählen Sie in diesem Fall nur die Spalten aus, die Sie für die Replikation in eine Zieltabelle verfügbar machen wollen. Da CD-Tabellen genügend Schlüsseldaten für Tabellen mit Zeitangabe enthalten müssen, sind Primärschlüsselspalten in die Untermenge aufzunehmen. Alle Spalten, die Sie nicht auswählen, stehen den Zieltabellen nicht für die Replikation zur Verfügung.
Bei Verwendung der Steuerzentrale wählen Sie mit Hilfe der erweiterten Subskriptionsoptionen nur die Spalten aus, die in die Zieltabelle repliziert werden sollen. Für DJRA können Sie die Spalten beim Hinzufügen von Elementen zur Subskriptionsgruppe auswählen. Die nicht ausgewählten Spalten stehen weiterhin für andere Subskriptionsgruppen zur Verfügung, werden jedoch nicht für die aktuelle Subskriptionsgruppe verwendet.
Empfehlung: Wählen Sie beim Definieren einer Subskriptionsquelle alle Spalten aus (d. h., es werden keine Spaltenuntermengen gebildet). Erstellen Sie die gewünschten Spaltenuntermengen stattdessen beim Definieren von Subskriptionsgruppen. Durch das Definieren der Spaltenuntermengen innerhalb der Subskriptionsgruppen (und nicht in den Replikationsquellen) ersparen Sie sich das erneute Definieren Ihrer Replikationsquellen, wenn sich die Subskriptionsanforderungen ändern.
Verwenden Sie dazu beim Definieren der Subskription die erweiterten Subskriptionsoptionen, um eine WHERE-Klausel zu definieren. Alle Arten von Zieltabellen unterstützen das Bilden horizontaler Untermengen.
Wenn die Primärschlüsselwerte der Zieltabelle aktualisiert werden oder die Tabelle (oder Sicht) eine logische Partitionierungsspalte enthält, die aktualisiert wird, müssen Sie beim Definieren der Replikationsquelle die Unterstützung für logische Partitionierungsschlüssel bei der Replikation aktivieren. Die Unterstützung für logische Partitionierungsschlüssel bei der Replikation führt eine UPDATE-Anweisung als Kombination aus einer DELETE-Anweisung und einer anschließenden INSERT-Anweisung aus. Weitere Informationen finden Sie im Abschnitt Aktivieren der Unterstützung logischer Partitionierungsschlüssel bei der Replikation.
Verknüpfungssichten können zu den unterschiedlichsten Zwecken eingesetzt werden, so beispielsweise zur Entnormalisierung (Umstrukturierung) von Kopien in Data-Warehouse-Szenarios (sie vereinfachen das Abfragen der kopierten Daten) oder auch bei der Lösung des Weiterleitungsproblems (in Szenarios mit verteilten Systemen auch als Datenbankpartitionierungsproblem bezeichnet). 16 Sichten sind ebenfalls nützlich, wenn Sie Prädikate für eine Zeilenuntermenge angeben müssen, die die Kapazität der Spalte PREDICATES der Tabelle für Subskriptionszuordnung (512 Byte) überschreiten. Auf diese Weise können Sie Ihre Untermengenprädikate unter Verwendung von Sichten steuern anstatt als Bestandteil der Subskriptionsgruppendefinition.
Wenn Sie mit der Steuerzentrale eine Verknüpfungssicht als Replikationsquelle definieren wollen, definieren Sie zunächst alle Tabellen, die in der Verknüpfung enthalten sein sollen, als Replikationsquellen (Sie brauchen keine Subskriptionen für diese Tabellen zu definieren). Wenn Sie mit DJRA eine Verknüpfungssicht als Replikationsquelle definieren wollen, können Sie vorhandene Sichten verwenden oder eine Verknüpfungssicht definieren, die nicht als Replikationsquellen definierte Tabellen enthält. Sie können sowohl die Steuerzentrale als auch DJRA zum Definieren einer Sicht als Replikationsquelle (vgl. Abschnitt Definieren von Sichten als Replikationsquellen). Wenn die in der Verknüpfung definierten Replikationsquellen CD- oder CCD-Tabellen beinhalten, erstellt die Steuerzentrale oder DJRA aus den CD-Tabellen der Replikationsquelle eine CD-Sicht.
Die DB2-Lösung zur Datenreplikation unterstützt folgende Arten von Sichtdefinitionen:
Es werden nur Sichten für Tabellen aus DB2-Datenbanken unterstützt. Sichten von Tabellen, die unter Oracle, Microsoft SQL Server, Sybase, Sybase SQL Anywhere, Informix oder Teradata gespeichert sind, werden nicht unterstützt.
Erstellen Sie DB2-Sichten, die als Replikationsquelle definiert werden sollen, unter Verwendung einer Korrelations-ID.
Tipp: Beim Definieren einer Sicht, die zwei oder mehr Quellentabellen als Replikationsquelle enthält, sollten Sie zusätzlich eine CCD-Tabelle für eine der Quellentabellen in der Verknüpfung definieren. Diese CCD-Tabelle sollte nicht komprimiert und unvollständig (oder vollständig) sein und sich auf dem Ziel-Server befinden. Bei einer Sicht, die mehr als zwei Quellentabellen enthält, können "doppelte Löschvorgänge" auftreten, die von DB2 DataPropagator nicht repliziert werden können.
Wenn Sie beispielsweise eine Sicht definieren, in der die Tabellen CUSTOMERS und CONTRACTS enthalten sind, und im gleichen Replikationszyklus eine bestimmte Zeile der Tabelle CUSTOMERS sowie die entsprechende Zeile (aus Sicht der Verknüpfung) der Tabelle CONTRACTS löschen, ist dies ein doppelter Löschvorgang. Hierbei entsteht das Problem, dass die Zeile nach dem Löschen in beiden Quellentabellen der Verknüpfung nicht mehr in den Sichten angezeigt wird (weder in den Basissichten noch in den Sichten der CD-Tabelle). Das bedeutet, der doppelte Löschvorgang kann nicht repliziert werden.
Das Problem kann durch Definieren einer komprimierten und unvollständigen CCD-Tabelle für eine der Quellentabellen der Verknüpfung behoben werden, da die Löschvorgänge anhand der Spalte IBMSNAP_OPERATION dieser CCD-Tabelle festgestellt werden können. Sie können der Definition der Subskriptionsgruppe eine SQL-Anweisung hinzufügen, die nach dem Subskriptionszyklus ausgeführt werden soll. Diese SQL-Anweisung entfernt alle Zeilen der Zieltabelle, für die die Spalte IBMSNAP_OPERATION in der CCD-Tabelle den Wert "D" enthält.
Sie können Vorabbilder und Nachabbilder in Ihren Replikationsquellen und Subskriptionen definieren. Eine Vorabbildspalte ist die Kopie einer Spalte, bevor diese aktualisiert wird. Eine Nachabbildspalte ist die Kopie einer Spalte nach der Aktualisierung. DB2 protokolliert sowohl die Vorabbild- als auch die Nachabbildspalten einer Tabelle für jede Änderung der Tabelle. Das Replizieren der Vorabbilder ist in Szenarios mit beliebiger Replikation erforderlich, wenn Sie für das Replikat die standardmäßige oder erweiterte Konflikterkennung definieren. In diesem Fall stellen die Vorabbilder die erforderlichen Informationen für die automatische Kompensierung zurückgewiesener Transaktionen zur Verfügung. Das Replizieren von Vorabbildern kann außerdem zu Prüfzwecken nützlich sein.
Die Vor- und Nachabbilder enthalten unterschiedliche Werte für verschiedene Aktionen an den Zieltabellen:
Wenn Sie die Unterstützung für logische Partitionierungsschlüssel aktivieren, erscheint die Vorabbildspalte in der gelöschten Spalte und die Nachabbildspalte in der eingefügten Spalte. Weitere Informationen finden Sie im Abschnitt Aktivieren der Unterstützung logischer Partitionierungsschlüssel bei der Replikation.
Vorabbilder sind für die Zieltabellenart "Basisergebnistabelle" nicht sinnvoll (für berechnete Spalten gibt es kein Vorabbild). Bei allen anderen Arten von Zieltabellen können Vorabbildspalten verwendet werden.
Beschränkung: Bei Spalten mit einem definierten Vorabbild begrenzt DB2 DataPropagator Spaltennamen auf maximal 17 Zeichen. Weil DB2 DataPropagator in Zieltabellen eine Kennung für Vorabbildspalten (normalerweise X) hinzufügt und weil Sie sicherstellen müssen, dass jeder Spaltenname eindeutig ist, dürfen Sie für die zu replizierenden Tabellen keine längeren Spaltennamen verwenden. Für Tabellen, die nicht repliziert werden sollen, können längere Spaltennamen verwendet werden. Es empfiehlt sich trotzdem, die Längenbegrenzung auf 17 Zeichen einzuhalten, falls diese Tabellen zu einem späteren Zeitpunkt doch repliziert werden sollen. Für Tabellen unter DB2 für OS/390 können Sie Spaltennamen mit 18 Zeichen verwenden. Allerdings ersetzt DB2 DataPropagator das achtzehnte Zeichen in Zieltabellen durch die Vorabbildspaltenkennung, d. h., Sie müssen sicherstellen, dass die ersten 17 Zeichen einen eindeutigen Namen ergeben.
Sie können Spalten für die Zieltabellenarten "Tabelle mit Zeitangabe" und "Benutzerkopie" umbenennen. Für andere Tabellenarten müssen Sie Sichten definieren, um Spalten umzubenennen.
Unter Verwendung von SQL können Sie neue Spalten aus vorhandenen Quellenspalten ableiten. Für Ergebniszieltabellen können Sie neue Spalten mit Hilfe von Spaltenfunktionen wie z. B. COUNT oder SUM definieren. Für andere Tabellenarten können Sie neue Spalten mit Hilfe von SQL-Ausdrücken definieren.
Beim Erstellen einer Sicht, die als Replikationsquelle verwendet wird, können Sie berechnete Spalten auch durch Verweisen auf benutzerdefinierte Funktionen erstellen.
Sie können Anweisungen für die Laufzeitverarbeitung mit SQL-Anweisungen oder gespeicherten Prozeduren definieren, die vor oder nach der Verarbeitung der Subskriptionsgruppe durch das Apply-Programm ausgeführt werden können. Solche Anweisungen können beispielsweise zum Bereinigen von CCD-Tabellen und zum Steuern der Verarbeitungsreihenfolge für Subskriptionsgruppen verwendet werden. Die Anweisungen für die Laufzeitverarbeitung können auf dem Quellen-Server ausgeführt werden, bevor eine Subskriptionsgruppe verarbeitet wird, oder auf den Quellen- und Ziel-Servern vor oder nach dem Verarbeiten einer Subskriptionsgruppe. Sie können SQL-Anweisungen ausführen, bevor Daten abgerufen werden oder nachdem Daten in Zieltabellen repliziert wurden, oder Sie können sich für eine Kombination aus beidem entscheiden.
Die gespeicherten Prozeduren verwenden die SQL-Anweisung CALL ohne Parameter. Der Prozedurname darf maximal 18 Zeichen lang sein (für AS/400 maximal 128 Zeichen). Wenn die Quellentabelle sich nicht in einer IBM Datenbank befindet, werden die SQL-Anweisungen von DB2 DataJoiner verarbeitet. Die Laufzeitprozeduren der einzelnen Typen werden zusammen als eine einzige Transaktion ausgeführt. Hier besteht außerdem die Möglichkeit, zulässige SQLSTATE-Werte für jede Anweisung zu definieren.
Je nach verwendeter DB2-Plattform kann der SQL-Code vor oder nach der Verarbeitung von Anweisungen andere Verarbeitungsvorgänge (z. B. das Aufrufen gespeicherter Prozeduren) ausführen.
DB2 Universal Database unterstützt große Objekte (Large Object, LOB). Dies umfasst folgende Datentypen: BLOB (große Binärobjekte), CLOB (große Zeichenobjekte) und DBCLOB (große Doppelbytezeichenobjekte). In diesem Abschnitt werden alle diese Datentypen zusammenfassend als LOB-Daten bezeichnet.
Das Capture-Programm ermittelt durch Lesen des LOB-Deskriptors, ob Daten in der LOB-Spalte geändert wurden und repliziert werden müssen. Das Programm kopiert die LOB-Daten jedoch nicht in die CD-Tabellen. Wenn eine LOB-Spalte geändert wird, setzt das Capture-Programm einen entsprechenden Indikator in den CD-Tabellen. Das Apply-Programm liest diesen Indikator und kopiert daraufhin die gesamte LOB-Spalte (nicht nur die geänderten Teile der LOB-Spalten) direkt aus der Quellentabelle in die Zieltabelle.
Damit das Capture-Programm Änderungen der LOB-Daten erkennen kann, müssen Sie beim Erstellen (oder Ändern) der Quellentabelle die Schlüsselwörter DATA CAPTURE CHANGES angeben.
Da eine LOB-Spalte bis zu zwei Gigabyte Daten enthalten kann, müssen Sie sicherstellen, dass die Netzwerkbandbreite für das Apply-Programm ausreicht. Außerdem müssen Ihre Zieltabellen über genügend Plattenspeicherplatz verfügen, um die LOB-Daten aufzunehmen.
Einschränkungen:
Der Zugriff auf große Dateien (z. B. Multimediadaten) über ein fernes Netzwerk kann ineffizient und kostspielig sein. Wenn diese Dateien gar nicht oder nur selten geändert werden, ermöglicht das Replizieren dieser Dateien an ferne Standorte einen schnelleren Zugriff und eine Reduzierung des Datenaustauschs im Netzwerk. DB2 Universal Database stellt den Datentyp DATALINK zur Verfügung, über den die Datenbank Zugriff, Integrität und Wiederherstellung dieser Art von Dateien steuern kann. DB2 Universal Database unterstützt DATALINK-Werte auf allen Plattformen außer OS/390.
DB2 repliziert DATALINK-Spalten und verwendet die Benutzer-Exit-Routine ASNDLCOPY zum Replizieren der externen Dateien, auf die in den DATALINK-Spalten verwiesen wird. Diese Routine setzt jeden Quellenverbindungsverweis in einen Zielverbindungsverweis um und kopiert die externen Dateien aus dem Quellensystem in das Zielsystem. Im Verzeichnis sqllib/samples/repl befindet sich die Beispielroutine (ASNDLCOPY.SMP), mit der FTP oder der Dämon zum Kopieren von Dateien (ASNDLCOPYD.SMP) für die Dateiübertragung verwendet werden kann. Die Beispielprogramme für AS/400 sind in den Dateien QCSRC, QCBLLESRC und QRPGLESRC der Bibliothek QDPR enthalten. Weitere Informationen dazu enthalten die Abschnitte Verwendung der Exit-Routine ASNDLCOPY und Verwendung des Dämonprozesses ASNDLCOPYD zum Kopieren von Dateien.
Da externe Dateien sehr umfangreich sein können, müssen Sie sicherstellen, dass die Netzwerkbandbreite für das Apply-Programm und für den Dateiübertragungsmechanismus ausreicht, den Sie zum Kopieren dieser Dateien verwenden. Außerdem muss Ihr Zielsystem über genügend Plattenspeicherplatz verfügen, um diese Dateien aufzunehmen.
Empfehlung:
Einschränkungen:
DATALINK-Werte können nicht auf Plattformen repliziert werden, die diese Werte nicht unterstützen.
Verwenden Sie beim Replizieren in komprimierte Zieltabellen (Benutzerkopietabellen, Tabellen mit Zeitangabe, komprimierte CCD- oder Replikattabellen) für Aktualisierungen nicht die Syntax SET KEYCOL=KEYCOL + n. Bei dieser Art von Schlüsselaktualisierung können die Daten nicht korrekt repliziert werden. Verwenden Sie eine andere Spalte in der Quellentabelle als Schlüssel in der Subskriptionsgruppe. Ist in der Quellentabelle kein Alternativschlüssel vorhanden, können Sie die Daten mit folgender Methode trotzdem korrekt replizieren:
Derzeit gelten für DB2 DataPropagator die im Folgenden aufgeführten spezifische Einschränkungen für bestimmte Betriebssystemumgebungen und Datentypen:
Stellen Sie genügend Plattenspeicherplatz für die aktive Protokolldatei bereit, da Capture für VSE und Capture für VM keine Archivprotokolldateien lesen können.
DB2 DataPropagator kann Daten, die mit Hilfe der DB2-Software- oder Hardwarekomprimierung unter DB2 für MVS/ESA (ab Version 4) komprimiert wurden, nur replizieren, wenn das bei der Komprimierung der Daten verwendete Wörterverzeichnis zur Verfügung steht. Bevor Sie den Befehl REORG für komprimierte Replikationsquellen aktivieren, sollten Sie einen der folgenden Schritte ausführen:
DB2 DataPropagator kann keine Daten replizieren, die durch EDITPROC- oder FIELDPROC-Prozeduren komprimiert wurden.
DB2 Enterprise - Extended Edition kann als Ziel-Server für das Apply-Programm fungieren. Zudem besteht die Möglichkeit, DB2 Enterprise - Extended Edition als mittlere Stufe in einer dreistufigen Konfiguration einzusetzen. Beispielsweise können Sie die Änderungen in einer Datenbank (Stufe 1) erfassen, diese in eine CCD-Tabelle in einer DB2 Enterprise - Extended Edition-Datenbank (Stufe 2) replizieren und anschließend die Änderungen aus der CCD-Tabelle in eine weitere Datenbank (Stufe 3) replizieren.
Sie können Änderungen mit DB2 Enterprise - Extended Edition nur erfassen, wenn die Quellentabelle nicht partitioniert ist und wenn sie sich auf dem Katalogknoten befindet. Auch alle Replikationssteuertabellen dürfen nicht partitioniert sein, und sie müssen sich auf dem Katalogknoten befinden.
Bei Verwendung der Steuerzentrale haben Sie nicht die Möglichkeit, DB2 Enterprise - Extended Edition-Objekte als Replikationsquellen auszuwählen oder zum Bestandteil einer Subskriptionsgruppe zu machen. Bei DJRA ist dies hingegen möglich.
Auf Grund der verwendeten Methode für die Kommunikationsverarbeitung können Sie DB2 DataPropagator mit ferner Journalführung und beliebigen SNA-Verbindungen oder mit DRDA und beliebigen TCP/IP-Verbindungen verwenden. Andere Kombinationen werden nicht unterstützt.
Bei DB2 bei MVS bis Version 4 muss der Partitionierungsschlüssel für den Zieltabellenbereich (falls vorhanden) mit dem Primärschlüssel übereinstimmen.
DB2 DataPropagator erfasst keine Aufrufe gespeicherter Prozeduren, das Programm erfasst jedoch von gespeicherten Prozeduren veranlasste Zeilenaktualisierungen.
DB2 DataPropagator unterstützt referenzielle Integritätsbedingungen nur für Benutzertabellen und Replikattabellen.
DB2 DataPropagator bietet keine Unterstützung für die folgenden Schlüsselwörter der SQL-Anweisung CREATE TABLE für Replikattabellen, die der Kompensierung unterliegen: DELETE CASCADE, DELETE RESTRICT und UPDATE RESTRICT.
DB2 DataPropagator kann keine Aktualisierungen erfassen, die von Datenbankdienstprogramme vorgenommen wurden. Außerdem kann DB2 DataPropagator keine Aktualisierungen von Daten erfassen, die mit den Optionen LOAD RESUME LOG YES geladen wurden.
DB2 DataPropagator kann keine verschlüsselten Daten replizieren.
DB2 DataPropagator kann die folgenden Datentypen generell nicht replizieren:
DB2 DataPropagator kann die folgenden Datentypen nur unter bestimmten Umständen replizieren:
Benutzerdefinierte Datentypen (Datentyp DISTINCT in DB2 Universal Database) werden vor der Replikation in den Basisdatentyp umgesetzt.
Je eine DB2 DataJoiner-Datenbank muss für jeden Quellen-Server eines anderen Herstellers vorhanden sein. Sie können zwar eine DB2 DataJoiner-Datenbank zum Replizieren von Daten auf mehrere Ziel-Server anderer Hersteller verwenden, Sie benötigen jedoch eine eindeutig zugeordnete DB2 DataJoiner-Datenbank für jeden Quellen-Server eines anderen Herstellers.
Bei DataJoiner für AIX muss bei der Replikation von Microsoft SQL Server 6.0 und 6.5 eine DBLIB-Verbindung verwendet werden; bei DataJoiner für NT muss bei der Replikation von Microsoft SQL Server 6.5 das ODBC-Protokoll verwendet werden.
Wenn Sybase oder Microsoft SQL Server die Datenquelle ist und die Quellentabelle eine Spalte vom Typ TIMESTAMP enthält, wählen Sie keine Vor- und Nachabbilder aus, wenn Sie die Tabelle als Replikationstabelle definieren. Für SQL Server ist nur eine Spalte vom Typ TIMESTAMP zulässig. Wenn Sie die Vor- und Nachabbilder benötigen, wählen Sie beim Definieren der Replikationsquelle nicht die Spalte vom Typ TIMESTAMP aus.
Wenn die Datenquelle Oracle ist, wählen Sie keine Vor- und Nachabbilder aus, wenn die Quellentabelle eine Spalte vom Typ LONG enthält. Eine Oracle-Tabelle darf nur eine Spalte vom Typ LONG enthalten.
DJRA unterstützt nicht die Replikation von LOB-Spalten in heterogenen Umgebungen.
Auch für die beliebige Replikation in heterogenen Umgebungen bietet DJRA keine Unterstützung.
In DB2 DataJoiner brauchen Sie keine Kurznamen für Microsoft Jet- oder Microsoft Access-Tabellen zu definieren. Weitere Informationen dazu enthält der Abschnitt Verwendung von DB2 DataPropagator für Microsoft Jet.
Treten beim Ausführen von DJRA in einer Windows 9x-Umgebung Verbindungsprobleme im Zusammenhang mit TCP/IP auf (z. B. kann ein Verbindungsfehler Client-Anwendungen inaktiv erscheinen lassen), können Sie durch Festlegen von Netzwerkoptionen steuern, nach welchem Zeitraum der Fehler festgestellt wird. Solche systemweiten Parameter können sich auf alle TCP/IP-Anwendungen auswirken. Editieren Sie zum Festlegen dieser Optionen die TCP/IP-Parameter in der Windows-Registrierdatenbank. Sichern Sie unbedingt Ihre Registrierdatenbank, bevor Sie Änderungen vornehmen.
Empfehlungen für Informix:
Capture-Auslöser werden für die Replikation aus Datenbanken anderer Hersteller verwendet. Sie erfassen geänderte Daten in einer Quellentabelle und stellen diese Daten für die Replikation zur Verfügung. Capture-Auslöser haben dieselbe Funktion wie das Capture-Programm bei DB2; die Funktionsweise unterscheidet sich jedoch. Die Capture-Auslöser werden von DJRA generiert.
Als Komponente von DB2 DataJoiner erstellt DJRA Capture-Auslöser in der Quellendatenbank eines anderen Herstellers, wenn Sie die Quellentabellen als Replikationsquellen definieren. Capture-Auslöser erfassen festgeschriebene Änderungen, die an den Quellendaten vorgenommen wurden, und stellen diese Änderungen in eine Zwischenspeichertabelle, die als CCD-Tabelle (Consistent Change Data Table) bezeichnet wird. Der CCD-Tabelle ist bei DB2 DataJoiner ein Kurzname zugeordnet, und Programme, die die Änderungen replizieren wollen (z. B. das Apply-Programm), können auf diesen Kurznamen zugreifen. Weitere Informationen zu CCD-Tabellen enthält der Abschnitt Zwischenspeichern von Daten.
Für jede Quellentabelle gibt es drei Auslöser: DELETE, UPDATE und INSERT.
Die Capture-Auslöser arbeiten mit folgenden Objekten zusammen: CCD-Tabelle, Registriersteuertabelle, Löschsteuertabelle und Synchronisationstabelle für Registrierinformationen.
DJRA generiert SQL-Anweisungen (wenn Sie eine Tabelle als Replikationsquelle definieren), die Folgendes bewirken:
Bei jeder Lösch-, Aktualisierungs- oder Einfügeoperation in der definierten Quelle zeichnet ein Capture-Auslöser die Änderung in der CCD-Tabelle auf. Wenn die Capture-Auslöser geänderte Informationen abrufen, können sie auch Vorabbild- und Nachabbildspaltendaten abrufen, die in die CCD-Tabelle gestellt werden.
Wenn die Primärschlüsselwerte der Zieltabelle aktualisiert werden oder die Tabelle (oder Sicht) eine logische Partitionierungsspalte enthält, die aktualisiert wird, müssen Sie beim Definieren der Replikationsquelle die Unterstützung für logische Partitionierungsschlüssel bei der Replikation aktivieren. Die Unterstützung für logische Partitionierungsschlüssel bei der Replikation führt eine UPDATE-Anweisung als Kombination aus einer DELETE-Anweisung und einer anschließenden INSERT-Anweisung aus. Weitere Informationen finden Sie im Abschnitt Aktivieren der Unterstützung logischer Partitionierungsschlüssel bei der Replikation.
Anschließend liest das Apply-Programm die CCD-Tabelle (über DB2 DataJoiner-Kurznamen), kopiert die Änderungen auf den Ziel-Server und wendet die Änderungen auf die Zieltabelle an. Abbildung 18 verdeutlicht die Beziehung zwischen den Capture-Auslösern, der Quellentabelle, der Registriersteuertabelle und der CCD-Tabelle.
Abbildung 18. Capture-Auslöser auf dem Quellen-Server. Die Capture-Auslöser überwachen die Quellendatenänderungen, erfassen die geänderten Daten und schreiben sie in die CCD-Tabelle.
Wenn DJRA Capture-Auslöser erstellt und in Datenbanken anderer Hersteller platziert, treten möglicherweise folgende Situationen auf:
Normalerweise werden bei der Replikation Änderungen der Quellentabelle erfasst, die geänderten Zeilen in die CD-Tabelle eingefügt und die dazugehörigen Transaktionsinformationen in die UOW-Tabelle eingefügt. Die CD-Tabelle wird mit der UOW-Tabelle verknüpft, um festzustellen, welche Änderungen festgeschrieben sind und daher in Zieltabellen repliziert werden können. Diese verknüpfte Ausgabe kann in einer CCD-Tabelle gespeichert werden, aus der ebenfalls Informationen zu Datenänderungen gelesen werden können. Eine CCD-Tabelle enthält nur festgeschriebene Änderungen. Bei Verwendung einer CCD-Tabelle können mehrere Subskriptionsgruppen (und die dazugehörigen Elemente) auf diese Informationen verweisen, ohne zusätzlichen Aufwand für die Verknüpfung der CD- und UOW-Tabellen für jeden Subskriptionszyklus zu verursachen. 18
CCD-Tabellen bieten weitere Vorteile neben dem Vermeiden der Verknüpfung von CD- und UOW-Tabellen. Beim Einrichten Ihrer Replikationsumgebung können Sie angeben, welcher Typ von CCD-Tabelle für Ihre Replikationsumgebung geeignet ist. Damit Sie leichter entscheiden können, ob Sie CCD-Tabellen verwenden sollten, werden in diesem Abschnitt die Attribute und typischen Verwendungszwecke von CCD-Tabellen beschrieben.
Wenn Sie CCD-Tabellen verwenden wollen, müssen Sie festlegen, wo sie platziert werden sollen und welche Änderungsdaten sie enthalten müssen.
Eine lokale CCD-Tabelle ist in der Quellendatenbank gespeichert. Eine ferne CCD-Tabelle befindet sich an einem anderen Standort als die Quellendatenbank, d. h., in einer beliebigen anderen Datenbank in dem Netzwerk, auf das das Apply-Programm zugreifen kann. Wenn Sie über viele ferne Ziele verfügen, können Sie eine ferne CCD-Tabelle als Quellentabelle verwenden, um den von der Quelle ausgehenden Datenaustausch auf dem Netzwerk zu reduzieren.
Eine vollständige CCD-Tabelle enthält alle Zeilen, die den Auswahlbedingungen der Quellensicht und den Prädikaten aus der Quellentabelle oder -sicht entsprechen. Das Apply-Programm verwendet eine vollständige CCD-Tabelle als Quelle für vollständige Aktualisierungen oder zum Replizieren von Änderungen in andere Zieltabellen.
Eine unvollständige CCD-Tabelle enthält nur Änderungen, die an der Quellentabelle vorgenommen wurden. Dies bedeutet, eine unvollständige CCD-Tabelle ist zunächst leer und wird nach und nach mit den an der Quellentabelle vorgenommenen Änderungen gefüllt. Beim Neuerstellen einer unvollständigen CCD-Tabelle bzw. beim Kaltstart des Capture-Programms, aktualisiert das Apply-Programm die unvollständige CCD-Tabelle nicht mit allen Zeilen der Quellentabelle. 19 Das Apply-Programm zeichnet Änderungen der Quellentabelle auf, es repliziert jedoch nicht die ursprünglichen Zeilen. Das Apply-Programm kann eine unvollständige CCD-Tabelle nicht zum Aktualisieren anderer Zieltabellen verwenden.
Eine komprimierte CCD-Tabelle enthält nur die aktuellsten Spaltenwerte. Beispiel: Wenn eine Zeile in der Quellentabelle fünf Mal geändert wird, enthält die CCD-Tabelle eine Zeile mit den Ergebnissen aller fünf Änderungen der Quellentabelle. Komprimierte CCD-Tabellen konsolidieren Änderungen und reduzieren den Datenaustausch auf dem Netzwerk für die mehrstufige Replikation. Eine nicht komprimierte CCD-Tabelle enthält je eine Zeile für jede Änderungen, die an einer Zeile der Replikationsquelle vorgenommen wurde. Beispiel: Wenn eine Zeile der Quellentabelle fünf Mal geändert wird, enthält die nicht komprimierte CCD-Tabelle fünf Zeilen (für jede Änderung eine). Die nicht komprimierte CCD-Tabelle protokolliert demnach alle Änderungen jeder einzelnen Zeile. Nicht komprimierte CCD-Tabellen sind nützlich für Prüfzwecke.
Definieren eindeutiger Indizes: Für eine komprimierte CCD-Tabelle sind eindeutige Schlüsselwerte für jede Zeile erforderlich; eine nicht komprimierte CCD-Tabelle hingegen kann mehrere Zeilen mit identischen Schlüsselwerten enthalten. Auf Grund dieses Unterschieds bei der Eindeutigkeit der Schlüssel muss für eine komprimierte CCD-Tabelle ein eindeutiger Index definiert werden, während eine nicht komprimierte CCD-Tabelle keinen eindeutigen Index haben darf.
Tabelle 5 fasst die Arten von CCD-Tabellen nach den möglichen
Attributkombinationen zusammen.
Tabelle 5. Grundlegende Arten von CCD-Tabellen
Eine CCD-Tabelle kann lokal oder fern, vollständig oder unvollständig, komprimiert oder nicht komprimiert sein - oder auch eine beliebige Kombination dieser Attribute aufweisen. | |||
Position | Vollständig | Komprimiert | Beschreibung |
---|---|---|---|
Lokal | Ja | Ja | Eine CCD-Tabelle, die sich in der Quellendatenbank befindet und die gleichen Daten wie die Replikationsquelle enthält. |
Nein | Eine CCD-Tabelle, die sich in der Quellendatenbank befindet und ein vollständiges Protokoll der Änderungen, einschließlich der Originaldaten aus der Replikationsquelle, enthält. | ||
Nein | Ja | Eine CCD-Tabelle, die sich in der Quellendatenbank befindet und nur die aktuellsten Änderungsdaten enthält. | |
Nein | Eine CCD-Tabelle, die sich in der Quellendatenbank befindet und nur die Änderungsdaten enthält. | ||
Fern | Ja | Ja | Eine CCD-Tabelle, die sich in einer Datenbank befindet, auf die das Apply-Programm zugreifen kann (nicht die Quellendatenbank), und die gleichen Daten wie die Benutzertabelle enthält. |
Nein | Eine CCD-Tabelle, die sich in einer Datenbank befindet, auf die das Apply-Programm zugreifen kann (nicht die Quellendatenbank), und ein vollständiges Protokoll der Änderungen enthält (einschließlich der Originaldaten aus der Replikationsquelle). | ||
Nein | Ja | Eine CCD-Tabelle, die sich in einer Datenbank befindet, auf die das Apply-Programm zugreifen kann (nicht die Quellendatenbank), und nur die aktuellsten Änderungsdaten enthält. | |
Nein | Eine CCD-Tabelle, die sich in einer Datenbank befindet, auf die das Apply-Programm zugreifen kann (nicht die Quellendatenbank), und nur die Änderungsdaten enthält. |
CCD-Tabellen können als Quellen für die Replikation in andere Zieltabellen verwendet werden. 20
Je nach verwendeter Replikationsumgebung können Sie Ihre gesamte CCD-Tabelle als Replikationsquelle (externe CCD-Tabelle) registrieren oder so konfigurieren, dass sie implizit als Replikationsquelle verwendet wird (interne CCD-Tabelle).
Wenn Sie eine vollständige Aktualisierung für eine externe CCD-Tabelle ausführen, nimmt das Apply-Programm eine vollständige Aktualisierung aller Zieltabellen vor, die diese externe CCD-Tabelle als Replikationsquelle verwenden. Dieser Prozess wird auch als mehrstufige vollständige Aktualisierung (Cascade Full Refresh) bezeichnet. Für eine Replikationsquelle können mehrere externe CCD-Tabellen definiert werden. Eine externe CCD-Tabelle kann beliebige Attribute haben (lokal oder fern, vollständig oder unvollständig, komprimiert oder nicht komprimiert). Dient sie jedoch zum Zwischenspeichern von Daten, muss eine vollständige CCD-Tabelle verwendet werden, da sie vom Apply-Programm sowohl für vollständige Aktualisierungen (Full Refresh) als auch die Replikation von Änderungen (Change Replication) verwendet wird.
Interne CCD-Tabellen dienen zum Zwischenspeichern von Änderungen. Das Apply-Programm verwendet die ursprüngliche Quellentabelle für vollständige Aktualisierungen und die interne CCD-Tabelle für Änderungsreplikationen (anstatt bei jedem Replizieren von Änderungen die CD- und UOW-Tabellen zu verknüpfen). 21
Verwenden Sie eine interne CCD-Tabelle als lokalen Zwischenspeicher für festgeschriebene Änderungen an einer Quellentabelle. Das Apply-Programm repliziert Änderungen aus einer internen CCD-Tabelle (falls vorhanden) anstatt aus CD-Tabellen.
Eine interne CCD-Tabelle kann als implizite Replikationsquelle verwendet werden, ohne dass sie explizit als Replikationsquelle definiert wurde. Beim Hinzufügen eines Subskriptionsgruppeneintrags kann eine interne CCD-Tabelle angefordert werden, wenn die Tabelle folgende Attribute aufweist:
Die folgende Liste enthält alle Arten von CCD-Tabellen und gibt an, ob sie sich zum Zwischenspeichern von Daten eignen.
Diese Art von CCD-Tabelle kann als Replikationsquelle definiert und wie folgt verwendet werden:
Normalerweise wird diese Tabelle in der Nähe der Ziele erstellt und nicht lokal auf dem Quellensystem, um den Datenaustausch auf dem Netzwerk bei der Replikation von Änderungen (Change Replication) und vollständigen Aktualisierungen (Full Refresh) möglichst gering zu halten. Außerdem führen mehrere Aktualisierungen einer einzigen Quellentabellenzeile dazu, dass eine einzelne Zeile in alle Zieltabellen repliziert wird.
Definieren Sie diese Art von CCD-Tabelle weder als Replikationsquelle noch als interne CCD-Tabelle.
Verwenden Sie diese Art von CCD-Tabelle nicht als Zwischenspeichertabelle für die Replikation, da das Speichern sämtlicher Änderungen sehr speicherintensiv ist.
Diese Tabelle enthält zunächst einen vollständigen Zeilensatz, und bei jeder Zeilenänderung werden weitere Zeilen angehängt. Es werden keine Informationen überschrieben, d. h., es gehen keine Informationen verloren. Verwenden Sie diese Art von CCD-Tabelle mit Anwendungen, die nach dem Initialisieren der CCD-Tabelle jederzeit zeitbezogene Abfragen (z. B. 'am letzten Dienstag', 'vor einem Monat' oder 'gestern') verarbeiten müssen. Außerdem kann diese Art von CCD-Tabelle für Prüfanwendungen verwendet werden, die einen vollständigen Zeilensatz benötigen. (Andere Prüfarten sind im Abschnitt Protokollierung zu Prüfzwecken beschrieben.)
Diese Art von CCD-Tabelle kann als interne CCD-Tabelle für die Replikationsquelle definiert werden. In diesem Fall wird die CCD-Tabelle für Aktualisierungen verwendet und nur bei vollständigen Aktualisierungen auf die ursprüngliche Quelle zugegriffen. Diese Vorgehensweise ist besonders effizient, weil die CD- und UOW-Tabellen nur einmal verknüpft werden, um die CCD-Tabelle zu füllen. Anschließend werden die Änderungen ohne den Zusatzaufwand für die Verknüpfung aus der CCD-Tabelle in alle Ziele repliziert. Da die CCD-Tabelle unvollständig ist, müssen vollständige Aktualisierungen aus der ursprünglichen Quellentabelle kommen. Diese Tabellenart ist außerdem nützlich zum Komprimieren von Änderungsdaten aus einer CD-Tabelle. Durch die Komprimierung wird eine geringere Anzahl von Zeilen auf ferne Standorte repliziert, und es werden weniger Operationen an den Zieltabellen ausgeführt, weil nur die letzte Änderung für jede Zeile aufbewahrt wird.
In den meisten Fällen sollte diese Art von CCD-Tabelle nicht als Replikationsquelle definiert werden. Diese Tabellenart kann für Prüfanwendungen verwendet werden, die keinen vollständigen Zeilensatz benötigen, sondern nur die zuletzt geänderten Zeilen.
Sie können diese CCD-Tabelle als interne CCD-Tabelle für eine Replikationsquelle definieren, wenn die fernen Ziele nicht komprimiert sind. In diesem Fall kann bei einer großen Anzahl ferner Ziele die wiederholte Verknüpfung der CD- und UOW-Tabellen vermieden werden, sofern dieser Vorteil größer ist als der Aufwand für das Speichern und Verwalten der CCD-Tabelle.
Wenn Sie eine interne CCD-Tabelle als Ziel definieren, werden die Änderungen aus allen anderen Zieltabellen, die der Quellentabelle zugeordnet sind, aus dieser internen CCD-Tabelle repliziert und nicht aus der ursprünglichen Quellentabelle. Darum ist es wichtig, alle potenziellen Zieltabellen einzuplanen, um sicherzustellen, dass die interne CCD-Tabelle korrekt definiert wird. Wenn Sie nicht alle Spalten der Quellentabelle in die interne CCD-Tabelle aufnehmen, sondern eine Zieltabelle alle diese Spalten enthält, schlägt die Replikation fehl. Die Replikation schlägt ebenfalls fehl, wenn nicht alle Spalten der Quellentabelle in der zum Verwalten der internen CCD-Tabelle verwendeten CD-Tabelle enthalten sind, sondern in einer Zieltabelle.
Interne CCD-Tabellen unterstützen keine zusätzlichen UOW-Tabellenspalten. Wenn Ziel-CCD-Tabellen (mit UOW-Spalten) als Replikationsquelle definiert werden, darf anschließend keine interne CCD-Tabelle definiert werden. Verwenden Sie keine interne CCD-Tabelle, wenn Sie bereits eine Ziel-CCD-Tabelle definiert haben, die UOW-Spalten enthält.
Wenn Sie in einer internen CCD-Tabelle Spaltenuntermengen verwenden wollen, überprüfen Sie alle zuvor definierten Zieltabellen, um sicherzustellen, dass die Definition der internen CCD-Tabelle alle relevanten Spalten aus den Quellentabellen enthält. Wenn Sie die Subskriptionsgruppe für die interne CCD-Tabelle vor den anderen Subskriptionsgruppen aus dieser Quelle definieren, sind diese anderen Subskriptionsgruppen auf die in der internen CCD-Tabelle enthaltenen Spalten begrenzt.
Mit CCD-Tabellen können Sie Änderungen replizieren, die von Anwendungsprogrammen oder Tools auf anderen Datenbankverwaltungssystemen (z. B. Oracle) erfasst werden. Auslöser in Oracle-Tabellen simulieren das Capture-Programm, indem Sie Änderungen in Oracle-CCD-Tabellen schreiben. Auslöser für die Erfassungsfunktion von Quellen anderer Hersteller verwenden ebenfalls die interne CCD-Konfiguration zum Replizieren von Änderungen. Ein Beispiel für diese Verwendung finden Sie im Abschnitt Abrufen von Daten aus einem verteilten Datenspeicher eines anderen Herstellers.
In ähnlicher Weise können von Anwendungsprogrammen oder anderen Tools (z. B. IMS DataPropagator) erfasste Änderungen als Quellen für Subskriptionsgruppen definiert werden. Das Anwendungsprogramm muss eine vollständige CCD-Tabelle erstellen und pflegen. Dabei muss es sich um eine externe CCD-Tabelle handeln, sie kann jedoch komprimiert oder nicht komprimiert sein. Beispiel: IMS DataPropagator erfasst Änderungen an IMS-DB-Segmenten und aktualisiert die eigene CCD-Tabelle. Sie definieren die CCD-Tabelle als Replikationsquelle. Anschließend können Sie mit Hilfe dieser CCD-Tabelle Subskriptionsgruppen definieren, und zwar unabhängig davon, wo die Aktualisierungen tatsächlich stattfinden. Ein Beispiel für diese Verwendung finden Sie im Abschnitt Verteilen von IMS-Daten an ferne Standorte.
Das Capture-Programm kann die CD-Tabellen auf der Basis der Informationen bereinigen, die vom Apply-Programm in die Löschsteuertabelle (Pruning Control Table) eingefügt werden. Mit dem Parameter PRUNE bzw. NOPRUNE können Sie steuern, ob das Capture-Programm CD-Tabellen bereinigt oder nicht. Außerdem können Sie festlegen, wann die Bereinigung erfolgt und wie das Bereinigungsintervall eingestellt wird, indem Sie die Anpassungsparameter der Steuertabelle ändern.
Manche CCD-Tabellen können unbegrenzt anwachsen; dies gilt insbesondere für nicht komprimierte CCD-Tabellen. Die Bereinigung dieser Tabellen erfolgt nicht automatisch. Sie müssen die Bereinigung manuell vornehmen oder von einem Anwendungsprogramm ausführen lassen. Bei manchen Arten von CCD-Tabellen kann es sinnvoll sein, die Tabellen zu archivieren und neue Tabellen zu definieren, anstatt eine Bereinigung vorzunehmen.
Bei einer Quellentabelle eines anderen Herstellers bereinigen die Capture-Auslöser die CCD-Tabelle auf der Basis eines Synchronisationspunkts, der vom Apply-Programm in die Löschsteuertabelle geschrieben wird.
Die Protokollierung zu Prüfzwecken (Auditing) dient zum Aufzeichnen der Datennutzung und beinhaltet Vorher/Nachher-Vergleiche der Daten und das Identifizieren von Änderungen anhand des Zeitpunkts der Änderung und anhand der Benutzer-ID, die die Änderung vorgenommen hat.
Die DB2-Lösung zur Datenreplikation unterstützt folgende Arten der Prüfprotokollierung:
Eine nicht komprimierte CCD-Tabelle enthält eine Zeile für jede UPDATE-, INSERT- oder DELETE-Operation und liefert auf diese Weise ein Protokoll der an der Quellentabelle ausgeführten Operationen. Wenn Sie UPDATE-Operationen als INSERT-Operationen und DELETE-Operationen erfassen (für Partitionierungsschlüsselspalten), enthält die CCD-Tabelle eine Zeile für jede DELETE- und INSERT-Operation und zwei Zeilen für jede UPDATE-Operation.
Wichtig: Führen Sie keinen Kaltstart für das Capture-Programm durch, wenn Sie genaue Protokolle der Änderungsdaten führen wollen. Ein Abstimmungsverlust kann auftreten, wenn das Apply-Programm Änderungen nicht replizieren kann, bevor das Capture-Programm beendet wird. Weitere Informationen hierzu enthält der Abschnitt Korrektur von Abstimmungsverlusten zwischen Quellen- und Zieltabellen.
Mit Hilfe von unvollständigen und nicht komprimierten CCD-Tabellen können Sie ein Teilprotokoll über die Aktualisierungen für eine Quellentabelle oder ein Prüfprotokoll für die Datenbanknutzung führen. Verwenden Sie zum Optimieren der Prüfprotokollfunktion auch die zusätzlichen Spalten aus der UOW-Tabelle. 22
Mit Hilfe von vollständigen, nicht komprimierten CCD-Tabellen können Sie ein vollständiges Protokoll der Änderungen einer Quellentabelle führen.
Näheres dazu kann im Abschnitt Attribute von CCD-Tabellen nachgelesen werden.
Wenn Sie eine stärker benutzerorientierte Kennzeichnung benötigen, stehen hierfür in der UOW-Tabelle Spalten für die Korrelations-ID und die primäre Berechtigungs-ID bei DB2 für OS/390 oder für den AS/400-Jobnamen und das AS/400-Benutzerprofil zur Verfügung.
Migration bei AS/400:
Es ist nicht möglich, die Version 1 von DPropR/400 gleichzeitig mit Version 7 auszuführen. Wenn Sie derzeit mit Version 1 arbeiten oder wenn Sie die Replikationskomponenten der Version 1 in einer DPropR/400-Umgebung der Version 5 verwenden, müssen Sie eine der folgenden Maßnahmen ausführen:
Die Migration von DPropR/400 V5 auf V7 erfordert keine speziellen Migrationsschritte.
Verwenden Sie DJRA für alle Tasks der Replikationsverwaltung. Sowohl DJRA als auch die DB2-Steuerzentrale bieten Basisfunktionen zur Replikationsverwaltung, über die Replikationsquellen und Subskriptionsgruppen definiert werden können.
Migration für OS/2, UNIX und Windows:
Ab Version 5 von DB2 Universal Database (für Windows, OS/2 oder UNIX) wird die Replikationskomponente automatisch mit DB2 installiert (sie ist nicht wahlfrei). Nach dem Installieren von DB2 UDB Version 7 ist Folgendes nicht mehr möglich:
Die Migration von DB2 UDB Version 6 auf Version 7 erfordert keine speziellen Migrationsschritte für die Replikation.
Wichtig: Eine Interoperabilität zwischen den Replikationskomponenten der Version 1 und der Version 6 oder Version 7 wird nicht unterstützt. Sie müssen darum alle Migrationsschritte von Version 1 auf Version 5 abschließen, bevor Sie DB2 UDB Version 6 oder Version 7 einführen. Die entsprechenden Anweisungen hierfür finden Sie im Migration Guide auf der Library-Seite der DB2 DataPropagator-Web-Site (www.ibm.com/software/data/dpropr/).
Die Komponenten Capture und Apply der Version 5 können parallel zu den Komponenten Capture und Apply der Version 6 oder der Version 7 ausgeführt werden, d. h., Sie brauchen nicht alle Server auf einmal zu migrieren.
Außerdem gilt Folgendes:
DB2 UDB unterstützt den Enabler-Befehl für DB2 Universal Database Satellite Edition (ASNSAT). Es ist jedoch nicht möglich, den Befehl SYNCH von DB2 Universal Database Satellite Edition in einer vorhandenen Replikationsumgebung zu verwenden, weil der Befehl SYNCH auf einer zentralen Verwaltungsfunktion basiert, die von einem zentralen Steuerungs-Server gesteuert wird. Der zentrale Steuerungs-Server erkennt keine Replikationsumgebungen, die nicht mit dem Befehl SYNCH verwaltet werden.
Weitere Informationen zu DB2 Universal Database Satellite Edition finden Sie in der Veröffentlichung DB2 Universal Database Administering Satellites Guide and Reference.
Migration bei OS/390:
Eine Interoperabilität zwischen den Replikationskomponenten der Version 1 und der Version 6 oder der Version 7 wird nicht unterstützt. Sie müssen darum alle Migrationsschritte von Version 1 auf Version 5 abschließen, bevor Sie DB2 für OS/390 Version 6 oder Version 7 einführen. Die entsprechenden Anweisungen hierfür finden Sie im Migration Guide auf der Library-Seite der DB2 DataPropagator-Web-Site (www.ibm.com/software/data/dpropr/).
Die Migration von DB2 für OS/390 Version 6 auf Version 7 erfordert keine speziellen Migrationsschritte für die Replikation.
Die Komponenten Capture und Apply der Version 5 können parallel zu den Komponenten Capture und Apply der Version 6 oder der Version 7 ausgeführt werden, d. h., Sie brauchen nicht alle Server auf einmal zu migrieren.