DB2 Replikation Benutzer- und Referenzhandbuch
In diesem Kapitel werden die wichtigsten Aufgaben der
Datenreplikation beschrieben, die im Laufe des Replikationsprozesses
ausgeführt werden. Die Aufgaben lassen sich den drei folgenden
Prozessstufen zuordnen:
- Planung der Replikationsanforderungen
- Einrichten der Replikationsumgebung
- Betrieb der Replikationsumgebung
Wenn Sie dieses Kapitel gelesen haben, finden Sie detailliertere
Beschreibungen der Aufgaben in Teil 2, Verwaltung. Spezifische Informationen zur Verwendung der
Programme Capture und Apply bei verschiedenen Betriebssystemen können Sie in Teil 3, Betrieb, nachlesen.
Als wichtiger Schritt zur Bereitstellung einer geeigneten
Replikationsumgebung ist im Voraus zu klären, durch welche Merkmale sich die
Anwendungsdaten auszeichnen, welcher Benutzerkreis Datenzugriff benötigt und
wie häufig die Benutzer zugreifen müssen.
Mit der DB2-Lösung zur Datenreplikation können Sie Daten an mehr als einem
Standort verwalten und die verschiedenen Kopien stets auf einem Stand
(d. h. synchron) halten. Sie müssen bestimmen, wo
sich die Quellendaten befinden, ob alle oder nur ein Teil der
Quelleninformationen kopiert werden sollen, ob nur Änderungen kopiert werden
sollen und wie viele Kopien (oder Ziele) Sie benötigen. Ferner müssen
Sie festlegen, wo die Kopien abgelegt werden sollen.
Sie können die Quellen- und Zieltabellen zwar nicht gleichzeitig
aktualisieren, Sie haben aber die Möglichkeit, die Aktualisierungen zeitlich
so zu steuern (terminieren), dass die Anforderungen Ihrer Anwendungen und
Ihrer Replikationsumgebung erfüllt werden. Die Replikationsfrequenz ist
abhängig davon, wie groß die akzeptable Zeitverzögerung zwischen der
Aktualisierung der Quelle und der Aktualisierung der Ziele sein darf.
Sie müssen deshalb zunächst den gewünschten Synchronisationsgrad zwischen den
Kopien und der Quelle bzw. zwischen den Kopien untereinander festlegen,
bevor ein Replikationsmodell erstellt werden kann.
Wenn die Anforderungen geklärt sind, die sich durch die Anwendungsdaten
ergeben, können Sie ein Replikationsmodell entwerfen, das es Ihnen ermöglicht,
diesen Anforderungen gerecht zu werden. Beim Modellentwurf sind eine
ganze Reihe von Aspekten zu berücksichtigen. Im Folgenden sind einige
der wichtigsten Entscheidungen aufgeführt, die Sie in diesem Zusammenhang
treffen müssen:
- Replikationskonfiguration
- Abhängig von den Datenanforderungen müssen Sie entscheiden, ob Ihre
Konfiguration zur Konsolidierung, Verteilung oder beliebigen
Tabellenreplikation (Update-Anywhere) dienen soll oder die Anforderungen von
zeitweise verbundenen Systemen erfüllen soll. Die Flexibilität des
Produkts bietet Ihnen die Möglichkeit, eine Umgebung zu entwerfen, die eine
dieser Konfigurationen oder eine Kombination aus ihnen verwendet.
- Platzierung des Steuerungs-Servers
- Wenn Sie die Steuertabellen nicht zentral, sondern auf demselben Server
speichern, auf dem sich auch das Apply-Programm befindet, ergeben sich
geringfügige Leistungsvorteile, da die Steuertabellen auf dem
Steuerungs-Server häufig vom Apply-Programm gelesen werden. Sie können
Ihre Apply-Programme so einrichten, dass sie auf einen gemeinsamen
Steuerungs-Server zugreifen: die Steuerinformationen sind dann zentral
gespeichert. Der Steuerungs-Server kann sich am Standort des
Quellen-Servers, des Ziel-Servers oder eines beliebigen anderen
Datenbank-Servers befinden, zu dem das Apply-Programm eine Verbindung
herstellen kann. Einem zentralen Steuerungs-Server wird häufig der
Vorzug gegeben, weil dies die Verwaltung großer Netzwerke erleichtert.
Zwei Nachteile sind hier jedoch zu beachten: der Zugriff des
Apply-Programms muss über das Netzwerk erfolgen, und bei einem Ausfall des
Steuerungs-Servers sind alle Apply-Prozesse betroffen. Wird der
Steuerungs-Server bei einem Quellen-Server platziert, der sich in einer
sicheren Umgebung befindet, kann dadurch die Sicherheit verbessert sowie die
zentrale Verwaltung und Überwachung von Replikationssubskriptionen ermöglicht
werden.
- Art der zu verwendenden Zieltabellen
- Die Art der zu verwendenden Zieltabelle hängt von den
Replikationsanforderungen ab. Jede Zieltabellenart ist für einen
bestimmten Anwendungsfall ausgelegt. Beispielsweise ist nur die
Replikattabelle für die beliebige Tabellenreplikation (Update-Anywhere
Replication) geeignet, und nur die Zeilenreplikattabelle kann für
DataPropagator für Microsoft Jet verwendet werden.
- Verwendung bereits bestehender Zieltabellen
- Sie haben die Möglichkeit, die Zieltabelle von der
Verwaltungsschnittstelle erstellen zu lassen oder eine bereits bestehende
Tabelle als Ziel zu verwenden. Handelt es sich bei den bestehenden
Tabellen um DB2-Tabellen, werden die Datentypen von den
DB2-Datenreplikationskomponenten unterstützt. Wenn Ihre
Replikationsumgebung auch Datenbanken anderer Hersteller enthält, können
einige Datentypen möglicherweise nicht direkt den verwendeten Quellentabellen
zugeordnet werden.
- Auswahl der für die Replikation verfügbaren Spalten
- Sie können entscheiden, ob nur die Nachabbildspaltenwerte (After-Image
Column) oder sowohl die Vorabbild- als auch die Nachabbildspaltenwerte erfasst
werden sollen. Wenn die Ziele zur Erstellung von Prüfprotokollen
verwendet werden sollen oder wenn Sie mit Replikatzieltabellen arbeiten,
müssen sowohl die Vorabbild- als auch die Nachabbildspaltenwerte kopiert
werden.
- Art der Erfassung von SQL-Operationen
- Möglicherweise möchten Sie alle Aktualisierungen in Form von zwei Zeilen
in der CD-Tabelle oder CCD-Tabelle einer Quelle eines anderen Herstellers
erfassen: als Löschung (DELETE) der Werte in der Vorabbildspalte,
gefolgt von einer Einfügung (INSERT) der Werte der Nachabbildspalte.
Dies schließt Aktualisierungen von Spalten ein, die als Primärschlüssel oder
als Partitionierungsschlüssel der Zieltabelle dienen werden, oder von Spalten,
die in der WHERE-Klausel bzw. im Prädikat der Subskriptionsgruppe
enthalten sind. Möglicherweise müssen Sie die Größe der CD-Tabelle
anpassen, damit sie die zusätzlichen Daten aufnehmen kann.
- Referenzielle Integritätsbedingungen
- Sie müssen nur dann referenzielle Integritätsbedingungen zur
Gewährleistung der referenziellen Integrität verwenden, wenn Sie mit
Replikattabellen als Zieltabellen arbeiten. Bei Tabellen mit
Lesezugriff müssen keine Integritätsbedingungen bei der Zieltabelle gesetzt
werden. Bei den anderen Arten von Zieltabellen ist die referenzielle
Integrität gewährleistet, wenn Sie die Subskriptionsgruppen ordnungsgemäß
definieren.
- Auswahl der zu verwendenden Verknüpfungen
- Verknüpfungen werden in Sichten beschrieben, die wiederum in
Replikationsquellen definiert sind. Beispielsweise können Sie eine
Sicht verwenden, um den Namen kopierter Spalten zu ändern, um auf Spalten
zugehöriger Tabellen in der WHERE-Klausel im Prädikat des
Subskriptionsgruppeneintrags zu verweisen, um Kopien, die innere Verknüpfungen
(Inner Joins) aus zwei oder mehr Tabellen darstellen, schrittweise zu pflegen
oder um Informationen aus einer Tabelle zu replizieren, wenn eine
Aktualisierung an einer anderen Tabelle vorgenommen wird.
Wenn Sie alle Vorbereitungen getroffen haben und die Replikationsumgebung
planen können, finden Sie weitere Informationen hierzu in Kapitel 5, Planung der Replikationsumgebung.
Nach dem Entwurf des Replikationsmodells müssen Sie Ihre
Replikationsumgebung einrichten. Das Einrichten der
Replikationsumgebung schließt folgende Schritte ein:
- Einrichten des Systems
- Definieren der Replikationskriterien
- Ausführen der ersten Replikation
Im Folgenden werden die zugehörigen Schritte beschrieben. In Kapitel 6, Einrichten der Replikationsumgebung, finden Sie Anweisungen zum Einrichten der
Replikationsumgebung.
Um das System einzurichten, gehen Sie folgendermaßen vor:
- Migration von früheren Releases des DataPropagator-Produkts.
- Erteilen des erforderlichen Zugriffs auf die entsprechenden
Benutzer-IDs.
Um die Replikationskriterien einzurichten, sind folgende Schritte
auszuführen:
- Konfigurieren des Verwaltungs-Tools. Wenn Sie
z. B. mit DJRA arbeiten möchten, müssen Sie den Datenbanken
Kennwörter zuordnen.
- Anpassen und Erstellen von Replikationssteuertabellen.
- Anpassen der CD-Tabellen (Change Data Tables). Dieser Schritt ist
wahlfrei. Sie können den Standardnamen und den Tabellenbereich Ihrer
CD-Tabellen ändern. Bei Verwendung der DB2-Steuerzentrale müssen Sie
Ihre CD-Tabellen ändern, bevor Sie eine Replikationsquelle
definieren. Wenn Sie mit DJRA arbeiten, passen Sie die CD-Tabellen beim
Definieren der Replikationsquelle an.
- Definieren der Replikationsquellen. In diesem Schritt wird auch die
Tabelle oder Sicht, aus der die Daten kopiert werden sollen, und die Art der
zu erfassenden Änderungen festgelegt.
- Definieren von Subskriptionsgruppen und
Subskriptionsgruppeneinträgen. In diesem Schritt wird auch die
Replikationsquelle der Zieltabelle zugeordnet, in die die Änderungen
repliziert werden sollen. Subskriptionsgruppen und
Subskriptionsgruppeneinträge können jederzeit vor dem Starten des
Apply-Programms definiert werden.
- Konfigurieren des Capture-Programms. Dieser Schritt umfasst das
Aktivieren des Quellen-Servers für die Protokollierung und das Erstellen und
Binden des Capture-Programmpakets an den Quellen-Server.
- Konfigurieren des Apply-Programms. Dieser Schritt umfasst das
Erstellen und Binden des Apply-Programmpakets an den Quellen-Server,
Ziel-Server und Steuerungs-Server, sowie das Erstellen und Binden des
Apply-Programms an den Ziel-Server.
11
Wichtig: Beim Einrichten der
Replikationsumgebung müssen Sie das Capture-Programm starten und das Ende des
Initialisierungsvorgangs abwarten, bevor Sie ein Apply-Programm
starten.
Wenn Sie den Replikationsprozess zum ersten Mal initialisieren, müssen Sie
die folgenden Schritte genau in der angegebenen Reihenfolge ausführen:
- Sicherstellen, dass mindestens eine Replikationsquelle definiert
ist.
- Starten des Capture-Programms. Dieser Schritt schließt die Angabe
von Aufrufparametern ein (z. B. des Parameters NOPRUNE, der
das automatische Bereinigen der CD- und UOW-Tabellen verhindert).
Nachdem das Capture-Programm vollständig initialisiert ist, beginnt es mit der
Erfassung von Änderungen - allerdings erst dann, wenn es vom Apply-Programm
eine entsprechende Aufforderung erhält.
- Definieren von mindestens einer Subskriptionsgruppe und einem
Subskriptionsgruppeneintrag (wenn dies nicht bereits geschehen ist).
- Starten eines oder mehrerer Apply-Programme. Dieser Schritt
schließt die Angabe von Aufrufparametern ein (z. B. des
Parameters LOADX, der die Exit-Routine ASNLOAD zum Initialisieren der
Zieltabellen aufruft). Jedes Apply-Programm führt dann eine
vollständige Aktualisierung aller Subskriptionsgruppeneinträge durch, und das
Capture-Programm beginnt mit dem Erfassen von Änderungen für die zugehörigen
Replikationsquellen.
12
Tipp: | Verwenden Sie die Option WARMNS im Capture-Programm, wenn Sie in der Lage
sein möchten, eventuell auftretende Probleme zu beheben
(z. B. nicht verfügbare Datenbanken oder Tabellenbereiche),
die die Ausführung eines Warmstarts verhindern können.
|
Von Zeit zu Zeit ist es erforderlich, neue Replikationsquellen und
Subskriptionsgruppen zur bestehenden Replikationsumgebung hinzuzufügen.
Um die Replikationsumgebung in dieser Weise zu erweitern, müssen Sie die
folgenden Schritte genau in der angegebenen Reihenfolge ausführen:
- Definieren der neuen Replikationsquelle.
- Ausführen des Capture-Befehls reinit oder Stoppen des
Capture-Programms und Ausführen eines Warmstarts.
- Definieren der neuen Subskriptionsgruppen und
Subskriptionsgruppeneinträge.
- Das Apply-Programm erkennt automatisch die neue Subskriptionsgruppe, wenn
das Apply-Programm bereits ausgeführt wird und wenn es das
Apply-Qualifikationsmerkmal verwendet, das der neuen Subskriptionsgruppe
zugeordnet ist. Andernfalls müssen Sie ein neues Apply-Programm unter
Verwendung des richtigen Apply-Qualifikationsmerkmals starten, damit das
Apply-Programm die neue Subskriptionsgruppe erkennen kann.
Wenn Sie die gewünschte Replikationsumgebung auf einem System
(z. B. einem Testsystem) definiert haben, können Sie die
Umgebung auf ein anderes System kopieren (z. B. ein
Produktionssystem). Mit den Übertragungsfunktionen (Promote Functions)
können Sie ein "Reverse-Engineering" der Tabellen, Replikationsquellen und
Subskriptionsgruppen vornehmen und eine Prozedurdatei (Script File) mit der
entsprechenden Datendefinitionssprache (Data Definition Language = DDL) und
Datenbearbeitungssprache (Data Manipulation Language = DML) erstellen.
Weitere Informationen zu den Übertragungsfunktionen finden Sie im Abschnitt Kopieren der Replikationskonfiguration auf ein anderes System und in der Online-Hilfe der Verwaltungsschnittstelle.
Wenn die Replikationsumgebung in Betrieb ist und Aktualisierungen
repliziert werden, müssen in regelmäßigen Abständen Verwaltungs- und
Pflegearbeiten durchgeführt werden, wie z. B.:
- Konfigurieren der Bereinigung der Steuertabellen
- Die UOW- und CD-Tabellen wachsen zu stark an, wenn sie nicht regelmäßig
bereinigt werden. Die Bereinigung können Sie automatisch vom System
ausführen lassen oder selbst manuell vornehmen. Dabei bestimmen Sie,
wie häufig nicht mehr relevante Informationen aus diesen Tabellen gelöscht
werden. Wenn die Tabellen nicht häufig genug bereinigt werden, kann
dies die Kapazität des Tabellenbereichs, in dem sie gespeichert sind,
erschöpfen und ein Beenden des Capture-Programms erzwingen. Werden die
Tabellen zu häufig oder zu Zeiten hoher Systembelastung bereinigt, entstehen
Konflikte zwischen der Bereinigung und dem Änderungserfassungsprozess.
Stellen Sie deshalb das für Ihre Replikationsumgebung optimale
Bereinigungsintervall ein.
- Überwachen wichtiger Leistungskriterien
- Die Leistung der Replikationsumgebung wird von vielen Faktoren
beeinflusst. Mit Hilfe des Programms Replication Monitor,
das Bestandteil von DJRA ist, können Sie einen Bericht erstellen, der Sie bei
der Überwachung der Aktivitäten der Programme Capture und Apply und des Status
der Subskriptionsgruppen unterstützt. Beispielsweise enthält der
Bericht Protokollinformationen zur Erkennung von Trends bei
Subskriptionslatenzzeiten.
- Beheben von Konflikten bei der Datenänderung
- Wenn Sie die beliebige Tabellenreplikation verwenden, und Sie haben Ihre
Konfiguration nicht so eingerichtet, dass Aktualisierungskonflikte vermieden
werden, müssen Sie Aktualisierungskonflikte und zurückgewiesene Transaktionen
beheben.
- Ausführen regelmäßiger Datenbankpflege
- Um den reibungslosen Betrieb Ihrer Replikationsumgebung zu gewährleisten,
müssen Sie regelmäßig Arbeiten der Datenbankpflege durchführen.
Beispielsweise ist das Dienstprogramm RUNSTATS für die DB2-Katalogtabellen
auszuführen, um neue statistische Informationen über Tabellen und Indizes zu
sammeln. Das Dienstprogramm RUNSTATS sollte einmal ausgeführt werden,
wenn die CD- und UOW-Tabellen genug Daten enthalten, so dass das
DB2-Optimierungsprogramm (DB2 Optimizer) Indizes für sie verwendet.
Führen Sie außerdem in regelmäßigen Abständen das Dienstprogramm REORG (oder
bei AS/400 den Befehl RGZPFM) für die CD-Tabellen, die UOW-Tabelle und die
Zieltabellen aus. Ferner müssen die Zeilen aus der
Apply-Prüfprotokolltabelle gelöscht werden, die statistische Informationen zu
Subskriptionsgruppen und Fehlerinformationen enthält.
- Abstimmen mit DB2-Dienstprogrammoperationen
- Wenn Sie beabsichtigen, DB2-Dienstprogramme (wie z. B.
REORG, RUNSTATS, BIND PACKAGE und REVOKE) auszuführen, die auf
Tabellenbereiche mit Replikationssteuertabellen zugreifen, müssen Sie die
Programme Capture und Apply stoppen, bevor Sie die Dienstprogramme
ausführen.
- Anpassen der Replikationskonfiguration an veränderte Anforderungen
- Von Zeit zu Zeit muss die Replikationsumgebung an geänderte Anforderungen
angepasst werden. Wenn Sie beispielsweise eine neue Spalte in eine
bestehende Quellentabelle einfügen oder eine Quellentabelle löschen, müssen
Sie die Replikationskriterien ändern. Darüber hinaus müssen die
Kennwortdateien gepflegt werden. Weitere Informationen zum Ändern der
Replikationskonfiguration enthält der Abschnitt Modifizieren der Replikationskonfiguration.
- Fehlerbehebung
- Wenn Ihre Replikationsumgebung nicht das erwartete Leistungsverhalten
zeigt oder wenn Daten nicht repliziert werden können, führen Sie das Programm
Replication Analyzer aus. Dieses Tool ist im Produktumfang
von DB2 Universal Database und DataJoiner Replication Administration (DJRA)
enthalten. Sie können mit Replication Analyzer das Leistungsverhalten
der Programme Capture und Apply analysieren. Beispielsweise kann
ermittelt werden, warum das Capture-Programm Daten nicht erfasst oder warum
das Apply-Programm erfasste Daten nicht anwendet. Das Programm
Replication Analyzer bietet Unterstützung bei der Fehlerdiagnose und beim
Prüfen der Replikationskonfiguration und bietet Vorschläge zur
Leistungsverbesserung. Statusinformationen zum Apply-Programm sind
ferner in der Apply-Prüfprotokolltabelle enthalten, Statusinformationen zum
Capture-Programm in der Trace-Tabelle des Capture-Programms. Weitere
Informationen enthält Kapitel 8, Fehlerbestimmung.
Allgemeine Informationen zum Betrieb in einer Replikationsumgebung finden
Sie in Kapitel 7, Betrieb von DB2 DataPropagator. Näheres zum Betrieb der Programme Capture und Apply
auf den verschiedenen Plattformen enthalten die einzelnen Kapitel in Teil 3, Betrieb.
Fußnoten:
- 11
-
Wenn das Capture-Programm und das Apply-Programm nicht unter OS/390 ausgeführt
werden, erfolgt das Binden automatisch.
- 12
-
Wenn Sie Ladedienstprogramme anderer Hersteller verwenden, wird empfohlen, die
Offline-Ladefunktion von DJRA zu verwenden. Weitere Informationen zum
Einrichten der Offline-Ladefunktion bei DJRA enthält der Abschnitt Laden von Zieltabellen im Offline-Betrieb mit DJRA.
[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]