Db2 z/OS-Transaktionslogs für Oracle GoldenGate vorbereiten

Hier erfahren Sie, wie Sie das Transaktionslogging Db2 so konfigurieren, dass die Datenerfassung durch Oracle GoldenGate Extract unterstützt wird.

Oracle GoldenGate kann Db2-Transaktionsdaten aus den aktiven und archivierten Logs erfassen. Befolgen Sie diese Richtlinien, um die Logs so zu konfigurieren, dass Extract Daten erfassen kann.

Informationen zum Aktivieren der Änderungserfassung für Oracle GoldenGate für Db2 z/OS finden Sie unter TRANDATA für Nicht-Oracle-Datenbanken aktivieren

Zugriff auf Logdatensätze aktivieren

Aktivieren Sie Db2 Monitor Trace Class 1 ("TRACE(MONITOR) CLASS(1) "), damit Extract das aktive Log lesen kann. Db2 ermöglicht es Extract. Das Standardziel von OPX ist ausreichend, da Oracle GoldenGate kein Ziel verwendet.

So starten Sie das Trace manuell

Melden Sie sich als Db2-Benutzer mit der Berechtigung TRACE oder mindestens der Berechtigung SYSOPR bei Db2 an.
Geben Sie den folgenden Befehl aus:

start trace(monitor) class(1) scope(group)

So starten Sie das Trace automatisch, wenn Db2 gestartet wird

Führen Sie eine der folgenden Aktionen aus:

Setzen Sie MONITOR TRACE im Tracingbereich für die Installation von DSNTIPN auf "YES".
Legen Sie "DSN6SYSP MON=YES" im Installationsjob DSNTIJUZ fest, wie im Db2 UDB-Installationshandbuch beschrieben.

Hinweis: Die primäre Autorisierungs-ID oder eine der sekundären Autorisierungs-IDs des ODBC-Plan-Executors muss auch über die Berechtigung MONITOR2 verfügen.

Logs vergrößern und beibehalten

Weitere Daten werden protokolliert, wenn Tabellen mit DATA CAPTURE CHANGES definiert werden, als wenn sie mit DATA CAPTURE NONE definiert werden. Wenn einer der folgenden Punkte zutrifft, müssen Sie möglicherweise die Anzahl und Größe der aktiven und archivierten Logs erhöhen.

Ihre Anwendungen generieren große Mengen an Db2-Daten.
Ihre Anwendungen haben selten Commits.
Sie erwarten, dass der Export für lange Zeiträume gestoppt wird.
Ihr Netzwerk ist unzuverlässig oder langsam.

Verwenden Sie den Systemparameter DSN6LOGP MAXARCH im Installationsjob DSNTIJUZ, um die Logaufbewahrung zu steuern.

Behalten Sie genügend Logdaten bei, damit Extract nach dem Stoppen oder nach einem ungeplanten Ausfall erneut von den Checkpoints gestartet werden kann. Extract muss Zugriff auf das Log haben, das den Start der ältesten nicht festgeschriebenen Arbeitseinheit und danach alle Logs enthält.

Wenn Daten, die Extract während der Verarbeitung benötigt, weder in Online- noch in archivierten Logs aufbewahrt wurden, kann eine der folgenden Korrekturmaßnahmen erforderlich sein:

Ändern Sie den Extract so, dass er ab einem späteren Zeitpunkt erfasst wird, für den Logdaten verfügbar sind (und einen möglichen Datenverlust auf dem Ziel akzeptieren).
Synchronisieren Sie die Quell- und Zieltabellen erneut, und starten Sie dann die Oracle GoldenGate-Umgebung erneut. Hinweis: In der IBM-Dokumentation werden Empfehlungen zur Verbesserung der Performance von Loglesevorgängen gegeben. Insbesondere können Sie große Logausgabepuffer, große aktive Logs und Archive auf Platte erstellen.

Archive Logs auf Band verwenden

Oracle GoldenGate kann Db2-Archivlogs auf Band lesen, was die Performance beeinträchtigt. Beispiel: Db2 reserviert getapte Archive für eine einzelne Recovery-Aufgabe, sodass Extract kein Archivband lesen kann, das zur Wiederherstellung einer Tabelle verwendet wird, bis das Recovery abgeschlossen ist. Sie könnten DFHSM oder ein gleichwertiges Tool verwenden, um die Archivlogs nahtlos zwischen Online-DASD-Speicher und -Band zu verschieben. Extract muss jedoch warten, bis die Übertragung abgeschlossen ist. Verzögerungen bei der Extraktionsverarbeitung erhöhen die Latenz zwischen Quell- und Zieldaten.

Wenn Oracle GoldenGate Extract auf Band (physisches Band) oder virtuelles Band (virtuelles Band) lesen kann oder wird, wird dringend empfohlen, die folgende ZPARMs zu berücksichtigen:

ZUTEILUNG

Der Subsystemparameter DEALLCT bestimmt, wie lange eine Bandeinheit beim Lesen des Archivs ungenutzt bleiben darf, bevor ihre Zuweisung aufgehoben wird.

Update: Option 43 im Bereich DSNTIPB

DSNZPxxx: DSN6LOGP DEALLCT

Oracle empfiehlt, DEALLCT auf 0, 1 (Verzögerung der 1-Sekunden-Deallokation) zu setzen. Standardmäßig wird die Zuteilung sofort aufgehoben. Dadurch wird verhindert, dass Db2 ein Band sofort zwischen Lesevorgängen aus Extract neu zuweist.

MAXRTU

Der Subsystemparameter MAXRTU gibt die maximale Anzahl dedizierter Bandeinheiten an, die den parallel gelesenen Band-Volumes von Archivprotokollen zugewiesen werden können.

Update: Option 43 im Bereich DSNTIPB

DSNZPxxx: DSN6LOGP MAXRTU

Der Standardwert beträgt 2 Bandeinheiten. Er sollte jedoch auf die Anzahl der erwarteten Prozesse eingestellt werden, die gleichzeitig von tape+1 gelesen werden können. Beispiel: Wenn 4 Extrakte und 2 andere Anwendungen aus Bändern gelesen werden können, muss MAXRTU mindestens 7 sein (4 + 2 + 1).

Um die beste Performance und geringste Verzögerungen beim Lesen vom Band zu erzielen, sollte Oracle GoldenGate Extract Folgendes verwenden:

TRANLOGOPTIONS BUFSIZE 33554432

Dies ist ein Hinweis darauf, dass Extract bis zu 32 MB gleichzeitig aus dem Transaktionslog liest und nicht standardmäßig 1 MB pro Lesevorgang. Diese Einstellung erhöht nicht die Speicherzuweisungen, die Oracle GoldenGate auf z/OS verwendet, weder ECSA (64 Byte) noch 64-Bit Shared Memory (1 MB). Die vorübergehenden Speicherzuweisungen von Db2 können erhöht werden, während der Extract die großen Puffer liest.

Außerdem kann in der Extract-Parameterdatei vor dem Parameter DBLOGIN Folgendes verwendet werden, um die TCP-Kommunikationspufferung des Db2-Treibers weiter zu optimieren. Beispiel:

SETENV(DB2SOSNDBUF='524288')
SETENV(DB2SORCVBUF='524288')

Dadurch wird der Db2-Treiber informiert, dass er 512 KB für die Sende- und Empfängerpuffer verwendet. Andere Werte können verwendet werden und können für jede Installation optimiert werden.

Kontrolllog-Flushs

Beim Lesen des Transaktionslogs verarbeitet Extract eine Transaktion erst, wenn der Commit-Datensatz erfasst wird. Wenn sich der Commit-Datensatz auf einem Datenblock befindet, der nicht voll ist, kann er erst erfasst werden, wenn mehr Logaktivität generiert wird, um den Block abzuschließen. Die API, mit der Extract die Logs liest, ruft nur vollständige physische Datenblöcke ab.

Eine Verzögerung beim Empfangen von Blöcken, die Commits enthalten, kann zu einer Latenz zwischen den Quell- und Zieldaten führen. Wenn die Anwendungen nicht genügend Logdatensätze generieren, um einen Block zu füllen, generiert Extract Logdatensätze, indem die Anweisungen SAVEPOINT und COMMIT ausgegeben werden, bis der Block auf die eine oder andere Weise gefüllt und freigegeben wird.

In einer Datenfreigabegruppe führt jeder API-Aufruf dazu, dass Db2 die Datenblöcke aller aktiven Member löscht, sodass Extract keine Löschvorgänge ausführen muss.

Um zu verhindern, dass Extract Flushes durchführt, verwenden Sie den Extract-Parameter TRANLOGOPTIONS mit der Option NOFLUSH.