In diesem Kapitel werden die Schritte zum Einrichten und Starten einer Replikationsumgebung beschrieben. Das Kapitel enthält keine Einzelheiten zum Betrieb der Programme Capture und Apply bei den verschiedenen Betriebssystemen. Näheres dazu können Sie in Teil 3, Betrieb, nachlesen.
Zum Einrichten der Replikationsumgebung sind folgende Schritte auszuführen:
Zum Definieren von Replikationsquellen und -zielen, zum Festlegen des Zeitplans für die Aktualisierung der Zieltabellen, zur Modifizierung der Zieldaten und zum Definieren von Replikationsauslösern können entweder die DB2-Steuerzentrale oder das Verwaltungs-Tool DB2 DataJoiner Replication Administration (DJRA) verwendet werden. Die DB2-Steuerzentrale kann nur dann zur Replikationsverwaltung eingesetzt werden, wenn sich Ihre Quellen- und Zieltabellen in DB2 Universal Database-Datenbanken (in einer beliebigen Betriebssystemumgebung) befinden. Beim Verwaltungs-Tool DJRA besteht diese Einschränkung nicht. Es kann auch dann zur Replikationsverwaltung verwendet werden, wenn die Quellen- und Zieltabellen in DB2 Universal Database-Datenbanken (unter einem beliebigen Betriebssystem) oder in unterstützten Datenbanken anderer Hersteller gespeichert sind.
Die in diesem Kapitel beschriebenen Verwaltungsaufgaben definieren die Steuerinformationen, die von den Programmen Capture und Apply zum Erfassen geänderter Daten und zum Replizieren dieser Daten in die Zieltabellen (im richtigen Format und in sinnvollen Intervallen) verwendet werden.
Beim Einrichten der Replikationsumgebung können Sie die DB2-Steuerzentrale zum Verwalten der Definitionen von Quellen- und Zieltabellen und der Steuertabellen verwenden. Die folgende Liste beschreibt ganz allgemein die Schritte zur Verwaltung von Replikationsobjekten:
Nach dem Erstellen der Steuertabellen und Definieren der Quellen und Ziele für die Replikation müssen Sie die Programme Capture und Apply konfigurieren und ausführen, um mit dem Replizieren der Daten zu beginnen.
Über die Steuerzentrale greifen Sie auf Ihre Replikationsquellen und -ziele zu. Die Objekte, die Sie zum Einrichten und Verwalten Ihrer Replikationsumgebung verwenden, sind in drei Ordnern in der Steuerzentrale enthalten:
Jedes Objekt verfügt auch über ein Menü (Kontextmenü) mit Aktionen, die für das Objekt ausgeführt werden können.
Um von der Steuerzentrale eine Verbindung zu einem DB2 für MVS/ESA-, DB2 für VSE-, DB2 für VM- oder DB2 für AS/400-Server herzustellen, müssen Sie die Konnektivität zu den fernen Datenbanken konfigurieren, die fernen Datenbanken katalogisieren und Pakete an die fernen Datenbanken binden.
Um die Datenbank zu binden, gehen Sie folgendermaßen vor:
DB2 CONNECT TO dbname USER benutzerid USING kennwort DB2 BIND @DDCSxxx.LST ISOLATION CS BLOCKING ALL SQLERROR CONTINUE
Dabei gibt CS die Isolationsstufe CS an (CS = Cursor Stability), und xxx steht für den Namen der Plattform: MVS, VSE, VM oder AS/400.
Wenn die Benutzer-ID und das Kennwort nicht mit der lokalen Anmelde-ID und dem Kennwort auf der Workstation der Steuerzentrale übereinstimmen, müssen Sie eine explizite Verbindung zum Datenbank-Server herstellen. Wählen Sie dazu die Menüauswahl Verbinden im Kontextmenü des Symbols Ihres fernen Datenbankobjekts aus.
Das Notizbuch "Tools - Einstellungen" enthält Standardvorgaben für die Verwaltungs-Tools von DB2 Universal Database. Auf der Seite "Replikation" des Notizbuchs können Sie Standardwerte für die Replikation definieren (vgl. Abbildung 19). Diese Standardwerte werden bei allen Replikationsaktivitäten verwendet, die über die Steuerzentrale verwaltet werden.
Abbildung 19. Die Seite "Replikation" im Notizbuch "Tools - Einstellungen". Verwenden Sie diese Seite, um Standardeinstellungen für die Replikation zu definieren.
Beim Definieren von Replikationsquellen und Subskriptionsgruppen können Sie CD-Tabellennamen, Indexnamen und Tabellenbereichsnamen anpassen. Sie können die Schablonendatei DPREPL.DFT im Arbeitsverzeichnis der Steuerzentrale (\sqllib\bin oder \sqllib\java) editieren, um diese Namen zu ändern. Die zu verwendende Syntax und einige Beispiele können Sie den Anweisungen in der Datei entnehmen.
Auf der Seite "Replikation" im Notizbuch "Tools - Einstellungen" geben Sie an, dass Sie diese Datei verwenden wollen. Vgl. Abbildung 19.
Wenn Sie das Verwaltungs-Tool DB2 DataJoiner Replication Administration (DJRA) zur Replikationsverwaltung einsetzen, stellt DJRA eine Verbindung zum Quellen-, Ziel- oder Steuerungs-Server her und ermöglicht so das Erstellen und Aktualisieren der Steuerinformationen und Zieltabellen auf dem Server (abhängig von der ausgeführten Operation). Die Client-Workstation, auf der DJRA installiert ist, muss für alle von DJRA verwalteten Quellen-, Ziel- und Steuerungs-Server berechtigt sein und eine Verbindung zu diesen Servern herstellen können.
DJRA stellt Objekte und Aktionen zur Verfügung, mit denen die Definitionen von Quellen- und Zieltabellen erstellt und verwaltet werden können. Als Komponente von DB2 DataJoiner erstellt DJRA:
Das Apply-Programm verwendet dann die DB2 DataJoiner-Kurznamen für Lese- und Schreiboperationen, wodurch eine Verbindung zu Datenbanken anderer Hersteller nicht mehr explizit hergestellt werden muss.
Wenn die Quellendatenbank eine DB2-Datenbank ist, werden die Änderungen für diese Datenbank vom Capture-Programm erfasst. Somit sind die Capture-Auslöser und DB2 DataJoiner nicht beteiligt. Ist die Zieldatenbank eine DB2-Datenbank, schreibt das Apply-Programm die geänderten Daten direkt in die DB2-Zieldatenbank, und DB2 DataJoiner ist nicht beteiligt.
DJRA repliziert zusammen mit DB2 DataJoiner, dem Capture-Programm, den Capture-Auslösern und dem Apply-Programm relationale Daten zwischen einer Vielzahl von Quellen und Zielen. DJRA unterstützt folgende Datenbanken als Quelle oder Ziel:
Bei DB2-Quellen-, DB2-Ziel- und DB2-Steuerungs-Servern sorgt die DB2 DataJoiner-Komponente Distributed Database Connection Services (DDCS) oder das Produkt DB2 Connect für die erforderliche Konnektivität. Wenn Sie mit Quellen und Zielen anderer Hersteller arbeiten, stellt DJRA die Verbindung zu den Servern anderer Hersteller über DB2 DataJoiner her.
Die Benutzerschnittstelle von DJRA ist in verschiedene Bereiche für Steuertabellen, Replikationsquellen, Subskriptionsgruppen und das Ausführen oder Editieren von SQL-Anweisungen unterteilt (siehe Abbildung 20).
Über diese Schnittstelle können Sie die folgenden Verwaltungsaufgaben ausführen:
Sie können die Programmlogik für die meisten der hier aufgeführten Verwaltungsaufgaben an Ihre spezifischen Anforderungen anpassen.
Abbildung 20. Das DJRA-Hauptfenster
Bei der Installation von DB2 UDB auf einem Windows-System kopiert das DB2-Installationsprogramm das DJRA-Installationsprogramm (djra.exe) in das Verzeichnis \sqllib\djra. DJRA ist auch im Programm DB2 DataJoiner V2 enthalten; wenn Sie DataJoiner unter Windows NT installieren, haben Sie die Möglichkeit, auch DJRA zu installieren. Außerdem können Sie DJRA aus dem Web herunterladen. 24 Ist bei der Installation von DJRA die Software ObjectREXX noch nicht installiert, wird sie mit DJRA installiert. Andernfalls wird Ihr vorhandenes ObjectREXX verwendet.
DJRA wird in folgenden Umgebungen unterstützt:
Um DJRA zu installieren, gehen Sie folgendermaßen vor:
Sie können folgende Einstellungen definieren:
Zum Definieren der Einstellungen wählen Sie File -> Preferences aus dem Menü im DJRA-Hauptfenster. Sie können die Einstellungen jederzeit ändern.
Auf der Seite "Connection" des Notizbuchs "Preferences" wird eine Liste der Datenbanken angezeigt, die zurzeit auf Ihrem System katalogisiert sind.
Einschränkung: Wenn Sie Microsoft SQL Server in Ihrer Replikationsumgebung einsetzen, dürfen Sie keinen Aliasnamen als Benutzer-ID verwenden. Microsoft SQL weist die Alias-Benutzer-ID zurück.
Bei DJRA können Sie Zwischenspeichertabellen, Indizes, Prädikate usw. anpassen, indem Sie den entsprechenden Knopf "Edit Logic" in den folgenden Fenstern auswählen:
Empfehlung: Wenn sich die Quellentabelle in einer Datenbank eines anderen Herstellers befindet, ändern Sie den Eigner der CCD-Tabelle nicht.
Sie haben auch die Möglichkeit, den Knopf Edit Logic im Fenster "Define Multiple Tables as Replication Sources" auszuwählen. In diesem Fall müssen Sie eine Zahl aus drei Ziffern am Ende des Parameterwerts CD_TABLE (oder CCD_TABLE) anfügen; DJRA erhöht diese Zahl automatisch, um sicherzustellen, dass jede Tabelle einen eindeutigen Namen hat.
Sie können die verwendeten Positionen für die Tabellenbereiche festlegen, indem Sie das Standardverzeichnis (C:\) ändern. Vergessen Sie nicht, einen umgekehrten Schrägstrich (\) nach dem Verzeichnisnamen einzugeben.
Wählen Sie den Knopf Edit Create Table Logic aus, um den Tabellenbereich oder das Segment anzugeben, in dem Zieltabellen erstellt werden.
Sie können die verwendeten Positionen für die Tabellenbereiche festlegen, indem Sie das Standardverzeichnis (C:\) ändern. Vergessen Sie nicht, einen umgekehrten Schrägstrich (\) nach dem Verzeichnisnamen einzugeben.
Sie haben auch die Möglichkeit, den Knopf Edit Predicate Logic oder Edit Create Table Logic im Fenster "Add Multiple Members to Subscription Sets" auszuwählen.
Die Replikationssteuertabellen werden normalerweise mit einem der folgenden Verfahren erstellt:
Die Datei enthält Kommentare, denen Sie entnehmen können, wie die SQL-Anweisungen für eine bestimmte Datenbankplattform angepasst werden können. Die Datei DPCNTL muss bezüglich folgender Definitionen angepasst werden:
Wenn Sie sich für diese Möglichkeit entscheiden, können Sie die Replikationssteuertabellen nicht anpassen, ohne die vorhandenen Steuertabellen zu löschen und eine Anpassung vorzunehmen. Wenn Sie auf der OS/390-, VSE/ESA- oder VM/ESA-Plattform arbeiten, müssen Sie die Replikationssteuertabellen anpassen.
Beim Erstellen angepasster Steuertabellen müssen Sie die CREATE TABLE-Anweisungen in den DPCNTL-Dateien anpassen. Für jedes Betriebssystem befindet sich eine Datei DPCNTL im Verzeichnis sqllib\samples\repl\. Die Dateien haben folgende Namen:
Wenn angepasste Steuertabellen wieder gelöscht werden sollen, müssen Sie die DROP TABLE-Anweisungen in den DPCNTL-Dateien anpassen. Für jedes Betriebssystem befindet sich eine Datei DPNCNTL im Verzeichnis sqllib\samples\repl\. Die Dateinamen sind:
Um die SQL-Anweisungen zum Erstellen oder Löschen der Steuertabellen anzupassen, gehen Sie folgendermaßen vor:
db2 -tf dpcntl.plattformname db2 -tf dpncntl.plattformname
Auf jedem an der Replikation beteiligten DB2-System (und DataJoiner-System) müssen Steuertabellen erstellt werden. 25 Wenn Sie diesen Arbeitsschritt durchgeführt haben, erstellt DJRA eine Registriertabelle, eine Löschsteuertabelle und eine Synchronisationstabelle für Registrierinformationen in der Datenbankquelle (bei Quellen anderer Hersteller werden Kurznamen für diese Tabellen in DB2 DataJoiner erstellt).
Klicken Sie im DJRA-Hauptfenster die Auswahl Create Replication Control Tables. Folgende Felder sind zum Erstellen einer Steuertabelle auszufüllen:
Geben Sie (None) an, wenn die Steuertabellen in der DataJoiner-Datenbank und nicht in der fernen Server-Datenbank erstellt werden sollen.
Wenn die Prozedur erfolgreich ausgeführt wurde, sichern Sie die Datei durch Auswahl von File->Save. Anschließend können Sie die generierten SQL-Anweisungen bei Bedarf editieren. Dabei sind die Richtlinien zu beachten, die im Abschnitt Anpassen und Ausführen von SQL-Dateien für Replikationsaktionen beschrieben sind. Wenn Sie die gewünschten Änderungen vorgenommen haben, führen Sie die SQL-Anweisungen durch Auswahl von File->Run aus. Die SQL-Anweisungen müssen gesichert werden, bevor sie ausgeführt werden können. Ferner müssen die SQL-Anweisungen zum Generieren der Steuertabellen vor den SQL-Anweisungen zum Erstellen von Replikationsquellen oder Subskriptionsgruppen generiert und ausgeführt werden.
Bei Verwendung der DB2-Steuerzentrale haben Sie die Möglichkeit, eine Replikationsaufgabe unmittelbar auszuführen oder die generierten SQL-Anweisungen in einer Datei zu speichern und diese zu einem späteren Zeitpunkt auszuführen. Bei DJRA können Sie SQL-Dateien vom Hauptfenster aus editieren und ausführen. Die SQL-Dateien können für umfangreiche Replikationsaktionen (z. B. für das Definieren von Subskriptionsgruppen) oder für Anwendungsfälle, die über die von der Steuerzentrale oder von DJRA unterstützten Implementierungen hinausgehen, angepasst werden.
SQL-Dateien können zur Ausführung der folgenden Aufgaben gesichert und angepasst werden:
Wenn Sie die Definitionen einer umfangreichen Replikationssubskriptionsgruppe in einer SQL-Datei sichern, können Sie die Definitionen nach Bedarf wiederholen.
Achten Sie beim Editieren der generierten SQL-Anweisungen darauf, dass Sie die speziellen DJRA-Codes innerhalb der Anweisungen unverändert lassen. So ist beispielsweise :ENDOFTRIGGER: oder :ENDOFPROCEDURE: Teil eines Kommentars, der für die erfolgreiche Ausführung von DJRA erforderlich ist. Wenn Sie die Befehlsblöcke zum Erstellen von Auslösern ändern, sind die SQL-Anweisungen möglicherweise fehlerhaft und können nicht ausgeführt werden. Wenn Sie am Ende der Datei neue Zeilen einfügen, stellen Sie sicher, dass Sie am Dateiende auf jeden Fall wieder ein Zeilenvorschubzeichen (CRLF) einfügen.
Der Druckknopf Run SQL bei DJRA dient zum Ausführen der von DJRA generierten SQL-Anweisungen. SQL-Anweisungen, die Sie mit anderen Verfahren generiert haben, können möglicherweise über DJRA nicht erfolgreich ausgeführt werden. Ebenso ist es eventuell nicht möglich, über DJRA generierte SQL-Anweisungen in der DB2-Befehlszeile auszuführen.
Empfehlung: Führen Sie die über DJRA generierten SQL-Anweisungen generell über DJRA aus.
Da DB2 DataPropagator vollständig auf Tabellen basiert, hängt die Sicherheit aller Replikationsobjekte von der Datenbanksicherheit ab. Der Datenbankadministrator, der die Replikationsquellen und Subskriptionsgruppen definiert, ist auch für das Definieren der zu verwendenden Sicherheitsmechanismen zuständig. Außerdem muss das Capture-Programm für den Zugriff auf die Quellendatenbank und das Apply-Programm für den Zugriff auf die Steuerungs-, Quellen- und Zieldatenbank berechtigt sein.
Wenn Sie Replikationsquellen und Subskriptionsgruppen definieren, werden eine Reihe von Tabellen von der DB2-Steuerzentrale und von DJRA erstellt. Bei einigen Betriebssystemen werden dabei auch Tabellenbereiche oder Datenbankbereiche (DBSPACEs) erstellt. Für diese Aktionen ist eine umfassende Datenbankberechtigung erforderlich. Deshalb sollten Sie mindestens eine Benutzer-ID einplanen, mit der der Replikationsadministrator arbeitet und die über die Berechtigung zum Erstellen von Objekten, zum Binden von Zugriffsplänen und zum Ausführen von SQL-Anweisungen für alle Quellendatenbanken verfügt.
Die Benutzer-ID, über die das Capture-Programm ausgeführt wird, muss über folgende Berechtigungen verfügen: Zugriff auf den DB2-Systemkatalog, Zugriffs- und Aktualisierungsberechtigung für alle Replikationssteuertabellen sowie die Ausführungsberechtigungen für die Capture-Programmpakete. Die Benutzer-ID, über die das Capture-Programm ausgeführt wird, und die Administrator-ID können (müssen aber nicht notwendigerweise) identisch sein.
Bei OS/390 sollte die Benutzer-ID, über die das Capture-Programm ausgeführt wird, entweder über die Berechtigung SYSADM oder über die folgenden Berechtigungen verfügen:
Bei VM und VSE muss die Benutzer-ID, über die das Capture-Programm ausgeführt wird, über die DBA-Berechtigung verfügen. Bei allen anderen Betriebssystemen muss die Benutzer-ID, über die das Capture-Programm ausgeführt wird, entweder über die Berechtigung DBADM oder über die Berechtigung SYSADM verfügen.
Die Benutzer-ID, über die das Apply-Programm ausgeführt wird, muss eine gültige Anmelde-ID für die Quellen-, Steuerungs- und Ziel-Server sein sowie für die Workstation, auf der die Steuerzentrale oder DJRA installiert ist. Die Benutzer-ID, über die das Apply-Programm ausgeführt wird, muss über folgende Berechtigungen verfügen: Zugriff auf die Quellentabellen, Zugriffs- und Aktualisierungsberechtigung für alle Replikationssteuertabellen sowie die Aktualisierungsberechtigung für die Zieltabellen. Diese Benutzer-ID muss außerdem über die Ausführungsberechtigungen für die Pakete des Apply-Programms verfügen. Die Benutzer-ID, über die das Apply-Programm ausgeführt wird, und die Administrator-ID können (müssen aber nicht notwendigerweise) identisch sein. Jede Benutzer-ID kann, wenn sie über die entsprechende Berechtigung verfügt, ein beliebiges Exemplar des Apply-Programms ausführen.
Ein Apply-Programm benötigt möglicherweise eine Kennwortdatei, um die Verbindung zum Quellen- oder Ziel-Server herzustellen. Weitere Informationen zu Berechtigungen für das Apply-Programm finden Sie im Kapitel über Capture und Apply für Ihr Betriebssystem (Teil 3, Betrieb).
Um eine Replikationsquelle über die DB2-Steuerzentrale zu definieren, gehen Sie folgendermaßen vor:
Klicken Sie den Ordner Tabellen für die Quellendatenbank an, um alle Tabellen anzuzeigen. Klicken Sie ein Tabellenobjekt mit der rechten Maustaste an. In dem daraufhin angezeigten Kontextmenü wählen Sie Als Replikationsquelle definieren aus.
Sie können Replikationsquellen über die Auswahlmöglichkeiten Standard oder Angepasst definieren. Bei Auswahl von Standard wird eine Replikationsquelle mit den Standardwerten definiert. Bei Auswahl von Angepasst können Sie die Standardwerte anpassen (z. B. können Sie angeben, dass bestimmte Spalten nicht erfasst werden sollen).
Wenn Sie die Replikationsquelle definiert haben, wird ein Objekt im Ordner Replikationsquellen erstellt. Die Quellentabelle kann anschließend in einer Subskriptionsgruppe definiert werden.
Um eine Replikationsquelle über DJRA zu definieren, gehen Sie folgendermaßen vor:
Klicken Sie Define One Table as a Replication Source oder Define Multiple Tables as Replication Sources an, und geben Sie anschließend die erforderlichen Informationen an (z. B. den Quellen-Server, die Quellentabellennamen und die Quellenspalten).
Weitere Informationen zu Capture-Auslösern enthält der Abschnitt Capture-Auslöser für Quellen anderer Hersteller. Informationen zu Einschränkungen, die beim Definieren von Replikationsquellen und Subskriptionsgruppen zu beachten sind, enthält der Abschnitt Allgemeine Einschränkungen bei der Replikation.
Das Capture-Programm erkennt neue DB2-Replikationsquellen erst, nachdem Sie den Befehl reinit oder den Befehl stop abgesetzt und anschließend das Capture-Programm erneut gestartet haben. Das Capture-Programm beginnt erst dann mit dem Erfassen von Änderungen für eine Replikationsquelle, wenn eine Subskriptionsgruppe für die Replikationsquelle erstellt und eine vollständige Aktualisierung für die Subskriptionsgruppeneinträge ausgeführt wurde.
Um eine Replikationsquelle für die beliebige Tabellenreplikation über die DB2-Steuerzentrale zu definieren, gehen Sie folgendermaßen vor:
Definieren Sie eine Replikationsquelle mit benutzerdefinierten Werte, und gehen Sie bei der Auswahl folgendermaßen vor:
Achtung: Miteinander in Konflikt stehende Aktualisierungen zwischen Quellentabelle und Replikat werden in diesem Fall nicht erkannt. Diese Option wird deshalb für die beliebige Tabellenreplikation nicht empfohlen.
Bei Auswahl dieser Option wählt die DB2-Steuerzentrale automatisch auch die Markierungsfelder Als Quelle definieren und Vorabbild erfassen für jede Spalte aus.
Wenn das Apply-Programm in einer zeitweise verbundenen Umgebung ausgeführt wird (d. h. über den Befehl asnsat oder unter Verwendung des Schlüsselworts COPYONCE gestartet wurde), verwendet das Apply-Programm auch dann die Standardkonflikterkennung, wenn die erweiterte Konflikterkennung angefordert wurde.
Um eine Replikationsquelle für die beliebige Tabellenreplikation über DJRA zu definieren, gehen Sie folgendermaßen vor:
Wählen Sie die Konflikterkennungsebene (wie oben beschrieben) aus, wenn Sie eine Tabelle als Replikationsquelle definieren, und wählen Sie die Zieltabellenstruktur "Replikat" aus, wenn Sie den Eintrag zur Subskriptionsgruppe hinzufügen.
Wenn Sie die beliebige Tabellenreplikation verwenden, ist Folgendes zu beachten:
Zur Vermeidung des Konfliktrisikos und des Zusatzaufwands durch Transaktionen, die auf Grund eines aufgetretenen Konflikts zurückgewiesen wurden, sollte die beliebige Tabellenreplikation unter folgenden Bedingungen verwendet werden:
Bei der beliebigen Tabellenreplikation können Aktualisierungskonflikte auftreten, wenn
Das Apply-Programm erkennt aufgetretene Aktualisierungskonflikte während des Subskriptionszyklus. Die Quellentabelle wird als Primärtabelle angesehen. D. h., sie kann Aktualisierungen von einer Replikattabellen erhalten. Liegt jedoch ein Konflikt vor, "gewinnt" die Quellentabelle, und die in Konflikt stehenden Transaktionen der Replikattabellen werden zurückgewiesen. Das Apply-Programm erkennt direkte Zeilenkonflikte durch Vergleichen der Schlüsselwerte in den CD-Tabellen mit den Quellen- und Zieltabellen. Wenn eine Übereinstimmung gefunden wird, wird die Replikattransaktion in der UOW-Tabelle als "zurückgewiesen" markiert und die Replikattransaktion rückgängig gemacht.
Das Apply-Programm ist nicht in der Lage, Leseabhängigkeiten zu erkennen. Wenn beispielsweise eine Anwendung Daten liest, die anschließend entfernt werden (durch eine Anweisung DELETE oder durch eine rückgängig gemachte Transaktion), kann das Apply-Programm die Abhängigkeit nicht erkennen.
DB2 DataPropagator bietet drei Konflikterkennungsebenen: keine Erkennung, Standarderkennung und erweiterte Erkennung. Jede Ebene hat einen eigenen numerischen Wert, der in der Spalte CONFLICT_LEVEL der Registriersteuertabelle gespeichert wird. Sie müssen auf der Basis Ihres Toleranzspielraums für verlorene oder zurückgewiesene Transaktionen und Leistungsanforderungen entscheiden, welche Art der Erkennung Sie verwenden wollen. Weitere Informationen zu den Konflikterkennungsebenen und dazu, wie sie angegeben werden, kann unter Definieren von Replikationsquellen für die beliebige Tabellenreplikation nachgelesen werden.
Einschränkung: Obwohl Sie die Konflikterkennungsebene für die Replikationsquellen einzeln festlegen, verwendet das Apply-Programm jeweils die höchste Konflikterkennungsebene jedes Subskriptionsgruppeneintrags für alle Einträge der Gruppe.
Anhand der Zurückweisungscodes aus der UOW-Tabelle können Sie die Vorher- und Nachher-Zeilenwerte in der CD-Tabelle für jede zurückgewiesene Transaktion identifizieren. Da die Exit-Routine ASNDONE zum Ende jedes Subskriptionszyklus ausgeführt wird, können Sie eigenen Programmcode zur Behandlung zurückgewiesener Transaktionen in die Routine aufnehmen. Weitere Informationen zur Exit-Routine ASNDONE finden Sie im Abschnitt Verwendung der Exit-Routine ASNDONE. Da die CD-Zeilen und die Zeile der UOW-Steuertabelle für zurückgewiesene Transaktionen vom normalen Bereinigungsvorgang ausgenommen sind (sie unterliegen allerdings der RETENTION_LIMIT-Bereinigung), haben Sie alternativ die Möglichkeit, die zurückgewiesenen Transaktionen unter Verwendung eines Programms, das die UOW-Tabelle durchsucht, als Stapel zu bearbeiten.
Sie können Replikationsquellen definieren, die Sichten von anderen Tabellen sind. Nachdem alle in der Sicht enthaltenen Replikationsquellentabellen definiert wurden, können Sie eine Sichtreplikationsquelle erstellen. Die Sichtreplikationsquelle kann dann in eine Zieltabelle repliziert werden.
Mit der DB2-Steuerzentrale können bestehende Sichten nicht als Replikationsquellen verwendet werden. Mit DJRA ist dies allerdings möglich. Sie können die DB2-Steuerzentrale verwenden, um eine neue Sicht als Replikationsquelle zu definieren.
Um unter Verwendung der DB2-Steuerzentrale eine Sicht zu definieren, gehen Sie folgendermaßen vor:
USERID.VIEW_NAME AS SELECT A.COL1, A.COL2, B.COL6, B.COL5
Die Schlüsselwörter CREATE VIEW dürfen nicht eingegeben werden. Dieser Teil der Anweisung wird während der Verarbeitung automatisch bereitgestellt.
TABLEA A, TABLEB B
Das Schlüsselwort FROM darf nicht eingegeben werden. Dieser Teil der Anweisung wird während der Verarbeitung automatisch bereitgestellt.
A.COL1=B.COL1
Das Schlüsselwort WHERE darf nicht eingegeben werden. Dieser Teil der Anweisung wird während der Verarbeitung automatisch bereitgestellt.
Um eine Sicht über DJRA als Replikationsquelle zu definieren, gehen Sie folgendermaßen vor:
Klicken Sie Define DB2 Views as Replication Sources an, und geben Sie anschließend die erforderlichen Informationen an (z. B. Quellen-Server, Qualifikationsmerkmal und Name der Quellensicht). Bei DJRA können Sie eine Verknüpfung nicht als Replikationsquelle definieren, Sie haben aber die Möglichkeit, eine Sicht für die Verknüpfung zu definieren und anschließend DJRA zu verwenden, um die Sicht als Replikationsquelle zu definieren.
Im Allgemeinen werden Aktualisierungen an Quellentabellen als UPDATE-Anweisung erfasst. Unter folgenden Bedingungen müssen Sie das Capture-Programm jedoch ausdrücklich anweisen, DELETE- und INSERT-Anweisungen als Aktualisierungen zu erfassen (d. h., Sie müssen die Unterstützung logischer Partitionierungsschlüssel aktivieren):
Da sich die Werte für den Primärschlüssel der Zieltabelle erst aus den auf dem Quellen-Server erfassten Änderungen ergeben, die die neuen Schlüsselwerte wiedergeben, können diese Werte nicht zum Lokalisieren der bestehenden Zieltabellenzeile verwendet werden (da sie noch nicht zur Verfügung steht). Das Umsetzen einer UPDATE-Operation in ein Paar aus DELETE- und INSERT-Operation stellt sicher, dass die Zieltabelle die auf dem Quellen-Server vorgenommenen Änderungen widerspiegelt.
In diesem Fall muss die im Prädikat enthaltene Spalte keine Primärschlüsselspalte sein. Wenn eine Subskriptionsgruppe mit einem Prädikat auf der Basis eines bestimmten Spaltenwerts definiert wird (z. B. WHERE DEPT = 'J35'), und Sie ändern diese Spalte (z. B. in DEPT='FFK'), wird die erfasste Änderung nicht für die Replikation ausgewählt, weil sie nicht den Prädikatkriterien entspricht. D. h., Ihre neue Abteilung FFK wird nicht repliziert, weil Ihre Subskription auf Abteilung J35 basiert. Das Umsetzen einer UPDATE-Operation in ein Paar aus DELETE- und INSERT-Operation stellt sicher, dass die Zeile in der Zieltabelle gelöscht wird.
Durch das Aktivieren der Unterstützung logischer Partitionierungsschlüssel wird sichergestellt, dass die Zielzeilen von einem Knoten an einen anderen verschoben werden, wenn die Quellenspalte für den logischen Partitionierungsschlüssel geändert und repliziert wird. Das Verschieben erfolgt durch eine DELETE-Operation auf dem alten Knoten und eine INSERT-Operation auf dem neuen Knoten.
Aktualisierungen können entweder als solche oder als Paare aus einer Löschung und einer Einfügung erfasst werden. Das gilt sowohl für DB2-Quellen als auch für Quellen in anderen Datenbanken.
Standardmäßig erfasst das Capture-Programm die geänderte Zeile für die Aktualisierung, wenn die Primärschlüssel der Quellen- oder Zieltabellen aktualisiert werden. Danach versucht das Apply-Programm, eine Zeile in der Zieltabelle mit dem neuen Schlüsselwert zu aktualisieren. Da dieser neue Schlüsselwert in der Zieltabelle nicht gefunden wird, wandelt das Apply-Programm die Aktualisierung in eine Einfügeoperation um. In diesem Fall verbleibt die alte Zeile mit dem alten Schlüsselwert unnötigerweise in der Tabelle. Wenn Sie die Unterstützung für logische Partitionierungsschlüssel bei der Replikation aktivieren, erfasst das Capture-Programm die Änderung als separate DELETE- und INSERT-Anweisungen: als Löschen der alten Zeile und Einfügen der neuen Zeile.
Bei DATALINK-Spalten, die als ON UNLINK DELETE definiert sind, wird das Aufheben der Verbindung ignoriert, da ein DELETE/INSERT-Paar innerhalb derselben Transaktion verarbeitet wird. Die externe Datei wird nicht gelöscht, sondern aktualisiert.
Jede erfasste UPDATE-Operation wird in zwei Zeilen in der CD-Tabelle umgesetzt. Dies gilt für alle Spalten (Schlüsselspalten und Spalten ohne Schlüsselfunktion). Möglicherweise müssen Sie die Bereichszuordnung der CD-Tabelle anpassen, damit sie die zusätzlich erfassten Daten aufnehmen kann.
Wenn Sie die DB2-Steuerzentrale zum Definieren der Quellentabelle verwenden, wählen Sie das Markierungsfeld Geänderte Daten für Spalten mit Partitionierungsschlüsseln als DELETE- bzw. INSERT-Vorgang erfassen im Fenster "Als Replikationsquelle definieren" aus, um anzugeben, dass das Capture-Programm die Aktualisierungen als DELETE- und INSERT-Anweisungen erfassen soll.
Wenn Sie DJRA zum Definieren der Quellentabelle verwenden, wählen Sie den Radioknopf Updates as Delete/Insert Pairs im Fenster "Define One Table as a Replication Source" oder im Fenster "Define Multiple Tables as Replication Sources" aus.
Empfehlung: Verwenden Sie DJRA zum Definieren von CCD-Tabellen. Die DB2-Steuerzentrale kann zwar ebenfalls CCD-Tabellen erstellen, sie gibt Ihnen aber nicht die Möglichkeit, diese Tabellen direkt zu definieren.
Zum Definieren einer CCD-Tabelle mit DJRA wählen Sie CCD als Target Structure im Fenster "Add Member to a Subscription Set" aus und klicken anschließend den Druckknopf Setup an. Wählen Sie die gewünschte Tabellenart der CCD-Tabelle im Fenster "Staging (CCD) table property selection for target server" aus. In diesem Fenster werden alle gültigen Kombinationen von CCD-Tabellen angegeben.
Unvollständige CCD-Tabellen können eine oder mehrere Spalten aus der UOW-Tabelle enthalten. Diese Spalten sind für Prüfzwecke nützlich und enthalten Apply-Qualifikationsmerkmale, Berechtigungs-IDs, UOW-IDs usw.
Wenn Sie eine CCD-Tabelle zum Zwischenspeichern von Replikationen (beispielsweise in einer dreistufigen Replikationsumgebung) verwenden, führen Sie die folgenden Schritte aus:
Das Apply-Programm, zu dem die Subskriptionsgruppe gehört, füllt die CCD-Tabelle gemäß der Subskriptionsgruppendefinition.
Im DJRA-Fenster "Staging (CCD) table property selection for target server" wählen Sie nach der Auswahl einer vollständigen CCD-Tabelle das Markierungsfeld Register as external replication source aus. Weitere Informationen enthält der Abschnitt Definieren von Replikationsquellen.
Diese neue Gruppe ist das Apply-Programm, das Änderungen aus der CCD-Tabelle auf die Zieltabellen anwendet. Normalerweise wird ein anderes Apply-Qualifikationsmerkmal als das zum Füllen der CCD-Tabelle verwendet; Sie können jedoch auch das gleiche verwenden.
Weitere Informationen dazu enthält der Abschnitt Definieren von Replikationssubskriptionsgruppen.
Wählen Sie die Zieltabelle in Abhängigkeit von der verwendeten CCD-Tabelle aus:
Einschränkungen: Zum Registrieren einer internen CCD-Tabelle müssen sich Quellen- und Ziel-Server auf einer Maschine befinden. Für jede Quellentabelle kann nur eine interne CCD-Tabelle registriert werden.
Weitere Informationen zu CCD-Tabellen enthält der Abschnitt Zwischenspeichern von Daten.
Um eine Replikationssubskriptionsgruppe über die DB2-Steuerzentrale zu definieren, gehen Sie folgendermaßen vor:
Wenn Sie angeben, dass das Apply-Programm die Zieltabelle erstellen und diese Tabelle DATALINK-Spalten enthalten soll, gilt für diese Spalten die Standardstufe der Verbindungssteuerung (keine). Soll für diese Spalten eine andere Verbindungssteuerungsstufe gelten, ändern Sie die Anweisung CREATE TABLE in den generierten SQL-Anweisungen und geben eine andere Verbindungssteuerungsstufe an. Anschließend führen Sie die geänderten SQL-Anweisungen aus.
Um eine Replikationssubskriptionsgruppe über DJRA zu definieren, gehen Sie folgendermaßen vor:
Wenn Sie Einträge zu einer Subskriptionsgruppe hinzufügen, können Sie angeben, welcher Primärschlüssel für die Zieltabelle verwendet werden soll. Sie können entweder angeben, dass DJRA den Zielprimärschlüssel aus dem Quellenprimärschlüssel und den Indizes der Quellentabelle generieren soll, oder Sie geben bestimmte Spalten für den Schlüssel an; als dritte Möglichkeit können Sie auch den Quellenprimärschlüssel angeben.
Nachdem Sie Subskriptionsgruppen für einen Quellen-Server eines anderen Herstellers erstellt haben, stellt das Apply-Programm eine Verbindung zu der DB2 DataJoiner-Datenbank her, die diesem Server zugeordnet ist, und greift (über die Kurznamen) auf die Informationen in der Registriersteuertabelle und der Zwischenspeichertabelle auf dem Quellen-Server des anderen Herstellers zu (vgl. Abbildung 21).
Abbildung 21. DB2 DataJoiner in einem Anwendungsbeispiel. Szenario 1 - Die Quellentabelle ist in einer Datenbank eines anderen Herstellers gespeichert (dunkle Pfeile). Über DB2 DataJoiner-Kurznamen erhält das Apply-Programm Zugriff auf den Quellen-Server (Datenbank eines anderen Herstellers) und auf die Änderungen, die an der Quellentabelle vorgenommen werden (über die Zwischenspeichertabelle). Szenario 2 - Die Quellentabelle ist eine DB2-Tabelle (helle Pfeile). Über DB2 DataJoiner-Kurznamen erhält das Apply-Programm Zugriff auf die Zieltabellen in der Datenbank eines anderen Herstellers.
Wenn Sie ein Ereignis zum Starten des Apply-Programms definiert haben, müssen Sie die Ereignistabelle füllen. Weitere Informationen zu dieser Aufgabe finden Sie im Abschnitt Ereignissteuerung. Um mit dem Replizieren von Daten in den Zieltabellen zu beginnen, starten Sie zunächst das Capture-Programm auf dem Quellen-Server und dann das Apply-Programm unter Angabe des Namens des Steuerungs-Servers, den Sie im Fenster "Information zu Subskription" der DB2-Steuerzentrale oder im DJRA-Fenster "Add a Member to Subscription Sets" (oder "Add Multiple Members to Subscription Sets") angegeben haben.
Um unter Verwendung der DB2-Steuerzentrale eine Subskriptionsgruppe für die beliebige Tabellenreplikation zu definieren, müssen Sie eine Subskriptionsgruppe definieren und bei der Auswahl folgendermaßen vorgehen:
Verwenden Sie denselben Primärschlüssel wie in der Quellentabelle, um Konflikte zu vermeiden. Verwenden Sie keine Vorabbildspalten als Primärschlüsselspalten für die Zieltabelle.
Wichtig: Für die bestehenden Zieltabellen müssen Sie die Primärschlüsselspalten auswählen.
Um unter Verwendung von DJRA eine Replikationssubskription für die beliebige Tabellenreplikation zu definieren, wählen Sie die Zieltabellenstruktur "Replikat" aus, wenn Sie den Eintrag zur Subskriptionsgruppe hinzufügen.
Sie können eine bestimmte Art von Zieltabelle angeben, wenn Sie nicht die standardmäßig vorgegebene Zieltabellenart "Benutzerkopie" verwenden möchten.
Um eine Zieltabellenart über die DB2-Steuerzentrale anzugeben, gehen Sie folgendermaßen vor:
Um eine Zieltabellenart über DJRA anzugeben, gehen Sie folgendermaßen vor:
Klicken Sie Add a Member to Subscription Sets oder Add Multiple Members to Subscription Sets an. Geben Sie die erforderlichen Informationen für den Subskriptionsgruppeneintrag an. Sie können die gewünschte Zieltabellenart über die verdeckte Liste Table Structure angeben. Hier sind dieselben Tabellenarten verfügbar wie bei der DB2-Steuerzentrale. Zusätzlich bietet DJRA verschiedene Auswahlmöglichkeiten für CCD-Tabellenarten.
In manchen Anwendungsfällen werden in der Zieltabelle nicht alle Zeilen und Spalten der Quellentabelle benötigt. Sie haben hier die Möglichkeit, die Zieltabelle über die DB2-Steuerzentrale oder DJRA als eine horizontale oder vertikale Untermenge (d. h. eine Zeilen- bzw. Spaltenuntermenge) der Quellentabelle zu definieren. Weitere Informationen zu Untermengen finden Sie im Abschnitt Bilden von Spalten- und Zeilenuntermengen.
Einschränkung: Replikatzieltabellen müssen dieselben Spalten wie die Quellentabelle enthalten. Sie können nicht unterteilt werden oder zusätzliche Spalten enthalten. Auch ein Umbenennen der Spalten ist nicht möglich.
Um die Zieltabellenspalten über die DB2-Steuerzentrale zu definieren, gehen Sie folgendermaßen vor:
Wenn Sie eine Spalte als Primärschlüsselspalte für die Zieltabelle angeben möchten, wählen Sie die Markierungsfelder Primärschlüssel neben den Spaltennamen an.
Achtung: Bei den folgenden Tabellenarten müssen Sie eine oder mehr Spalten als Teil eines Primärschlüssels auswählen: Benutzerkopie, Tabelle mit Zeitangabe, Replikat oder komprimierte Zwischenspeichertabelle. Wenn Sie keine Spalten für den Primärschlüssel auswählen, verwendet DB2 die Primärschlüsseldefinition der Quellentabelle. Verfügt die Quellentabelle allerdings nicht über eine Primärschlüsseldefinition, gibt das Apply-Programm eine Fehlernachricht aus.
Wenn Sie eine Spalte umbenennen möchten, wählen Sie den Spaltennamen aus, und überschreiben Sie den aktuellen Spaltennamen. Ein Spaltenname kann bis zu 17 Zeichen enthalten und eine Standardkennung oder ein begrenzter Bezeichner sein.
Um eine Spaltendefinition für eine Zieltabelle zu ändern, klicken Sie Ändern an, um das Fenster "Spalte ändern" zu öffnen. Über dieses Fenster können Sie folgende Funktionen ausführen:
Dabei kann es sich um einen beliebigen gültigen SQL-Ausdruck mit bis zu 254 Zeichen handeln. Der Ausdruck kann Standardkennungen und begrenzte Bezeichner enthalten. Bei den Spalten, die in dem Ausdruck verwendet werden, muss es sich um gültige Nachabbildspalten aus der Quellentabelle handeln. Die betreffenden Spaltennamen sind im Listenfenster Verfügbare Spalten aufgeführt.
Näheres zu gültigen SQL-Ausdrücken können Sie in der Veröffentlichung DB2 SQL Reference nachlesen. Ungültige SQL-Ausdrücke verursachen einen SQL-Fehler, wenn die Subskription vom Apply-Programm verarbeitet wird.
Wenn Sie eine Spalte aus der Zieltabelle entfernen möchten, inaktivieren Sie das Markierungsfeld Teilnehmen neben dem Spaltennamen.
Um eine neue berechnete Spalte zu erstellen oder um eine Berechnung für die Zieltabelle vorzunehmen, gehen Sie folgendermaßen vor:
Um die Zieltabellenspalten über DJRA zu definieren, gehen Sie folgendermaßen vor:
Klicken Sie den Radioknopf Selected columns im Fenster "Add a Member to Subscription Sets" an. Wählen Sie anschließend die Spalten aus, die in die Zieltabelle repliziert werden sollen.
Um die Zieltabellenzeilen über die DB2-Steuerzentrale zu definieren, gehen Sie folgendermaßen vor:
Um anzugeben, welche Zeilen in die Zieltabelle kopiert werden, geben Sie ein SQL-Prädikat im Feld WHERE ein. Das Prädikat kann Standardkennungen und begrenzte Bezeichner enthalten. Näheres zu WHERE-Klauseln können Sie in der Veröffentlichung DB2 SQL Reference nachlesen.
Einschränkungen beim Definieren von Zeilenprädikaten:
Das Apply-Programm gibt Fehlernachrichten aus, wenn Sie die Test-WHERE-Klausel in dieser Situation nicht angeben.
Die folgenden Beispiele zeigen WHERE-Klauseln, die Sie zum Filtern von Zeilen der Zieltabelle verwenden können. Die Beispiele sind allgemein gehalten und können als Vorlage für eigene Klauseln verwendet werden.
Um nur die Zeilen zu kopieren, die einen bestimmten Wert (wie z. B. MGR für Angestellte, die Manager sind) enthalten, verwenden Sie z. B. eine WHERE-Klausel mit folgendem Format:
EMPLOYEE = 'MGR'
Um nur die Zeilen innerhalb eines Wertebereichs (wie z. B. die Personalnummern zwischen 5000 und 7000) in die Zieltabelle zu kopieren, verwenden Sie z. B. eine WHERE-Klausel mit folgendem Format:
EMPID BETWEEN 5000 AND 7000
Um die Spaltenberechnung zu unterstützen, verwenden Sie eine WHERE-Klausel wie z. B.:
1=1
Um die Zieltabellenzeilen über DJRA zu definieren, gehen Sie folgendermaßen vor:
Fügen Sie eine WHERE-Klausel im Feld Where Clause im Fenster "Add a Member to Subscription Sets" hinzu.
Bei DB2 DataPropagator können Sie eine zuvor definierte DB2-Tabelle als Zieltabelle in einer Subskriptionsgruppe verwenden. D. h., Sie können einen Subskriptionsgruppeneintrag als Zieltabelle definieren, die unabhängig von der DB2-Steuerzentrale oder von DJRA definiert wurde. Diese Art von Zieltabelle wird als benutzerdefinierte Zieltabelle bezeichnet.
Einschränkungen:
Um eine Subskription mit einer benutzerdefinierten Zieltabelle zu definieren, gehen Sie folgendermaßen vor:
Gehen Sie bei Anzeige des Fensters "Replikationssubskription" der DB2-Steuerzentrale folgendermaßen vor:
Informationen zur Wahl einer anderen Tabellenart finden Sie im Abschnitt Auswählen einer Zieltabellenart. Wenn Sie die Spalten der Zieltabelle ändern möchten, so dass sie der benutzerdefinierten Zieltabelle entsprechen, oder wenn Sie eine Unterauswahl von Zeilen bilden oder einen Berechnungsausdruck verwenden möchten, lesen Sie hierzu den Abschnitt Definieren der Zieltabellenstruktur: Spalten und Zeilen.
DJRA toleriert bereits vorhandene Zieltabellen und prüft, ob die Spalten in der Zieltabelle mit den Spalten übereinstimmen, die für den Subskriptionsgruppeneintrag definiert wurden.
DB2 DataPropagator nimmt keine Prüfung auf Inkonsistenzen zwischen der Subskriptionsdefinition und einer benutzerdefinierten Zieltabelle vor. Führen Sie die folgenden Schritte aus:
Sie können SQL-Anweisungen oder gespeicherte Prozeduren definieren, die ausgeführt werden, bevor oder nachdem das Apply-Programm die Daten aus der Quellentabelle in die Zieltabelle kopiert. Beispielsweise können Sie die Apply-Prüfprotokolltabelle bereinigen, um ältere Einträge zu entfernen.
Um SQL-Anweisungen oder gespeicherte Prozeduren für die Subskriptionsgruppe über die DB2-Steuerzentrale anzugeben, gehen Sie folgendermaßen vor:
Mit dem SQL-Fenster können Sie SQL-Anweisungen oder gespeicherte Prozeduren hinzufügen oder entfernen, die auf dem Ziel- oder Quellen-Server entweder vor oder nach der Verarbeitung der Replikationssubskription ausgeführt werden. Die Anweisungen werden in der Reihenfolge verarbeitet, in der sie in der Liste stehen.
Geben Sie gültige 5-Byte-SQLSTATE-Werte im Feld SQLSTATE ein, und klicken Sie Hinzufügen. Der Wert wird dann unter Zulässige SQLSTATE-Werte hinzugefügt. Sie können bis zu 10 Werte hinzufügen.
Um SQL-Anweisungen oder gespeicherte Prozeduren für die Subskription über DJRA anzugeben, gehen Sie folgendermaßen vor:
Wählen Sie eine Anweisungsnummer aus dem Umlaufauswahlfeld Statement number aus, und geben Sie gültige 5-Byte-SQLSTATE-Werte in das Feld Acceptable SQLSTATE values ein.
Es ist auch möglich, die Replikationsfunktion in System/390-Umgebungen mit gemeinsamer Datenbenutzung zu implementieren. In einer solchen Umgebung können Sie für jede Gruppe, die Quellendaten gemeinsam benutzt, ein Capture-Programm ausführen, sowie ein oder mehrere Apply-Programme für jede Gruppe, die Zieldaten gemeinsam benutzt.
Das Capture-Programm kann die Protokolle von Umgebungen mit gemeinsamer Datenbenutzung (Data-Sharing Logs) bei allen unterstützten Versionen von DB2 für OS/390 lesen. Dadurch ist es möglich, verschiedene Versionen von DB2 in einer Umgebung mit gemeinsamer Datenbenutzung auszuführen (z. B. bei der Migration auf eine neue Version) und die Erfassung transaktionskonsistenter Daten von einem Capture-Programm vornehmen zu lassen. Die Verwendung verschiedener Versionen wird aber nicht für einen längerfristigen Einsatz empfohlen (weder für die Replikation noch für DB2). Weitere Informationen zu Umgebungen mit gemeinsamer Datenbenutzung und verschiedenen Versionen von DB2 enthält die Veröffentlichung DB2 for OS/390 Administration Guide.
Um anzugeben, wie viele (in einer bestimmten Anzahl von Minuten gesammelte) Änderungsdaten in einem Subskriptionszyklus von DB2 DataPropagator repliziert werden können, verwenden Sie die Seite "Datenblockung" im Notizbuch "Ablaufsteuerung für Subskription" der DB2-Steuerzentrale, oder legen Sie den Blockungsfaktor über das Feld Blocking Factor im DJRA-Fenster "Create Empty Subscription Sets" fest. Die von Ihnen angegebene Zeitdauer (Anzahl Minuten) entscheidet über die Größe des Datenblocks. Weitere Informationen zum Ermitteln dieses Werts finden Sie im Abschnitt Datenblockung bei hohem Änderungsaufkommen.
DB2 DataPropagator speichert diesen Wert in der Spalte MAX_SYNCH_MINUTES der Tabelle für Subskriptionsgruppen. Um diesen Wert zu ändern, führen Sie die folgende SQL-Anweisung aus:
UPDATE ASN.IBMSNAP_SUBS_SET SET MAX_SYNCH_MINUTES=neuer-wert WHERE APPLY_QUAL=apply-qual AND SET_NAME=name AND WHOS_ON_FIRST=wert
Dabei ist neuer-wert der Wert des neuen Blockungsfaktor, apply-qual das aktuelle Apply-Qualifikationsmerkmal, name der Name der aktuellen Subskriptionsgruppe und wert entweder F oder S.
Beim Einrichten Ihrer Replikationsumgebung müssen Sie auch folgende Fragen klären: Wie "aktuell" sollen die Zieltabellen jeweils sein? Wie groß darf ein Rückstand maximal werden, bevor der Betrieb von Anwendungsprogrammen, die die Daten verwenden, beeinträchtigt wird. Anhand dieser Fragen können Sie Ihre Anforderungen an die Aktualität Ihrer Daten definieren. Sie können steuern, wie häufig das Apply-Programm Subskriptionen verarbeitet, und damit festlegen, wie aktuell Ihre Daten gehalten werden. Sie können entweder ein Intervall (relative Ablaufsteuerung) für das Apply-Programm festlegen oder ein Ereignis als Auslöser definieren, das vom Apply-Programm verwendet wird, um die Verarbeitung einer Subskriptionsgruppe zu starten.
Die Ablaufsteuerung für die Subskription wird entweder über das Notizbuch "Ablaufsteuerung für Subskription" der DB2-Steuerzentrale oder über das Feld Subscription Set Timing im DJRA-Fenster "Create Empty Subscription Sets" definiert. Sie können sich entweder für eine zeit- oder ereignisbasierte Ablaufsteuerung (oder eine Kombination aus beiden) entscheiden. Beispielsweise können Sie als Intervall einen Tag definieren und zusätzlich ein Ereignis angeben, das den Subskriptionszyklus auslöst. Bei der beliebigen Tabellenreplikation können Sie zudem zwischen verschiedenen Ablaufsteuerungsoptionen wählen, je nach dem, ob von der Quelle zum Replikat oder vom Replikat zur Quelle repliziert wird.
Empfehlung: Geben Sie beim Übergang von der Testumgebung zur Produktionsumgebung einen Ablaufsteuerungswert im mittleren Bereich an (z. B. 2 Stunden), und nehmen Sie ausgehend von diesem Basiswert eine Feinabstimmung vor (indem Sie das Intervall je nach Bedarf verlängern oder verkürzen).
Das einfachste Verfahren zur Ablaufsteuerung für Subskriptionen ist die Intervallsteuerung. Dabei geben Sie eine bestimmte Uhrzeit, ein Datum und ein Intervall an. Für das Intervall kann eine spezifische Angabe (von einer Minute bis zu einem Jahr) erfolgen oder "Fortlaufend" angegeben werden, wobei die Intervalle nur als ungefähre Angaben zu werten sind. Das Apply-Programm beginnt so bald wie möglich mit der Verarbeitung der Subskriptionsgruppe; dies hängt jedoch von der momentanen Auslastung und Verfügbarkeit der Ressourcen ab. Wenn Sie sich für die fortlaufende Ablaufsteuerung entscheiden, repliziert das Apply-Programm die Daten so häufig wie möglich.
Die Auswahl eines bestimmten Zeitintervalls garantiert nicht, dass die Replikation immer genau nach Ablauf dieses Intervalls erfolgt. Bevor Sie ein Intervall angeben, müssen Sie bestimmen, ob es möglich ist, alle Tabellen in der Subskriptionsgruppe innerhalb dieses Intervalls zu aktualisieren: Ermitteln Sie hierfür, welche Datenmenge das Apply-Programm voraussichtlich in jedem Intervall zum Aktualisieren auswählt und wie lange es dauert, diese Daten zu kopieren.
Das Festlegen und Ändern des Intervalls ist über die DB2-Steuerzentrale, über DJRA oder durch Ausführen von SQL-Anweisungen für die Tabelle für Subskriptionsgruppen möglich.
Um Daten unter Verwendung der Ereignissteuerung zu replizieren, geben Sie einen Ereignisnamen an, wenn Sie die Subskriptionsgruppe über die DB2-Steuerzentrale oder über DJRA definieren. Außerdem müssen Sie in der Tabelle für Subskriptionsereignisse eine Zeitmarke für den Ereignisnamen einfügen (über ein Anwendungsprogramm oder über die DB2-Steuerzentrale). Wenn das Apply-Programm dann während der Verarbeitung auf das Ereignis trifft, wird die Replikation (entweder durch Änderungserfassung oder vollständige Aktualisierung) gestartet.
Die Tabelle für Subskriptionsereignisse enthält drei Spalten (vgl. Tabelle 6).
Tabelle 6. Tabelle für Subskriptionsereignisse
EVENT_NAME | EVENT_TIME | END_OF_PERIOD |
---|---|---|
END_OF_DAY | 2000-05-01-17.00.00.000000 | 2000-05-01-15.00.00.000000 |
EVENT_NAME ist der Name des Ereignisses, das Sie beim Definieren der Subskriptionsgruppe angeben. EVENT_TIME ist die Zeitmarke für den Zeitpunkt, zu dem das Apply-Programm mit der Verarbeitung der Subskriptionsgruppe beginnt. END_OF_PERIOD ist eine wahlfreie Zeitangabe, die angibt, dass danach ausgeführte Aktualisierungen auf einen späteren Zeitpunkt verschoben werden. Legen Sie EVENT_TIME über den Taktgeber des Steuerungs-Servers fest, END_OF_PERIOD hingegen über den Taktgeber des Quellen-Servers. Diese Unterscheidung ist wichtig, wenn sich die beiden Server in verschiedenen Zeitzonen befinden.
In Tabelle 6 bezeichnet der Zeitmarkenwert (2000-05-01-17.00.00.000000) für das Ereignis END_OF_DAY den Zeitpunkt, an dem das Apply-Programm mit der Verarbeitung der Replikationssubskription beginnen soll. Der Zeitmarkenwert END_OF_PERIOD (2000-05-01-15.00.00.000000) gibt den Zeitpunkt an, nach dem Aktualisierungen nicht mehr an diesem Tag repliziert werden, sondern erst während des Verarbeitungszyklus am darauf folgenden Tag. Das heißt, das Ereignis bewirkt, dass alle anstehenden Aktualisierungen, die vor 15.00 Uhr vorgenommen wurden, repliziert werden, alle nachfolgenden Aktualisierungen werden verzögert.
Die verwendeten Anwendungsprogramme müssen Ereignisse an die Tabelle für Subskriptionsereignisse übergeben, um eine Verknüpfung zwischen Anwendungsprogrammen und der Subskriptionsaktivität herzustellen. Wenn Sie mit CURRENT TIMESTAMP mit der Vorgabe "plus eine Minute" für EVENT_TIME einen Eintrag übergeben, wird das in EVENT_NAME angegebene Ereignis ausgelöst. Jede Subskriptionsgruppe, die mit diesem Ereignis verknüpft ist, kann zur Ausführung in einer Minute ausgewählt werden. Sie können Ereignisse im Voraus, z. B. für die nächste Woche, das nächste Jahr oder für jeden Samstag übergeben. Wenn das Apply-Programm aktiviert ist, wird es zu dem von Ihnen angegebenen Zeitpunkt (leichte Abweichung möglich) gestartet. Wenn das Apply-Programm zu dem von Ihnen angegebenen Zeitpunkt gestoppt wurde, durchsucht es nach einem Neustart die Tabelle für Subskriptionsereignisse und beginnt mit der Verarbeitung der Subskriptionsgruppe für das übergebene Ereignis.
Jedes Ereignis, das vor dem Zeitpunkt der letzten Verarbeitung der Subskriptionsgruppe durch das Apply-Programm liegt (gemäß des Werts in der Spalte LASTRUN der Steuertabelle für die Subskriptionsgruppe), wird als abgelaufenes Ereignis angesehen und ignoriert. Falls das Apply-Programm aktiv ist, sollten Sie also nur Ereignisse übergeben, die zumindest in der nahen Zukunft liegen. Auf diese Weise vermeiden Sie das Übergeben abgelaufener Ereignisse.
Sie können die Ablaufsteuerung für Subskriptionsgruppen ändern, während das Capture-Programm und das Apply-Programm aktiv sind, indem Sie Werte in den Tabellen für Subskriptionsgruppen ändern. Um z. B. den Intervallwert zu ändern, führen Sie die folgende SQL-Anweisung aus:
UPDATE ASN.IBMSNAP_SUBS_SET SET INTERVAL_MINUTES=neuer-wert WHERE APPLY_QUAL=apply-qual AND SET_NAME=name AND WHOS_ON_FIRST=wert
Dabei ist neuer-wert der Wert des neuen Intervalls, apply-qual das aktuelle Apply-Qualifikationsmerkmal, name der Name der aktuellen Subskriptionsgruppe und wert entweder F oder S.
Wenn Sie eine Subskriptionsgruppe so ändern möchten, dass sie die Ereignissteuerung anstelle der Intervallsteuerung verwendet, führen Sie die folgenden SQL-Anweisungen aus:
UPDATE ASN.IBMSNAP_SUBS_SET SET REFRESH_TIMING='E', EVENT_NAME='END_OF_DAY' WHERE APPLY_QUAL=apply-qual AND SET_NAME=name INSERT INTO ASN.IBMSNAP_SUBS_EVENT (EVENT_NAME, EVENT_TIME) VALUES ('END_OF_DAY', 'zeitmarke')
Dabei ist apply-qual das aktuelle Apply-Qualifikationsmerkmal, name der Name der aktuellen Subskriptionsgruppe und zeitmarke die Angabe des Zeitpunkts, zu dem das Apply-Programm mit der Verarbeitung der Subskriptionsgruppe beginnen soll. Gibt es bereits ein Ereignis mit dem Namen END_OF_DAY, benötigen Sie die oben angegebene INSERT-Anweisung nicht; möglicherweise müssen Sie jedoch den Wert von EVENT_TIME ändern.
Näheres zu diesen Steuertabellen können Sie in den Abschnitten Tabelle für Subskriptionsgruppen und Tabelle für Subskriptionsereignisse nachlesen.
Beim Planen und Definieren einer Subskriptionsgruppe sind die folgenden Regeln und Einschränkungen zu beachten:
Wenn Sie eine eigene CCD-Tabelle verwalten, müssen Sie drei Spalten in der Registriersteuertabelle aktualisieren: CCD_OLD_SYNCHPOINT, SYNCHPOINT und SYNCHTIME:
Setzen Sie vor einer vollständigen Aktualisierung der CCD-Tabelle den Wert CCD_OLD_SYNCHPOINT auf NULL.
Erhöhen Sie den Wert für CCD_OLD_SYNCHPOINT nach einer vollständigen Aktualisierung der CCD-Tabelle, so dass er größer ist als der vorherige Wert von SYNCHPOINT. War für SYNCHPOINT vorher kein Wert angegeben (beim einleitenden Ladevorgang), setzen Sie CCD_OLD_SYNCHPOINT auf den Wert X'00000000000000000000'.
Setzen Sie SYNCHPOINT für die CCD-Tabelle immer dann auf MAX(IBMSNAP_COMMITSEQ), wenn Sie neue Änderungen für die CCD-Tabelle festschreiben. Der Wert für SYNCHTIME muss entsprechend festgelegt werden.
Das Verwaltungs-Tool DJRA führt Sie schrittweise durch den Prozess des Ladens einer Tabelle oder Datenbank im Offline-Betrieb. Bei dem folgenden Verfahren werden die zusätzlichen Steuerinformationen, die für das Laden externer CCD-Tabellen erforderlich sind, nicht verarbeitet. Diese Tabellen müssen deshalb manuell geladen werden.
Um mit DJRA einen Ladevorgang im Offline-Betrieb durchzuführen, gehen Sie folgendermaßen vor:
Wenn Sie Tabellen, Replikationsquellen oder Subskriptionsgruppen auf einem System (z. B. auf einem Testsystem) definieren und Sie diese Replikationsumgebung auf ein anderes System kopieren müssen (z. B. ein Produktionssystem), können Sie hierzu die Übertragungsfunktionen (Promote Functions) von DJRA verwenden. Mit diesen Funktionen 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. Tabelle 7 zeigt die drei Übertragungsfunktionen.
Verwenden Sie beispielsweise die Übertragungsfunktionen zum Definieren von
Subskriptionsgruppen für ferne DB2 Personal Edition-Zieldatenbanken.
Nachdem Sie ein Modell des Zielsystems in Ihrer Testumgebung definiert haben,
können Sie Subskriptionsgruppenprozeduren für Ihre DB2 Personal
Edition-Systeme erstellen (und unter anderem das zu verwendende
Apply-Qualifikationsmerkmal ändern), die über keinen anderen zentralen
Steuerpunkt unterstützt werden.
Tabelle 7. Übertragungsfunktionen (Promote Functions) von DJRA
Übertragungsfunktion | Beschreibung |
---|---|
Promote Registration | Mit dieser Funktion werden Quellentabellen und -sichten von einem Quellen-Server übertragen. |
Promote Table | Mit dieser Funktion werden Tabellen, Tabellenbereiche und Indizes
übertragen. Integritätsbedingungen, die für Tabellen definiert sind,
werden nicht übertragen.
Diese Funktion wird vollständig für DB2 Universal Database ab Version 5 unterstützt, bei der Server-Version können Sie jedoch nur Tabellen, nicht aber Tabellenbereiche übertragen. |
Promote Subscription | Mit dieser Funktion werden Subskriptionen übertragen:
Subskriptionsgruppen, Subskriptionsgruppeneinträge, Subskriptionsspalten,
Subskriptionsbereinigungsinformationen und Subskriptionsanweisungen.
Die Funktion ermöglicht Ihnen das Erstellen einer neuen Subskriptionsgruppe
auf der Grundlage einer bereits vorhandenen.
Über das DJRA-Fenster "Promote Subscriptions" können Sie Ihre Subskriptionen (vor dem Übertragen) ändern, indem Sie neue Werte in den folgenden Feldern eingeben: Apply Qualifier (Apply-Qualifikationsmerkmal), Set Name (Gruppenname), Source Server (Quellen-Server), Source Alias (Aliasname des Quellen-Servers), Target Server (Ziel-Server), Target Alias (Aliasname des Ziel-Servers), Control Server (Steuerungs-Server) und Control Alias (Aliasname des Steuerungs-Servers). |
Dieser Abschnitt enthält allgemeine Informationen zum Einrichten des Capture-Programms. Spezifische Informationen für Ihre Betriebssystemumgebung finden Sie im entsprechenden Kapitel in Teil 3, Betrieb.
Um die Leistung des Capture-Programms zu steuern, können Sie die folgenden Anpassungsparameter in der Tabelle mit Anpassungsparametern angeben:
Auf einem System IBM AS/400 können Sie die Tabellengröße kleiner halten, indem Sie die Tabellen mit dem Befehl RGZPFM reorganisieren.
Empfehlung: Geben Sie einen hohen Wert für die maximale Verzögerung an, um sicherzustellen, dass das Capture-Programm nicht unnötigerweise einen Programmabschluss ausführt.
Wenn die Datenbank nicht über eine Archivprotokolldatei verfügt oder eine solche nicht unterstützt und das Capture-Programm einen Programmabschluss durchführt, sollten Sie einen Kaltstart des Capture-Programms ausführen.
Wenn das Apply-Programm nicht gleichzeitig mit dem Capture-Programm ausgeführt wird, können Sie für das Festschreibungsintervall keinen höheren Wert als für das DB2-Zeitlimitintervall definieren.
Auf Systemen AS/400 hat dieser Wert eine andere Bedeutung. Hier gibt er die Dauer (Anzahl Sekunden) zwischen dem Zeitpunkt an, zu dem ein Anwendungsprogramm eine Quellentabelle aktualisiert, und dem Zeitpunkt, zu dem die entsprechende Aktualisierung in der CD-Tabelle auf die Platte geschrieben wird. Das Festschreibungsintervall reicht von 30 bis 600 Sekunden. Der Standardwert beträgt 180. Wird der Wert zu klein gewählt, kann sich dies negativ auf die gesamte Systemleistung auswirken.
Auf einem System IBM AS/400 können Sie diesen Wert durch Angabe eines Unterparameterwerts für die Wartezeit im Befehl STRDPRCAP (Schlüsselwort CLNUPITV) überschreiben. Bei Angabe von *NO für den Unterparameter (für das Starten des Bereinigungsvorgangs) des Schlüsselworts CLNUPITV wird der Wert für das Bereinigungsintervall ignoriert.
Wenn Sie auf einem System IBM AS/400 arbeiten und das Capture-Programm täglich starten, können Sie die Bereinigung durch Angabe von *NO verzögern (z. B. auf das Wochenende verschieben). Während der Woche können Sie CLNUPITV (*DPRVSN *NO) im Befehl STDPRCAP angeben. Am Wochenende kann dann CLNUPITV (*DPRVSN *IMMED) verwendet werden. Dies ist der Standardwert.
Wichtig: Wenn Sie die CD-Tabelle manuell bereinigen, löschen Sie nicht die Zeile mit dem aktuellsten Datum. Die Tabelle muss immer mindestens eine Zeile enthalten.
Um die Anpassungsparameter anzugeben, führen Sie eine der folgenden Funktionen aus:
UPDATE TABLE ASN.IBMSNAP_CCPPARMS SET RETENTION_LIMIT=anzahl_minuten, LAG_LIMIT=anzahl_minuten, COMMIT_INTERVAL=anzahl_sekunden, PRUNE_INTERVAL=anzahl_sekunden
Wenn Sie die Werte ändern und die Anpassungsparameter aktualisieren müssen, während das Capture-Programm aktiv ist, geben Sie den Befehl reinit nach dem Ändern der Tabellenwerte ein. Wenn Sie auf einem System IBM AS/400 arbeiten, geben Sie den Befehl INZDPRCAP ein. Weitere Informationen zum Befehl INZDPRCAP finden Sie im Abschnitt Reinitialisieren von Capture für AS/400.
Weitere Informationen zur Struktur der Tabelle mit Anpassungsparametern finden Sie in Kapitel 14, Tabellenstrukturen.
Folgende Aktionen bewirken einen Abbruch des aktiven Capture-Programms. Stoppen Sie deshalb das Capture-Programm, wenn Sie eine der folgenden Funktionen ausführen möchten:
Weitere Einschränkungen des Capture-Programms:
Dieser Abschnitt enthält allgemeine Informationen zum Einrichten des Apply-Programms. Spezifische Informationen für Ihre Betriebssystemumgebung finden Sie im entsprechenden Kapitel in Teil 3, Betrieb.
Das Apply-Programm kann die Exit-Routine ASNLOAD immer dann aufrufen, wenn es eine Zieltabelle vollständig aktualisiert. Diese Routine wird vom Apply-Programm aufgerufen, wenn Sie den Parameter LOADX angegeben haben.
Sie können die Routine ASNLOAD in ihrer Standardkonfiguration verwenden oder Änderungen vornehmen. In ihrer Standardkonfiguration verwendet die Routine das DB2-Dienstprogramm EXPORT für den Export der Daten aus der Quellentabelle und das DB2-Dienstprogramm LOAD für die vollständige Aktualisierung der Zieltabelle. Sie können die Routine ASNLOAD ändern, so dass sie jedes gewünschte IBM Programm oder Fremdprogramm aufruft. Informationen zum Ändern dieser Exit-Routine finden Sie im Prologabschnitt des Beispielprogramms (ASNLOAD.SMP) im Verzeichnis \sqllib\samples\repl.
Sie müssen die Routine ASNLOAD zur vollständigen Aktualisierung von Tabellen mit referenziellen Integritätsbedingungen verwenden (um die referenzielle Integritätsprüfung zu umgehen).
Wenn Ihre Quellen-Server durch ein Kennwort geschützt sind, müssen Sie die Routine ASNLOAD so ändern, dass sie die Kennwortdatei bereitstellt. Wenn das Kennwort aber von DB2 Universal Database Satellite Edition verwaltet wird, braucht die Routine ASNLOAD keine Kennwortdatei, und Sie können die von IBM gelieferte Routine verwenden.
Wenn Ihre Quellentabellen DATALINK-Spalten enthalten, ruft das Apply-Programm nicht die Exit-Routine ASNDLCOPY auf. Wenn Sie möchten, dass externe Dateien (auf die durch die DATALINK-Werte verwiesen wird) während einer vollständigen Aktualisierung kopiert werden, müssen Sie die Routine ASNLOAD so ändern, dass die Routine ASNDLCOPY für diese Spalten aufgerufen wird.
Weitere Informationen zur Verwendung der Routine ASNLOAD in einer AS/400-Umgebung können Sie im Abschnitt Aktualisieren von Zieltabellen mit der Exit-Routine ASNLOAD bei AS/400 nachlesen.
Wenn Sie die Routine ASNLOAD ausführen, werden die folgenden Dateien erstellt:
Diese Datei enthält die aus der Quelle exportierten Daten.
Diese Datei enthält Fehlernachrichten, Warnungen und Informationsnachrichten, die von den EXPORT-APIs ausgegeben werden.
Diese Datei enthält Fehlernachrichten, Warnungen und Informationsnachrichten, die von den LOAD-APIs ausgegeben werden.
Wenn Sie die Routine ASNLOAD ausführen, werden die folgenden Dateien erstellt:
Diese Datei enthält die aus der Quelle exportierten Daten.
Diese Datei enthält Fehlernachrichten, Warnungen und Informationsnachrichten, die von den EXPORT-APIs ausgegeben werden.
Diese Datei enthält Fehlernachrichten, Warnungen und Informationsnachrichten, die von den LOAD-APIs ausgegeben werden.
Wenn ein Fehler auftritt, während die Routine ASNLOAD vom Apply-Programm aufgerufen wird, oder wenn die Routine einen Rückkehrcode ungleich Null zurückgibt, gibt das Apply-Programm eine Nachricht aus, stoppt die Verarbeitung der aktuellen Subskriptionsgruppe und setzt die Verarbeitung mit der nächsten Subskriptionsgruppe fort.
Sie können die Routine ASNLOAD nur zum Aktualisieren von Tabellen mit Zeitangabe und von Benutzerkopietabellen verwenden. Für Zieltabellen bestehen die folgenden Einschränkungen bei der Routine ASNLOAD:
Das Apply-Programm kann die Exit-Routine ASNDONE nach Beenden der Subskriptionsverarbeitung wahlfrei aufrufen, unabhängig davon, ob die Verarbeitung erfolgreich war oder nicht. Die Routine kann bei Bedarf geändert werden. Beispielsweise kann die Routine in der UOW-Tabelle nach zurückgewiesenen Transaktionen suchen und weitere Aktionen einleiten, wie z. B. die Ausgabe einer Nachricht oder das Generieren eines Alerts. Des Weiteren kann die Exit-Routine zum Inaktivieren einer fehlgeschlagenen Subskriptionsgruppe (Status = -1) verwendet werden, um Wiederholungsversuche des Apply-Programms zu verhindern, bis der Fehler behoben ist.
Informationen zum Ändern dieser Exit-Routine finden Sie im Prologabschnitt
des Beispielprogramms (ASNDONE.SMP) im Verzeichnis
\sqllib\samples\repl. Für die AS/400-Umgebung gibt die folgende Tabelle
an, wo sich der Quellencode für diese Routine befindet:
Compiler-Sprache | Bibliothek | Quellendatei | Teildatei |
---|---|---|---|
C | QDPR | QCSRC | ASNDONE |
COBOL | QDPR | QCBLLESRC | ASNDONE |
RPG | QDPR | QRPGLESRC | ASNDONE |
Weitere Informationen zur Verwendung der Routine ASNDONE in einer AS/400-Umgebung können Sie im Abschnitt Aktualisieren von Zieltabellen mit der Exit-Routine ASNLOAD bei AS/400 nachlesen.
Um die Exit-Routine ASNDONE zu verwenden, gehen sie folgendermaßen vor:
Folgende Parameter übergibt das Apply-Programm an die Exit-Routine ASNDONE:
Wenn eine Subskriptionsgruppe DATALINK-Spalten enthält, ruft das Apply-Programm die Exit-Routine ASNDLCOPY während der Verarbeitung auf, damit ein Subskriptionsgruppeneintrag die externe Datei kopiert. Sie können diese Routine bei Bedarf modifizieren (beispielsweise, wenn Sie das Dateiübertragungsprotokoll ändern möchten).
Einschränkungen: Das Apply-Programm ruft die Routine ASNDLCOPY nicht auf, wenn die Zieltabelle eine CCD-Tabelle ist. Auch wenn Sie möchten, dass externe Dateien (auf die durch DATALINK-Werte verwiesen wird) während einer vollständige Aktualisierung kopiert werden, müssen Sie die Routine ASNLOAD so ändern, dass die Routine ASNDLCOPY für diese Spalten aufgerufen wird.
Informationen zum Einrichten und Ändern dieser Exit-Routine finden Sie im Prologabschnitt des Beispielprogramms (ASNDLCOPY.SMP) im Verzeichnis \sqllib\samples\repl. Für AS/400 finden Sie das Beispielprogramm in Bibliothek QDPR, Quellendatei QCSRC, Member ASNDLCOPY.
Um die Exit-Routine ASNDLCOPY zu verwenden, gehen Sie folgendermaßen vor:
Die Routine ASNDLCOPY gibt normalerweise nach ihrer Beendigung einen Rückkehrcode an das Apply-Programm zurück. Dabei weist ein Rückkehrcode ungleich Null das Apply-Programm darauf hin, dass die Replikation für eine oder mehrere Dateien fehlgeschlagen ist. In diesem Fall gibt das Apply-Programm eine Nachricht aus, stoppt die Verarbeitung der aktuellen Subskriptionsgruppe und setzt die Verarbeitung mit der nächsten Subskriptionsgruppe fort. Der Rückkehrcode Null gibt an, dass die Replikation erfolgreich durchgeführt wurde.
Da das Apply-Programm nach Beendigung der Verarbeitung einer Subskriptionsgruppe in beiden Fällen die Exit-Routine ASNDONE aufruft, können Sie mit dieser Routine Bereinigungsmaßnahmen durchführen, die erforderlich sind, falls die Routine ASNDLCOPY externe Dateien nicht repliziert.
Die Routine ASNDLCOPY generiert zwei Dateien, eine Protokolldatei und eine Trace-Datei (wenn die Trace-Funktion aktiviert ist). Die Protokolldatei wird wie folgt benannt:
ASNDLapply-qualgr-namequell-serverziel-server.LOG
Dabei ist apply-qual das Apply-Qualifikationsmerkmal, gr-name der Name der Subskriptionsgruppe, quell-server der Name des Quellen-Servers und ziel-server der Name des Ziel-Servers. Die Protokolldatei enthält alle von der ASNDLCOPY-Routine generierten Nachrichten. Die Trace-Datei wird wie folgt benannt:
ASNDLapply-qualgr-namequell-serverziel-server.TRC
Die Trace-Datei enthält alle von der Routine ASNDLCOPY generierten Trace-Informationen.
Folgende Parameter übergibt das Apply-Programm an die Exit-Routine ASNDLCOPY:
Die Eingabedatendatei enthält eine Liste von Verknüpfungsverweisen, die in der Quellentabelle erfasst wurden. Diese Datei hat folgendes Format:
länge quellenverknüpfungsverweis neuer-verknüpfungsverweis
Die Felder sind:
Verwenden Sie das Zeilenvorschubzeichen, um das Ende einer Eingabezeile anzugeben.
Beispiel für eine Eingabedatei:
35 HTTP://S1.CDE.COM/data/yy/file1.avi Y 35 HTTP://S2.CDE.COM/data/qq/file2.avi N
Die Ergebnisdatei enthält umgesetzte Verknüpfungsverweise, die für das Zielsystem gültig sind. Diese Datei hat folgendes Format:
länge zielverknüpfungsverweis
Dabei ist länge die Länge des Zielverknüpfungsverweises, und zielverknüpfungsverweis ist der Verweis auf die Zielverknüpfung im URL-Format. Kann eine Quellendatei nicht repliziert werden, setzt die Routine ASNDLCOPY in der Ergebnisdatei normalerweise länge auf Null und zielverknüpfungsverweis auf Leerzeichen, um sicherzustellen, dass keine Verknüpfung in der Zieltabelle erstellt wird.
Beispiel für eine Ergebnisdatei:
35 HTTP://T1.XYZ.COM/data/yy/file1.avi 35 HTTP://T2.XYZ.COM/data/zz/file2.avi
Die Trace-Option kann entweder yes oder no sein, abhängig davon, ob Sie Trace-Informationen wünschen.
Für die Routine ASNDLCOPY sind zwei Konfigurationsdateien erforderlich, ASNDLUSER und ASNDLSRVMAP. Die Datei ASNDLUSER enthält die Server-Adresse (URL-Format), die Eingabeanschlussnummer, die Ausgabeanschlussnummer, die Anmelde-ID und das Kennwort. Die erste Anschlussnummer gibt die Quellen-FTP-Adresse oder den Quellen-Dämonprozess zum Kopieren von Dateien an, mit der/dem die Routine ASNDLCOPY eine Verbindung herstellt, um Dateien abzurufen. Die zweite Anschlussnummer ist für die Ziel-FTP-Adresse oder den Ziel-Dämonprozess zum Kopieren von Dateien, um Dateien zu senden. Diese Anschlussnummern können identisch sein.
Beispiel für eine Datei ASNDLUSER:
S1.CDE.COM 21 21 benutzerA xxyyzz T1.XYZ.COM 21 24 benutzerB xkxkxk
Die Datei ASNDLSRVMAP enthält die Server-Zuordnungen für Verknüpfungsverweise und eventuell eine Verzeichnispfadangabe. Wird kein Verzeichnispfad angegeben oder der angegebene Pfad nicht gefunden, wird der gleiche Pfadname verwendet.
Beispiel für eine Datei ASNDLSRVMAP:
HTTP://S1.CDE.COM HTTP://T1.XYZ.COM HTTP://S2.CDE.COM HTTP://T2.XYZ.COM /data/qq /data/zz
Alle Felder für einen Eintrag müssen in derselben Zeile stehen.
Der Dämonprozess ASNDLCOPYD zum Kopieren von Dateien extrahiert Dateien für die Exit-Routine ASNDLCOPY. Er ähnelt einem Standard-FTP-Dämonprozess, bietet aber die folgenden Funktionen für die DATALINK-Replikation:
Empfehlung: Verwenden Sie den Dämonprozess ASNDLCOPYD zum Kopieren von Dateien, um eine DATALINK-Spalte zu replizieren, die mit dem Attribut "Read Permission DB" (Lesezugriff DB) definiert wurde. Im Gegensatz zum Standard-FTP-Prozess ist für den Dämonprozess ASNDLCOPYD kein Superuser-Zugriff erforderlich.
Sie können den Dämonprozess ASNDLCOPYD zum Kopieren von Dateien so konfigurieren, dass sich nur bestimmte Benutzer anmelden können. Jedem Benutzer können Sie Zugriff auf bestimmte Verzeichnisse einrichten. Informationen zum Einrichten und Ändern diese Programms finden Sie im Prologabschnitt des Beispielprogramms (ASNDLCOPYD.SMP) im Verzeichnis \sqllib\samples\repl. Für AS/400 finden Sie das Beispielprogramm in Bibliothek QDPR, Quellendatei QCSRC, Member ASNDLCOPYD. Zum Hinzufügen und Ändern von Benutzer-IDs verwenden Sie das Tool ASNDLCOPYD_CMD.
An den Dämonprozess zum Kopieren von Dateien übergeben Sie die folgenden Parameter:
Um den Dämonprozess ASNDLCOPYD zum Kopieren von Dateien zu verwenden, gehen Sie folgendermaßen vor:
Für die Ausführung des Dämonprozesses ASNDLCOPYD benötigen Sie die Root- bzw. Administratorberechtigung.
Der Dämonprozess ASNDLCOPYD zum Kopieren von Dateien erstellt eine Protokolldatei für alle vom Programm ASNDLCOPYD generierten Nachrichten. Diese Protokolldatei wird wie folgt benannt: ASNDLCOPYDJJJJMMTTHHMMSS.LOG, wobei JJJJMMTTHHMMSS den Zeitpunkt angibt, zu dem der Dämonprozess gestartet wurde.
Installieren Sie DB2 DataJoiner anhand der Schritte, die in der Veröffentlichung DB2 DataJoiner Planning, Installation, and Configuration Guide beschrieben sind. Das Apply-Programm wird bei der Installation von DataJoiner automatisch installiert. Nach der Installation von DataJoiner gehen Sie folgendermaßen vor:
Für AIX definieren Sie die Apply-Benutzer-ID als lokalen Client für DataJoiner.
Soll DJRA auf DataJoiner für AIX zugreifen, setzen Sie die Umgebungsvariable DB2CODEPAGE von Ihrer DJRA-Workstation aus. Der Wert, den Sie angeben, ist von Ihrem Landescode abhängig. Beim Landescode US ist beispielsweise folgendermaßen vorzugehen:
Sie müssen je eine DataJoiner-Datenbank für jeden Replikations-Quellen-Server eines anderen Herstellers erstellen. Mit einer DataJoiner-Datenbank können Sie jedoch viele Replikations-Ziel-Server anderer Hersteller unterstützen. Die von Ihnen erstellten DataJoiner-Datenbanken sind zusammen in einem DataJoiner-Exemplar enthalten. Sie müssen Server- und Benutzerzuordnungen für jede DataJoiner-Datenbank erstellen, die auf eine Quelle oder ein Ziel zugreifen soll.
Verwenden Sie für jede Quelle eines anderen Herstellers die Parameter COLLATE USING IDENTITY im Befehl CREATE DATABASE.
Bei Windows NT können das DataJoiner-Exemplar und der DB2-Sicherheitsservice automatisch gestartet werden:
Weitere Informationen dazu enthält die Veröffentlichung DB2 DataJoiner Planning, Installation, and Configuration Guide.