TRANLOGOPTIONS

Gültig für

Extrahieren

Beschreibung

Mit dem Parameter TRANLOGOPTIONS können Sie steuern, wie Extract mit dem Transaktionslog oder mit der API interagiert, die Transaktionsdaten übergibt, je nach Datenbank- oder Capture-Modus. Sie können mehrere TRANLOGOPTIONS-Anweisungen in derselben Parameterdatei verwenden oder mehrere Optionen innerhalb derselben TRANLOGOPTIONS-Anweisung angeben, wenn dies bei diesen Optionen möglich ist.

Verwenden Sie eine bestimmte Option TRANLOGOPTIONS nur für die Datenbank oder Datenbanken, für die sie bestimmt ist.

Standard

Keine

Syntax

TRANLOGOPTIONS {[ALLOW_BINLOG_ROW_METADATA_MINIMAL]
[ALLOWTABLECOMPRESSION][ALTLOGDEST <path> | REMOTE]
[ALWAYSONREADONLYROUTING]
[ASMUSERALIAS <alias> [DOMAIN <domain>]]
[ASYNCTRANSPROCESSING <buffer_size>]
[BUFSIZE <size>]
[CHECKPOINTRETENTIONTIME <days>][DB2APIRETRY <retry_count>]
[DB2ZV11COMPATIBILITYMODE]
[DICTIONARY_CACHE_SIZE <value>]
[DLFAILOVER_TIMEOUT <seconds>]
[DISABLESOFTEOFDELAY]
[EXCLUDEFILTERTABLE <table>]
[EXCLUDETAG {<tag> | + | NULL}]
[EXCLUDETRANS <transaction>]
[EXCLUDEUSER <user>]
[EXCLUDEUSERID <Oracle_uid>][FAILOVERTARGETDESTID <n>][FETCHPARTIALJSON]
[FETCHPARTIALLOB][FETCHPARTIALXML]
[FORCEFETCHLOB]
[GETCTASDML | NOGETCTASDML][HANDLEDLFAILOVER [STANDBY_WARNING | STANDBY_ABEND]]
[IFILOCKSECONDS]
[IGNOREDATACAPTURECHANGES | NOIGNOREDATACAPTURECHANGES]
[INCLUDEAUX (<AUX_specification>)]
[INCLUDEREGIONID | INCLUDEREGIONIDWITHOFFSET]
[INTEGRATEDPARAMS]
[INCLUDETAG <tag>]
[ENABLE_PROCEDURAL_REPLICATION Y]
[ENABLE_AUTO_CAPTURE | DISABLE_AUTO_CAPTURE]
[LOB_CHUNK_SIZE <size>]
[MAXAUTOCMTTRANSSIZE (<range>, <default>)]
[LOGREADTIMEOUT <value>]
[MININGUSERIDALIAS <alias> [DOMAIN <domain>]][MIXEDENDIAN [ON|OFF]]
[MANAGECDCCLEANUP | NOMANAGECDCCLEANUP ]
[MANAGESECONDARYTRUNCATIONPOINT | NOMANAGESECONDARYTRUNCATIONPOINT ]
[PERFORMANCEPROFILE HIGH|MEDIUM|LOW_RES|LOW_WORKLOAD][QUERYTIMEOUT <seconds>]
[QUERYRETRYCOUNT <seconds>]
[READQUEUESIZE <size>]
[READTIMEOUT <milliseconds>]
[REDO_TRANSPORT_LAG_THRESHOLD <seconds>]
[REDO_TRANSPORT_LAG_TIMEOUT <value>]
[REMOTESCHEMA <value>]
[REQUIRELONGDATACAPTURECHANGES | NOREQUIRELONGDATACAPTURECHANGES]
[SOURCE_OS_TIMEZONE <timezone>]
[SKIPUNKNOWNEVENT]  [STREAMINGOPTIONS (publication_names=<pub_name1>, <pub_name2>, <pub_name3>)
[SUPPRESSNOOOPUPDATES]
[TRACKSCHEMACHANGES | NOTRACKSCHEMACHANGES]
[TRANCOUNT <integer>]
[TSLOOKUPBEGINLRI | TSLOOKUPENDLRI]
[VALIDATEINLINESFLOB]
[USE_ROOT_CONTAINER_TIMEZONE]
[USENATIVEOBJSUPPORT | NOUSENATIVEOBJSUPPORT]
[VERSIONCHECK DYNAMIC | IMMEDIATE][WARNCREATEASSELECT]
}

[ALLOW_BINLOG_ROW_METADATA_MINIMAL]

Gültig für MySQL

Verwenden Sie die Datei ALLOW_BINLOG_ROW_METADATA_MINIMAL in der Extraktparameterdatei, um die MySQL Server-Variable BINLOG_ROW_METADATA weiterhin zu verwenden, die auf MINIMAL gesetzt ist.

Die MySQL Server-Variable BINLOG_ROW_METADATA unterstützt keine Features wie TRACKSCHEMACHANGES- und DDL-Replikation. Um diese Features zu verwenden, setzen Sie BINLOG_ROW_METADATA in der Serverkonfigurationsdatei MySQL auf Full. Wenn diese Features nicht erforderlich sind, verwenden Sie MINIMAL mit dem Parameter ALLOW_BINLOG_ROW_METADATA_MINIMAL.

ALWAYSONREADONLYROUTING

Gültig für SQL Server

Mit dem Parameter ALWAYSONREADONLYROUTING kann Extract für den SQL-Server seine schreibgeschützte Verarbeitung an ein verfügbares sekundäres Lese-Intent weiterleiten, wenn eine Verbindung zu einem Always On-Verfügbarkeitsgruppen-Listener besteht.

ALTLOGDEST <path | REMOTE>

Gültig für MySQL.

Gibt den Speicherort der MySQL-Logindexdatei an. Extract sucht in diesem Verzeichnis nach den Logdateien anstelle des Standardspeicherorts der Datenbank. ALTLOGDEST kann verwendet werden, wenn die Datenbankkonfiguration nicht den vollständigen Pfadnamen zu den Logs enthält oder wenn mehrere MySQL-Installationen auf dem Rechner vorhanden sind. Extract liest die Logindexdatei, um die Binärlogdatei zu finden, die gelesen werden muss. Wenn ALTLOGDEST verwendet wird, geht Extract davon aus, dass sich die Logs und der Index im selben Speicherort befinden.

Geben Sie den vollständigen Pfadnamen für das Verzeichnis an.

Setzen Sie den Pfad unter Windows in doppelte Anführungszeichen, wenn der Pfad Leerzeichen enthält, wie im folgenden Beispiel.

TRANLOGOPTIONS ALTLOGDEST "C:\Program Files\MySQL\MySQL Server
5.7\log\binlog.index"

Auf Linux-System:

TRANLOGOPTIONS ALTLOGDEST "/mnt/rdbms/mysql/data/logs/binlog.index"

Beim Erfassen für eine Remote-MySQL-Datenbank verwenden Sie die Option REMOTE anstelle des Indexdateipfads. Wenn ALTLOGDEST nicht angegeben wird, nimmt das System die Option REMOTE an.

Geben Sie im Remote Capture-Prozess Folgendes in der Extract-Parameterdatei an.

TRANLOGOPTIONS ALTLOGDEST REMOTE

Weitere Informationen zur Verwendung der Option REMOTE finden Sie unter Loggingebenen konfigurieren.

ASYNCTRANSPROCESSING <buffer_size>

Gültig für Extract im integrierten Capture-Modus für Oracle.

Steuert, ob der integrierte Capture-Prozess im asynchronen oder synchronen Verarbeitungsmodus ausgeführt wird, und steuert die Puffergröße, wenn Extract sich im asynchronen Modus befindet. Der Mindestwert ist 1, der Höchstwert ist 1024, der Standardwert ist 300.

ASYNCTRANSPROCESSING <buffer_size>

Im asynchronen Verarbeitungsmodus <transaction> gibt es zwei Kontrollthreads:

Der Transaktionspuffer ist der Puffer zwischen diesen beiden Threads und wird verwendet, um Arbeit von einem Thread auf den anderen zu übertragen. Die Standardgröße des Transaktionspuffers beträgt 300 festgeschriebene Transaktionen, wird jedoch vom Oracle GoldenGate-Memory Manager nach unten angepasst, wenn der Cachespeicher nahezu erschöpft ist.

NOASYNCTRANSPROCESSING

Deaktiviert die asynchrone Verarbeitung und führt dazu, dass Extract im synchronen Modus arbeitet. In diesem Modus führt ein Thread alle Capture-Vorgänge aus.

BUFSIZE <size>

Gültig für Db2 LUW und Db2 z/OS. Gültig für Db2 für i von Oracle GoldenGate 19c und höher. Gültig für Oracle AI-Datenbank von Oracle GoldenGate 21c und höher.

Kontrolliert die maximale Größe der Puffer, die zur Aufnahme der Daten aus dem Transaktionslog zugewiesen sind, die in Byte.

Hohe Werte erhöhen die Erfassungsgeschwindigkeit, führen aber dazu, dass Extract mehr Speicher verbraucht. Niedrige Werte reduzieren die Speicherauslastung, erhöhen jedoch das I/O, da Extract Daten speichern muss, die die Cachegröße auf Platte überschreiten.

Bei Oracle AI Database ist die Größe des Vorgangsdatensatzes DDL durch die interne Puffergröße des Oracle GoldenGate-Datensatzes begrenzt. Die Größe von DDL kann bis zur Größenbeschränkung von Oracle RDBMS betragen. Obwohl die Oracle-Datenbank 21c das Erstellen von DDL mit mehr als 10 MB zulässt, ist die maximale interne Puffergröße für die Datensatzerfassung auf 10 MB begrenzt.

Der <default>-Puffer <size> wird von der Quelle der Redo-Daten bestimmt. Im Folgenden werden die gültigen Bereiche und <default>-Größen in Byte aufgeführt:

Db2 LUW:

Db2 z/OS und Db2 für i:

CHECKPOINTRETENTIONTIME <days>

Gültig für Extract im integrierten Modus nur für Oracle.

Steuert die Anzahl der Tage, die Extract Checkpoints vor dem Löschen speichert. Teiltage können mit Dezimalwerten angegeben werden. Beispiel: 8.25 gibt 8 Tage und 6 Stunden an. Wenn der Checkpoint eines Extract im integrierten Capture-Modus gelöscht wird, werden die Data Dictionary-Informationen LogMiner für die archivierte Redo-Logdatei, die dem Checkpoint entspricht, gelöscht, und der Wert first_scn des Capture-Prozesses wird auf den SCN-Wert zurückgesetzt, der der ersten Änderung in der nächsten archivierten Redo-Logdatei entspricht. Der Standardwert ist sieben Tage und der Mindestwert ist 0,00001.

DB2APIRETRY <number> der Wiederholungsversuche

Wenn Extract einen Fehler von der Db2-Loglese-API db2ReadLog(), empfängt, wird der API-Aufruf bei bestimmten Fehlern wiederholt. Verwenden Sie DB2APIRETRY, um die Anzahl der Wiederholungen zu ändern. Die Standardanzahl der Wiederholungen ist auf 3 gesetzt. SQL-Code, für den die API erneut versucht wird, lautet SQLCODE -30108.

DB2ZV11COMPATIBILITYMODE

Gültig für Extract für Db2 z/OS.

Wenn Sie Oracle GoldenGate verwenden, um in einigen Kompatibilitätsmodi aus Db2 z/OS Version 11 zu extrahieren, bestimmt der Extract-Prozess möglicherweise nicht programmgesteuert die tatsächliche Datenbankversion, und es tritt ein OGG-00551- oder OGG-00804-Fehler auf. Verwenden Sie diese Option in der Extract-Parameterdatei, um die erforderliche Datenbankversion manuell festzulegen.

DICTIONARY_CACHE_SIZE <value>

Verwenden Sie diese Option, um die Dictionary-Cachegröße aus Extract zu optimieren. Der Standardwert ist 5000. Wenn PERFORMANCEPROFILE auf HIGH gesetzt ist, ist der Standardwert 10000.

DLFAILOVER_TIMEOUT <seconds>

Gültig für Extract im integrierten Modus für Oracle.

Stellt einen konfigurierbaren Timeout in Sekunden bereit, um den Post-Role-Übergang für die Standbydatenbank-Neuinstanziierung zuzulassen. Sie wird in Verbindung mit HANDLEDLFAILOVER verwendet, damit Integrated Extract unmittelbar nach einem Rollenübergang gestartet werden kann. Wenn die Standbydatenbank am Ende des Timeoutzeitraums noch nicht verfügbar ist, wird Extract beendet.

Der Standardwert beträgt 300 Sekunden. Sie können auch Zentisekunden oder Millisekunden verwenden.

DISABLESOFTEOFDELAY

Gültig für Extract nur im integrierten Modus für Oracle und Db2 LUW.

Verwenden Sie DISABLESOFTEOFDELAY in der Extract-Parameterdatei, um festzulegen, dass die Wartezeit wirksam wird, wenn der EOF-Status ohne zurückzugebende Datensätze gemeldet wird.

ENABLE_AUTO_CAPTURE DISABLE_AUTO_CAPTURE

Legen Sie diese Option fest, um den Modus auto_capture zu aktivieren, der LCRs von Tabellen bereitstellt, die für die automatische Erfassung aktiviert sind. Diese Option kann festgelegt werden, wenn die Oracle-Binärversion der Quelldatenbank 21c oder höher ist.

EXCLUDETAG {<tag> | + | NULL}]

Gültig für Extract. (Nur Oracle)

Mit EXCLUDETAG werden Änderungen ausgeschlossen, die zuvor von Replicat mit der Option DBOPTIONS SET TAG oder in der Oracle AI Database-Session mit der Prozedur DBMS_XSTREAM_ADM.SET_TAG getaggt wurden.

Verwenden Sie EXCLUDETAG tag>, um den Extract-Prozess anzuweisen, die einzelnen Datensätze zu ignorieren, die mit dem angegebenen Redo-Tag getaggt sind.

Verwenden Sie EXCLUDETAG NULL, um alle Vorgänge auszuschließen, die nicht getaggt sind. Das Gegenteil von EXCLUDETAG +.

Verwenden Sie EXCLUDETAG +, um den Extract-Prozess anzuweisen, die einzelnen Datensätze zu ignorieren, die mit einem Redo-Tag getaggt sind.

Beispiel

Im Folgenden finden Sie Beispiele für die Verwendung von Tagbezeichnern mit EXCLUDETAG.

So schließen Sie alle getaggten Änderungen aus:

TRANLOGOPTIONS EXCLUDETAG +

So schließen Sie bestimmte getaggte Änderungen aus:

TRANLOGOPTIONS EXCLUDETAG 00
TRANLOGOPTIONS EXCLUDETAG 0952

Richtlinien bei der Verwendung der Parameter EXCLUDETAG und INCLUDETAG

Beachten Sie bei der Verwendung der Parameter EXCLUDETAG und INCLUDETAG mit den Befehlen TRANLOGOPTIONS und DDLOPTIONS Folgendes:

EXCLUDETRANS <transaction>

Gültig für integrierten Extrakt für Oracle.

Gibt den Transaktionsnamen des Replicat-Datenbankbenutzers oder eines anderen Benutzers an, sodass diese Transaktionen nicht von Extract erfasst werden. Wird für die bidirektionale Verarbeitung verwendet, um ein Schleifen von Daten zwischen den Datenbanken zu verhindern.

Weitere Informationen zur bidirektionalen Synchronisierung finden Sie unter Bidirektionale Replikation konfigurieren in der Dokumentation zu Oracle GoldenGate Microservices.

EXCLUDEUSER <user>

Gültig für Db2 LUW, Db2 für z/OS, Db2 für i, Oracle und Sybase.

Gibt den Namen des Replicat-Datenbankbenutzers oder eines anderen Benutzers an, der als Filter verwendet werden soll. In der Regel wird diese Option verwendet, um Replicat-Transaktionen in einer bidirektionalen oder kaskadierenden Verarbeitungskonfiguration zu identifizieren, um sie auszuschließen oder zu erfassen. Es kann jedoch verwendet werden, um Transaktionen von jedem anderen Benutzer zu identifizieren, z. B. von Transaktionen einer bestimmten Geschäftsanwendung.

Sie können EXCLUDEUSER und EXCLUDEUSERID in derselben Parameterdatei verwenden. Verwenden Sie in keinem der Parameter Platzhalter.

Der Benutzername muss gültig sein. Oracle GoldenGate fragt die Datenbank ab, um den zugehörigen Benutzer ID abzurufen, und ordnet die numerische ID wieder dem Benutzernamen zu. Aus diesem Grund bleibt EXCLUDEUSER gültig, wenn der angegebene Benutzer gelöscht und neu erstellt wird, während die Namensauflösung auf den Standardwert DYNAMICRESOLUTION gesetzt ist. Wenn dieselbe Transaktion ausgeführt wird, wenn die Namensauflösung auf NODYNAMICRESOLUTION gesetzt ist, wird EXCLUDEUSER ungültig, und Extract muss gestoppt und dann gestartet werden, damit EXCLUDEUSER wirksam wird, siehe DYNAMICRESOLUTION \| NODYNAMICRESOLUTION.

Beispiel

Das folgende Oracle-Beispielfilter für zwei Benutzer (einer nach Name und einer nach Benutzer ID). Die von diesen Benutzern generierten Transaktionen werden mit Filtertags verarbeitet, und es wird eine neue Transaktionspuffergröße angegeben.

TRANLOGOPTIONS EXCLUDEUSER ggsrep, EXCLUDEUSERID 90, BUFSIZE 100000

Um EXCLUDEUSER mit Mehrmandantenfähigkeit zu verwenden, müssen Sie PDB.USERNAME angeben. Im folgenden Beispiel werden alle DML-Vorgänge ausgeschlossen, die von PDBXYZ.SCOTT ausgeführt werden:

TRANLOGOPTIONS EXCLUDEUSER PDBXYZ.SCOTT

EXCLUDEUSERID <Database_uid>

Gültig für Extract für Oracle.

Gibt den Datenbankbenutzer ID (uid) des Replicat-Datenbankbenutzers oder eines anderen Benutzers an, der als Filter verwendet werden soll. Dieser Parameter ist für mehrmandantenfähige Exporte nicht gültig. Verwenden Sie stattdessen Tagging und EXCLUDETAG.

Die Verwendung entspricht der Verwendung von EXCLUDEUSER.

<Oracle_uid> ist eine nicht negative Ganzzahl mit einem Höchstwert von 2147483638. Es gibt mehrere Systemansichten, die abgefragt werden können, um den Benutzer ID abzurufen. Die einfachste ist die ALL_USERS-Ansicht. Oracle GoldenGate validiert den Benutzer ID nicht. Wenn der Benutzer, der mit dem angegebenen Benutzer ID verknüpft ist, gelöscht und neu erstellt wird, wird der neue Benutzer ID zugewiesen. Daher wird EXCLUDEUSERID für diesen Benutzer ungültig.

FAILOVERTARGETDESTID <n>

Gültig für Extract für Oracle.

Wenn Sie Oracle GoldenGate Extract-Prozesse in einer Oracle Data Guard-Konfiguration verwenden, muss der Extract-Prozess GoldenGate hinter dem Redo zurückbleiben, das auf die Oracle Data Guard-Standbydatenbank angewendet wurde. Mit dem Parameter FAILOVERTARGETDESTID wird der Initialisierungsparameter LOG_ARCHIVE_DEST_n identifiziert, der auf die Standbydatenbank verweist. Dies ist das Failover-Ziel, hinter dem Extract verbleiben muss. Dieser Parameter wird in Kombination mit HANDLEDLFAILOVER verwendet, um zu steuern, ob Extract das Schreiben von Traildaten basierend auf dem Apply-Fortschritt der Oracle Data Guard-Standbydatenbank drosselt. Beachten Sie, dass FAILOVERTARGETDESTID nicht erforderlich ist, wenn für die Data Guard-Konfiguration Fast Start Failover (FSFO) aktiviert ist. Der Mindestwert ist 0, der Höchstwert ist 32 und der Standardwert 0.

Beispiel

Um den entsprechenden Wert für den Extract-Parameter TRANLOGOPTIONS FAILOVERTARGETDESTID zu bestimmen, melden Sie sich bei der Datenbank an, aus der Extract Daten extrahiert, und setzen Sie den folgenden Befehl ab.

SQL> show parameters log_archive_dest
        NAME TYPE VALUE
        -----------------------------------------------------------------------------
         log_archive_dest_1 string location=USE_DB_RECOVERY_FILE_DEST,
         valid_for=(ALL_LOGFILES, ALL_ROLES)

         log_archive_dest_2 string service="ggs2d",
         ASYNC NOAFFIRM delay=0 optional compression =disable max_failure=0
         max_connections=1 reopen=300 db_unique_name="GGS2D" net_timeout=30,
         valid_for=(online_logfile,all_roles)

Der Extract-Parameter TRANLOGOPTIONS FAILOVERTARGETDESTID wird auf 2 gesetzt, da dies die Standbydatenbank ist, die Oracle GoldenGate zurückhalten soll. Der erste Eintrag (log_archive_dest_1) gilt für die lokalen Archive-Logs für diese Datenbank, der zweite für die Standbydatenbank.

Der Wert wird auf 2 gesetzt, weil Oracle GoldenGate die Standby-Datenbank ist, die zurückbleiben soll. Der erste Eintrag (log_archive_dest_1) gilt für die lokalen Archive-Logs für diese Datenbank, der zweite für die Standbydatenbank.

FETCHPARTIALJSON

Gültig für Extract für MySQL

Verwenden Sie diese Option in der Extract-Parameterdatei, um Daten direkt aus der Tabelle abzurufen, wenn teilweise Aktualisierungen an den Datentypspalten JSON einer Tabelle vorhanden sind. Hinweis: Die Verarbeitung von Spaltendatenaktualisierungen in JSON hängt vom Wert der Servervariablen MySQL, binlog_row_value_options, ab, deren Wert als PARTIAL_JSON festgelegt werden muss, und die Extract-Parameterdatei enthält den Parameter FETCHPARTIALJSON.

FETCHPARTIALLOB

Gültig für Extract im integrierten Capture-Modus für Oracle.

Verwenden Sie diese Option beim Replizieren auf ein heterogenes Ziel oder unter anderen Bedingungen, in denen das vollständige LOB-Image erforderlich ist. Dadurch ruft Extract das vollständige LOB-Objekt ab, anstatt das partielle Änderungsobjekt aus dem Redo-Datensatz zu verwenden. Standardmäßig sendet der Datenbank-Logmining-Server Extract eine ganze oder teilweise LOB, je nachdem, ob die gesamte oder ein Teil der Quelle LOB aktualisiert wurde. Um den richtigen Snapshot der LOB sicherzustellen, muss das Oracle Flashback-Feature für die Tabelle aktiviert sein, und Extract muss für die Verwendung konfiguriert sein. Der Extract FETCHOPTIONS-Parameter kontrolliert den Abruf und muss auf USESNAPSHOT gesetzt werden (der Standardwert ohne NOUSESNAPSHOT). Ohne einen Flashback Snapshot ruft Extract die LOB aus der Tabelle ab. Dabei kann es sich um ein anderes Image handeln als zu dem Zeitpunkt, zu dem der Redo-Datensatz generiert wurde.

FETCHPARTIALXML

Gültig für Extract im Oracle-Modus für integrierten Capture-Modus.

Verwenden Sie diese Option beim Replizieren auf ein heterogenes Ziel oder unter anderen Bedingungen, in denen das vollständige LOB-Image erforderlich ist. Dadurch ruft Extract das vollständige XML-Dokument ab, anstatt das teilweise Änderungsbild aus dem Redo-Datensatz zu verwenden. Standardmäßig sendet der Datenbank-Logmining-Server Extract ein ganzes oder teilweises XML-Dokument, je nachdem, ob der Quell-XML vollständig oder teilweise aktualisiert wurde. Um den richtigen Snapshot der XML sicherzustellen, muss das Oracle Flashback-Feature für die Tabelle aktiviert sein, und Extract muss für die Verwendung konfiguriert sein. Der Extract FETCHOPTIONS-Parameter kontrolliert den Abruf und muss auf USESNAPSHOT gesetzt werden (der Standardwert ohne NOUSESNAPSHOT). Ohne Flashback Snapshot ruft Extract das Dokument XML aus der Tabelle ab. Dabei kann es sich um ein anderes Bild handeln als zu dem Zeitpunkt, zu dem der Redo-Datensatz generiert wurde.

EXCLUDEFILTERTABLE <table>

Gültig für Extract für Server MySQL, PostgreSQL und SQL.

Mit dieser Option können Sie eine Quelltransaktion zum Filtern identifizieren. Wenn eine Quelltransaktion einen Vorgang für die angegebene EXCLUDEFILTERTABLE enthält, wird diese Transaktion als replizierte Transaktion identifiziert. Die Transaktionsfilterung basiert auf Tags.

Wenn ein Replicat eine Checkpoint-Tabelle verwendet, schreibt es einen Recovery-Datensatz in die Checkpoint-Tabelle am Ende jeder Transaktion, die es anwendet. Da alle vom Replicat angewendeten Transaktionen eine Aktualisierung der Checkpoint-Tabelle enthalten, ignoriert der Extract die gesamte vom Replicat angewendete Transaktion, wodurch ein Schleifen der Daten verhindert wird. Stellen Sie für den PostgreSQL- und SQL-Server sicher, dass TRANDATA für die Checkpoint-Tabelle hinzugefügt wurde.

Wenn Sie ein paralleles Replicat in einer bidirektionalen Replikation verwenden, werden mehrere Filtertabellen mit der Option TRANLOGOPTIONS EXCLUDEFILTERTABLE unterstützt. Mit mehreren Filtertabellen kann TRANLOGOPTIONS EXCLUDEFILTERTABLE mehrmals mit verschiedenen Tabellennamen oder Platzhaltern angegeben werden.

Sie können einzelne oder mehrere TRANLOGOPTIONS EXCLUDEFILTERTABLE-Einträge in die Extract-Parameterdatei aufnehmen. Im folgenden Beispiel sind mehrere TRANLOGOPTIONS EXCLUDEFILTERTABLE-Einträge in der Extract-Parameterdatei mit expliziten Objektnamen und Platzhaltern enthalten.

TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt2
TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt_RABC_*

Informationen zum Erstellen einer Checkpoint-Tabelle finden Sie unter Primären Extract hinzufügen. Informationen dazu, wie Sie Objektnamen und Platzhalter korrekt angeben, finden Sie unter Platzhalter in Befehlsargumenten verwenden in der Oracle GoldenGate-Microservices-Dokumentation.

FORCEFETCHLOB

Gültig für Extract für Oracle.

Setzt das Standardverhalten des Erfassens von LOB-Daten aus dem Redo-Log außer Kraft. LOBs werden standardmäßig aus der Datenbank abgerufen.

Achtung: Wenn ein Wert vor dem Abruf gelöscht wird, schreibt Extract einen Nullwert in den Trail. Wenn ein Wert vor einem Abruf aktualisiert wird, schreibt Extract den aktualisierten Wert. Um diese Ungenauigkeiten zu vermeiden, versuchen Sie, die Extract-Latenz niedrig zu halten. Die Oracle GoldenGate-Dokumentation enthält Richtlinien für die Optimierung der Prozessperformance. Anweisungen zum Festlegen der Fetch-Optionen finden Sie unter Interaktionen zwischen Fetch-Vorgängen aus einer Tabelle und DDL.

GETCTASDML | NOGETCTASDML

Aktiviert die Funktion "Tabelle als Auswahl erstellen" (CTAS). Wenn GETCTASDML aktiviert ist, werden CTAS-DMLs von LogMiner gesendet und auf dem Ziel repliziert. Diese Option ist standardmäßig aktiviert. Die Ausführung des CTAS DDL wird auf dem Ziel unterdrückt.

HANDLEDLFAILOVER [ STANDBY_WARNING <value> | STANDBY_ABEND <value>]

Gültig für Extract für Oracle

STANDBY_WARNING und STANDBY_ABEND gültig für Oracle Database 21c und höher.

Steuert, ob Extract das Schreiben von Traildaten basierend auf dem Anwendungsfortschritt der Fast Start Failover-Standbydatenbank drosselt. Es soll Extract an einem sicheren Punkt hinter jedem Datenverlust-Failover halten.

Wenn Sie dies für Datenverlust in einer Data Guard-Konfiguration ohne Fast Start Failover (FSFO) verwenden, müssen Sie den Parameter FAILOVERTARGETDESTID Extract festlegen, um das Archive-Logziel ID zu identifizieren, mit dem die Standbydatenbank verbunden werden kann.

Extract befindet sich in einem verzögerten Status, wenn Extract die SCN-Informationen zur Standbydatenbankanwendung abfragt (SELECT applied_scn FROM v$archive_dest where dest_id=n), und diese SCN ist kleiner als die LCR-SCN zur Extraktionsverarbeitung. In diesem Fall verarbeitet Extract den LCR nicht und wartet, bis applied_scn größer oder gleich der Extract-Verarbeitungs-LCR-SCN wird.

STANDBY_WARNING <value>

Gibt an, wie lange eine Warnmeldung in die Extract-Berichtsdatei geschrieben wird, wenn Extract blockiert ist. Der Standardwert ist 60 Sekunden.

STANDBY_ABEND <value>

Die Zeit, die vor dem Export abfällt, wenn Extract blockiert ist. Der Standard ist 30 Minuten.

Wenn sowohl STANDBY_WARNING als auch STANDBY_ABEND angegeben sind, muss STANDBY_ABEND immer größer als STANDBY_WARNING sein.

IFILOCKSECONDS <seconds>

Gültig für Db2 z/OS

Legt das Intervall in <seconds> fest, in dem der Extract die impliziten Sperren enthält, die in der Datenbank durch die Aufrufe von IFCID gehalten werden

  1. Die Sperren können sich auf die Möglichkeit auswirken, bestimmte Datenbankvorgänge wie REORGS auszuführen. Der Standardwert ist 20 Sekunden, wobei die Mindest- und Höchstwerte 1 Sekunde bzw. 300 Sekunden betragen. Hinweis: Wenn der Parameter IFILOCKSECONDS länger festgelegt ist, können andere Datenbankvorgänge wie REORGS durch interne Sperren beeinträchtigt werden, die durch die Extract-IFI-Aufrufe verursacht werden. Wenn also ein Sperrkonflikt in Bezug auf einen Extract auftritt, legen Sie entweder den Sperr-Timeout für den Vorgang auf eine Dauer fest, die länger als der Wert des Parameters IFILOCKSECONDS ist, oder fahren Sie den Extract herunter.
IGNOREDATACAPTURECHANGES NOIGNOREDATACAPTURECHANGES

Gültig für Db2 LUW

Steuert, ob Extract Tabellen erfasst, für die DATA CAPTURE CHANGES nicht festgelegt ist. IGNOREDATACAPTURECHANGES ignoriert Tabellen, für die DATA CAPTURE CHANGES nicht festgelegt ist. Verwenden Sie diese Option, wenn Tabellen mit einem Platzhalter angegeben wurden, um sicherzustellen, dass die Verarbeitung für Tabellen mit einem Change Capture-Set fortgesetzt wird. Für Tabellen, die übersprungen wurden, wird eine Warnung an das Fehlerlog ausgegeben. Der Standardwert ist NOIGNOREDATACAPTURECHANGES.

INCLUDEREGIONID INCLUDEREGIONIDWITHOFFSET

Gültig für Extract für Oracle.

Diese Optionen unterstützen den Oracle-Datentyp TIMESTAMP WITH TIME ZONE, der als TZR angegeben ist (der die Zeitzonenregion darstellt, wie US/Pacific). Standardmäßig ändert Extract den Wert für TIMESTAMP WITH TIME ZONE, wenn er eine Zeitzonenregion enthält. Mit diesen Optionen können Sie diesen Zeitstempel basierend auf dem Zieldatenbanktyp verarbeiten.

Wenn Extract erkennt, dass der Quelldatentyp TIMESTAMP ist und ein Region-ID-Mappingtoken vorhanden ist, wendet Replicat den Zeitstempel wie folgt an:

INCLUDEREGIONID

Gültig für integrierten Extrakt für Oracle.

Die INCLUDEREGIONID ist für Oracle GoldenGate 19c (19.1.0) veraltet. Ab Oracle GoldenGate 19c (19.1.0) ist TIMESTAMP WITH TIME ZONE mit Daten der Region ID standardmäßig enthalten, einschließlich anfänglichem Laden.

Wird bei der Replikation von einer Oracle-Quelle auf ein Oracle-Ziel derselben Version oder höher verwendet. Wenn INCLUDEREGIONID angegeben ist, fügt Extract einen Spaltenindex und den TMZ-Zwei-Byte-Wert als Zeitzonenzuordnungstoken hinzu und gibt ihn im UTC-Format von YYYY-MM-DD HH:MI.SS.FFFFFF +00:00 an den Trail aus.

INCLUDEREGIONIDWITHOFFSET

Gültig für integrierten Extrakt für Oracle.

Verwenden Sie diese Option, um die Region ID in den Offsetwert für Stunde und Minuten (+06:00 als Beispiel) zu konvertieren. Wenn die Option nicht angegeben ist, wird der Zeitstempel immer in UTC in die Traildatei geschrieben, und die Zeitzone ist immer +00:00.

Wenn Sie den Zeitzonenwert in Stunde und Minuten anstelle von UTC beibehalten müssen, kann diese Option verwendet werden.

In den folgenden Fällen muss die Option aktiviert werden, um TIMEZONE <value> in Stunde und Minuten <offset> beizubehalten:

INCLUDETAG {<tag>| +}

Gültig für Extract. (Nur Oracle)

Verwenden Sie INCLUDETAG <tag>, um bestimmte getaggte DDL-Vorgänge in die Traildateien aufzunehmen. Der Tagwert kann bis zu 2000 Hexadezimalziffern (0-9 A-F) betragen.

Um Konflikte zu vermeiden, verwenden Sie INCLUDETAG nicht in Verbindung mit EXCLUDETAG.

Beispiel: tranlogoptions includetag 00

LOB_CHUNK_SIZE

Gültig für SQL Server, PostgreSQL.

Wenn Sie große LOB-Datengrößen haben, können Sie LOB_CHUNK_SIZE vom Standard von 4000 Byte auf einen höheren Wert bis zu 65535 Byte anpassen, sodass die Fetch-Größe erhöht wird. Dadurch werden die zum Abrufen der gesamten LOB erforderlichen Trips reduziert

Beispiel: TRANLOGOPTIONS LOB_CHUNK_SIZE 8000

(PostgreSQL) Gibt die Größe des Chunk für die Daten LOB (CLOB/BLOB) an, die zum Push in COM verwendet werden. Die Einheit ist in Byte angegeben. Der Mindest- und Höchstwert für lob_chunk_size liegt zwischen 4000 und 65535 Byte.

LOGREADTIMEOUT

Gültig für Extract für PostgreSQL Version 12 und höher.

Aktiviert oder deaktiviert die Option wal_sender_timeout für den WAL-Senderprozess.

Die Option value kann nur ein ganzzahliger Wert sein, wobei 60000 Millisekunden der Standardwert ist. Der Höchstwert beträgt 2147483647 Millisekunden und der Mindestwert 0 Millisekunden.

INTEGRATEDPARAMS (<parametervalue> [, ...])

Gültig für Extract im integrierten Capture-Modus für Oracle Standard oder Enterprise Edition 12c oder höher.

Übergibt Parameter und Werte an den Oracle AI Database-Logmining-Server, wenn Extract sich im integrierten Capture-Modus befindet. Die Eingabe muss das Format <parameter value> aufweisen, wie in:

TRANLOGOPTIONS INTEGRATEDPARAMS (downsream_real_time_mine Y)

Gültige Parameterspezifikationen und deren Werte sind:

max_sga_size

Gibt den SGA-Speicher an, der vom Logmining-Server der Datenbank verwendet wird. Kann eine positive Ganzzahl in Megabyte sein. Der Standardwert ist 1 GB, wenn streams_pool_size größer als 1 GB ist. Andernfalls beträgt er 75% von streams_pool_size.

parallelism

Gibt die Anzahl der Prozesse an, die den Logmining-Server der Datenbank unterstützen. Kann eine positive Ganzzahl sein. Der Standardwert lautet 2.

downstream_real_time_mine

Gibt an, ob der integrierte Capture-Prozess eine Downstream-Mining-Datenbank im Echtzeitmodus abbaut. Der Wert Y gibt Echtzeiterfassung an und erfordert, dass Standby-Redo-Logs in der Downstream-Mining-Datenbank konfiguriert werden. Der Wert N gibt Capture aus archivierten Logs an, die an die Downstream-Mining-Datenbank gesendet werden. Der Standardwert ist N.

enable_procedural_replication

Aktiviert die prozedurale Replikation bei Capture. Die prozedurale Replikation ist standardmäßig deaktiviert. Der Wert Y aktiviert die prozedurale Replikation. Sobald diese Option für einen Extract aktiviert ist, bleibt sie aktiviert. Der Parameterwert kann nicht umgeschaltet werden.

MANAGESECONDARYTRUNCATIONPOINT NOMANAGESECONDARYTRUNCATIONPOINT

Gültig für PostgreSQL.

MANAGESECONDARYTRUNCATIONPOINT ist die Standardeinstellung und steuert die restart_lsn des Replikationsslots für den spezifischen Extract.

NOMANAGESECONDARYTRUNCATIONPOINT verschiebt den Replikations-Slot des Extract nicht und wird in der Regel nur zu Entwicklungs- und Testzwecken verwendet, wenn ein Extract in eine frühere LSN aus der Recovery LSN des Extract neu positioniert werden muss. Wenn es verwendet wird, nimmt das Write-Ahead-Log PostgreSQL weiter zu und belegt Speicherplatz.

MAXAUTOCMTTRANSSIZE (<range>, <default>)

Gültig für DB2 nur für i

Gibt den Bereich der maximalen Größe der automatisch zugewiesenen Transaktion an.

Db2 für i-Autocommited-Datensätze (Journalbuchung hat CCID gleich 0) weist keinen Commit-Datensatz im Journal auf. Daher muss Oracle GoldenGate eine implizite Transaktion erstellen, um diese Datensätze in den Trail aufzunehmen. Der Standardwert ermöglicht, dass ein einzelner Datensatz in eine einzelne Transaktion aufgenommen wird. Dadurch wird die Genauigkeit der angegebenen I/O-Zeit für jeden Datensatz beibehalten, da die I/O-Zeit auf dem Commit für die Transaktion basiert.

Dieser Parameter legt die maximale Anzahl von Datensätzen fest, die in eine implizit erstellte Transaktion eingeschlossen werden. Die Anzahl könnte jedoch geringer sein, wenn ein anderer Buchungstyp in der Buchung angezeigt wird, bevor der Höchstwert erreicht wird. Mit dieser Antwort werden Probleme mit Überschneidungen für Checkpoints in Datensätzen vermieden, die zu explizit festgeschriebenen Datensätzen gehören.

Wenn Sie den Wert für diesen Parameter auf 1 (defulat) setzen, erhalten Sie eine genaue I/O-Zeit für jeden Datensatz im Trail für automatisch zugesagte Datensätze (mit einer CCID von 0 in der Journalbuchung) zu potenziellen Kosten des Durchsatzes für den Export. Der Wert dieses Parameters wirkt sich auch auf die maximale potenzielle Größe einer gecachten Transaktion für diese Datensätze im Speicher aus. Wenn der Wert auf einen niedrigeren Wert gesetzt wird, ist der Transaktionsspeicher niedriger, wenn der Extract die maximale Anzahl von Einträgen pro impliziter Transaktion speichern kann. Per Definition kann es zu einem bestimmten Zeitpunkt nur eine solche implizite Transaktion im Speicher geben, da andere Transaktionsdatensätze einen sofortigen Commit in den Trail von Datensätzen in einer impliziten Transaktion verursachen, die bereits im Speicher ist.

Der Standardbereich liegt zwischen 1 und 10000. Der Standardwert ist 1.

MININGUSER {/ | <useridalias> [<algorithm> ENCRYPTKEY {<key_name> | DEFAULT}] [SYSDBA]]

Gültig für Oracle GoldenGate Extract for Oracle.

Gibt Anmeldezugangsdaten für Extract an, um sich bei einer Downstream-Oracle-Mining-Datenbank anzumelden und mit dem Logmining-Server zu interagieren. Kann anstelle der Option MININGUSERIDALIAS verwendet werden, wenn kein Oracle GoldenGate-Zugangsdatenspeicher verwendet wird.

Dieser Benutzer muss:

/

Weist Oracle GoldenGate an, eine Betriebssystemanmeldung für Oracle und keine Datenbankbenutzeranmeldung zu verwenden. Verwenden Sie dieses Argument nur, wenn die Datenbank die Authentifizierung auf Betriebssystemebene zulässt. Durch die Umgehung der Authentifizierung auf Datenbankebene müssen keine Oracle GoldenGate-Parameterdateien aktualisiert werden, wenn sich Anwendungskennwörter häufig ändern.

Zur Verwendung dieser Option muss der übereinstimmende Benutzername in der Datenbank vorhanden sein, in Relation zu dem Wert des Oracle-Initialisierungsparameters OS_AUTHENT_PREFIX. Der mit OS_AUTHENT_PREFIX festgelegte Wert wird mit dem Namen des Betriebssystemaccounts eines Benutzers verkettet und dann mit dem Datenbanknamen verglichen. Diese beiden Namen müssen übereinstimmen.

Wenn OS_AUTHENT_PREFIX auf ' ' (eine Nullzeichenfolge) gesetzt ist, muss der Benutzername mit IDENTIFIED EXTERNALLY erstellt werden. Beispiel: Wenn der Benutzername OS ogg lautet, erstellen Sie den Datenbankbenutzer wie folgt:

CREATE USER ogg IDENTIFIED EXTERNALLY;

Wenn OS_AUTHENT_PREFIX auf OPS$ oder eine andere Zeichenfolge gesetzt ist, muss der Name <user> im folgenden Format erstellt werden:

<OS_AUTHENT_PREFIX_value><OS_user_name>

Beispiel: Wenn der Name von OS <user> ogg lautet, erstellen Sie die Datenbank <user> wie folgt:

CREATE USER ops$ogg IDENTIFIED BY oggpassword;

<user>

Gibt den Namen eines Mining-Datenbankbenutzers oder eine SQL*Net-Verbindungszeichenfolgean.

<password>

Das Kennwort des Benutzers. Verwenden Sie diese Option, wenn die Datenbankauthentifizierung erforderlich ist, um das Kennwort für den Datenbankbenutzer festzulegen. Wenn das Kennwort mit dem Befehl ENCRYPT PASSWORD verschlüsselt wurde, Geben Sie das verschlüsselte Kennwort an. Andernfalls verwenden Sie das Klartextkennwort. Beachten Sie gegebenenfalls die Groß-/Kleinschreibung des Kennworts. Wenn sich der Benutzer ID oder das Kennwort ändert, muss die Änderung in den Oracle GoldenGate-Parameterdateien vorgenommen werden, einschließlich der erneuten Verschlüsselung des Kennworts, falls erforderlich.

<algorithm>

Gibt die Verschlüsselung <algorithm> an, die zum Verschlüsseln von <password> mit ENCRYPT PASSWORD verwendet wurde. Folgende Werte sind möglich:

AES128
AES192
AES256

ENCRYPTKEY {<key_name> | DEFAULT}

Gibt den Verschlüsselungsschlüssel an, der mit ENCRYPT PASSWORD angegeben wurde.

SYSDBA

Gibt an, dass der Benutzer sich als sysdba anmeldet.

MININGUSERIDALIAS <alias>

Gültig für Extract für Oracle.

Gibt den Alias für die Anmeldedaten an, mit denen Extract sich bei einer Downstream-Oracle Mining-Datenbank anmeldet, um mit dem Logmining-Server zu interagieren. Kann anstelle von MININGUSER verwendet werden, wenn ein Oracle GoldenGate-Zugangsdatenspeicher verwendet wird.

Dieser Alias muss lauten:

Dieser Alias und Benutzer dürfen nicht geändert werden, während sich Extract im integrierten Erfassungsmodus befindet.

MIXEDENDIAN [ON OFF]

Gültig für Db2 LUW mit Oracle GoldenGate-Primärextrakt

Oracle GoldenGate Extract for Db2 LUW unterstützt Cross-Endian Capture-Prozesse, bei denen die Datenbank und Oracle GoldenGate auf verschiedenen Byte-Order-Servern ausgeführt werden. Die Erkennung der Byte-Reihenfolge erfolgt automatisch für Db2 LUW-Datenbankversion 10.5 und höher. Wenn Sie die automatische Erkennung in Db2 LUW 10.5 deaktivieren müssen, können Sie sie überschreiben, indem Sie diesen Parameter angeben. Für Version 10.1 muss der Parameter in der Extract-Parameterdatei für den Cross-Endian Capture-Prozess verwendet werden. Standardmäßig ist der Wert für Version 10.1 auf OFF gesetzt.

Syntax:

TRANLOGOPTIONS MIXEDENDIAN [ON|OFF]

ON: Wenn dies festgelegt ist, geht der Extract davon aus, dass die Datenbank und Oracle GoldenGate auf Servern mit einer anderen Bytereihenfolge ausgeführt werden und die erforderliche Byteumkehrkonvertierung ausgeführt wird.

OFF: Wenn dies festgelegt ist, geht der Extract davon aus, dass die Datenbank und Oracle GoldenGate auf Servern mit derselben Bytereihenfolge ausgeführt werden und keine Umkehrkonvertierung der Bytereihenfolge ausgeführt wird.

MANAGECDCCLEANUP NOMANAGECDCCLENUP

Gültig für SQL-Server.

MANAGECDCCLEANUP ist die Standard- und empfohlene Einstellung, die den Extract anweist, das Vorhandensein des Oracle GoldenGate CDC-Bereinigungsjobs oder der Aufgabe "Änderungsdaten löschen" zu validieren, je nach Architektur und Version von Oracle GoldenGate.

Verwenden Sie für alle Oracle GoldenGate Classic Architecture-Versionen und für Microservices-Versionen vor Oracle GoldenGate 21.4 das Programm ogg_cdc_cleanup_setup.bat/sh, um den Oracle GoldenGate CDC-Bereinigungsjob und die zugehörigen Tabellen und gespeicherten Prozeduren zu installieren.

Erstellen Sie bei Oracle GoldenGate Microservices 21.4 und späteren Installationen auf der Seite "Aufgaben" im Abschnitt "Konfiguration" des Administrationsservice von WebUI eine Aufgabe "Änderungsdaten löschen". Die Aufgabe "Änderungsdaten löschen" erstellt die erforderlichen gespeicherten Prozeduren und verknüpften Tabellen und verarbeitet die Löschfunktion in Oracle GoldenGate und nicht über den Server-Agent-Job SQL.

Die Option NOMANAGECDCCLEANUP weist Extract an, nicht zu prüfen, ob der Oracle GoldenGate CDC-Bereinigungsjob oder die Aufgabe "Änderungsdaten löschen" vorhanden ist. Dies ist keine empfohlene Option für Produktionsumgebungen, kann jedoch zum Testen eines Extract verwendet werden, ohne den Oracle GoldenGate CDC-Bereinigungsjob oder die Aufgabe erstellen zu müssen.

PERFORMANCEPROFILE HIGH MEDIUM LOW_RES LOW_WORKLOAD

Gültig für Extract im integrierten Erfassungsmodus.

Für die Optimierung von Integrated Capture.

Sie kann auf HIGH, MEDIUM (Standard) oder LOW_RES gesetzt werden. Sie hilft, eine bessere Performance zu erzielen, indem sie die Parameter gruppiert, die sich auf die Performance auswirken. Nachdem das Performanceprofil eingerichtet worden ist, konfiguriert diese Option automatisch die relevanten Parameter, um den erforderlichen Durchsatz und die erforderliche Latenz zu erreichen.

Wenn die Option HIGH für Workloads mit geringer bis mittlerer Intensität aktiviert ist, wird die integrierte Extract-Latenz auf mehrere Sekunden erhöht. Der Grund dafür ist, dass die Option HIGH die Lesepuffergröße des Extract auf 8 MB erhöht. Die Regel zum Leeren des Extract-Lesepuffers lautet jedoch entweder, wenn der Puffer voll ist oder wenn für eine Dauer von 0,2 Sekunden keine eingehenden Datensätze vorhanden sind. Daher führt jede kontinuierliche Workload mit einer Extract-Aufnahmerate von weniger als 8 MB zu einer integrierten Extract-Latenz von mehr als 1 Sekunde. Stellen Sie sicher, dass Sie die Option HIGH nicht verwenden, wenn die Extract-Aufnahmeraten (oder Redo-Generierungsraten, wenn 100% der Redo-Daten erfasst werden) niedriger als der angegebene Wert sind, z.B. ~15 MB/s, um eine Extrahierungslatenz von ~0,5 Sekunden zu erhalten. Wenn eine Latenzzeit von unter einer Sekunde erforderlich ist, wird empfohlen, die Puffergröße entsprechend zu senken. Stellen Sie beispielsweise die Puffergröße auf ein Drittel der Redo-Generierungsrate in MB/s ein, um die maximale Extraktionslatenz von ~0,3 Sekunden zu erhalten.

QUERYTIMEOUT <seconds>

Gültig für SQL-Server.

Gibt an, wie lange Abfragen an den SQL-Server auf Ergebnisse warten, bevor eine Timeoutfehlermeldung gemeldet wird. Diese Option verwendet einen ganzzahligen Wert, um die Anzahl der Sekunden darzustellen. Der Standardwert für den Abfrage-Timeout beträgt 300 Sekunden (5 Minuten). Der Mindestwert beträgt 0 Sekunden (unendlicher Timeout). Das Maximum beträgt 2147483645 Sekunden.

Im folgenden Beispiel wird der SQL-Server angewiesen, 60 Sekunden auf Ergebnisse zu warten, bevor ein Timeout auftritt.

TRANLOGOPTIONS QUERYTIMEOUT 60

QUERYRETRYCOUNT <seconds>

Gültig für Extract für SQL-Server und MySQL.

Gibt an, wie oft Aufrufe der gespeicherten CDC-Prozedur, die von Extract verwendet werden, wiederholt werden müssen, falls ein Timeout für die Ergebnissetierung auftritt.

QUERYRETRYCOUNT kann angegeben werden, um es mehrmals zu wiederholen. Wenn alle Wiederholungsversuche nicht erfolgreich sind, wird Extract mit der Fehlermeldung "normal connection timeout" beendet.

Für den SQL-Server ist der Standardwert ein Wiederholungsversuch. Danach ist die Mindesteinstellung (0) des Prozesses abends.The unendlich, das Maximum ist 1000 und der Standardwert ist 1.

Für MySQL sind die Mindest- und Standardeinstellung 50 und das Maximum 1000. Es gibt keinen unendlichen Wert. Jeder Versuch, QUERYRETRYCOUNT auf ein Minimum zu setzen, wird ohne Fehler oder Warnung ignoriert.

Das folgende Beispiel veranlasst Extract, seinen Aufruf der gespeicherten CDC-Prozedur 4 Mal zu versuchen:

TRANLOGOPTIONS QUERYRETRYCOUNT 4

Das folgende Beispiel veranlasst Extract, seinen Aufruf der gespeicherten CDC-Prozedur 100 Mal zu versuchen:

TRANLOGOPTIONS QUERYRETRYCOUNT 100

READQUEUESIZE <size>

Gültig für MySQL.

Gibt die Größe der internen Queue in Byte für Transaktionsdaten an. Es kann erhöht werden, um die Leistung zu verbessern. Gültige Werte sind Ganzzahlen von 3 bis 1500. Der Standardwert ist 256 Byte. Beginnen Sie mit dem Standardwert, und bewerten Sie die Performance, bevor Sie sie nach oben anpassen.

REDO_TRANSPORT_LAG_THRESHOLD <seconds>

Gültig für integrierten Extrakt im Downstream-Mining-Modus.

Überwacht die Netzwerklatenz zwischen einer Quell- und Zieldatenbank, wenn Redo-Logs versendet werden. Wenn die Latenzzeit den angegebenen Schwellenwert überschreitet, wird in der Berichtsdatei eine Warnung angezeigt, und eine nachfolgende Informationsmeldung wird angezeigt, wenn die Verzögerung auf die normale Ebene fällt.

Der Standardschwellenwert beträgt 30 Sekunden. Der Mindestschwellenwert, der angegeben werden kann, beträgt 15 Sekunden.

Weitere Informationen finden Sie unter Downstream-Extrakt.

REDO_TRANSPORT_LAG_TIMEOUT <value>

Gültig für integrierten Extrakt im Downstream-Mining-Modus.

Der als Eingabe in dieser Parameteroption angegebene Wert ist der Zeitraum, für den Extract auf Redo von jedem Thread wartet. Wenn alle Threads auf den Timeout gewartet haben (in Sekunden) und kein Redo erhalten haben, wird Extract beendet.

REQUIRELONGDATACAPTURECHANGES NOREQUIRELONGDATACAPTURECHANGES

Gültig für Db2 LUW.

Kontrolliert die Antwort von Extract, wenn DATA CAPTURE auf NONE oder auf CHANGES ohne INCLUDE LONGVAR COLUMNS gesetzt ist und die Parameterdatei einen der folgenden Oracle GoldenGate-Parameter enthält, für die Before Images für einige oder alle Spaltenwerte erforderlich sind: GETBEFOREUPATES, NOCOMPRESSUPDATES und NOCOMPRESSDELETES. Beide DATA CAPTURE-Einstellungen verhindern das Logging von Before-Werten für LONGVAR-Spalten. Wenn diese Spalten nicht für Extract verfügbar sind, kann dies die Integrität der Zieldaten beeinträchtigen.

REQUIRELONGDATACAPTURECHANGES

Extract wird mit einem Fehler abgebrochen.

NOREQUIRELONGDATACAPTURECHANGES

Extract gibt eine Warnung aus, setzt jedoch die Verarbeitung des Datensatzes fort.

REMOTESCHEMA <value>

Gültig für Db2 z/OS Extract.

Wenn Sie mehrere Versionen von Oracle GoldenGate für Db2 z/OS Extract verwenden, müssen Sie mehrere Versionen von GoldenGate Extract-Komponenten innerhalb von Db2 z/OS unter verschiedenen Schemanamen erstellen. Mit dem Parameter REMOTESCHEMA wird der Extract angewiesen, welches Schema verwendet werden soll.

Weitere Informationen finden Sie unter Extract-Komponenten auf Db2 z/OS installieren in der Dokumentation zu Oracle GoldenGate-Microservices.

SOURCE_OS_TIMEZONE <timezone>

Gültig für Extract im integrierten Capture-Modus für Oracle.

Gibt die Systemzeitzone der Quelldatenbank an. Die Systemzeitzone einer Datenbank wird in der Regel von der Standardzeitzone ihres Betriebssystems vorgegeben. Sie kann auch überschrieben werden, indem die Umgebungsvariable TZ beim Starten der Datenbank festgelegt wird. Sie sollten diese Option nur angeben, wenn die Quelldatenbank und der Extraktionsprozess unterschiedliche Systemzeitzonen verwenden. Beispiel: In einem Downstream Capture Deployment, bei dem die Quelldatenbank und der Extract-Prozess auf verschiedenen Servern in verschiedenen Zeitzonen ausgeführt werden.

Sie können den Wert dieser Option in einem Zeitzonenregionsnamen oder einem UTC-Offsetformular angeben, und Sie müssen dasselbe Formular verwenden, das von der Quelldatenbank verwendet wird. Beispiel: Wenn die Quelldatenbank ein Regionsnamensformular wie America/New_York verwendet, müssen Sie America/New_York, US/Eastern oder EST5EDT angeben. Alternativ müssen Sie die Syntax (GMT)[+|-]hh[:mm] verwenden, wenn die Quelldatenbank ein UTC-Offsetformular wie -05:00 verwendet. Beispiel: GMT-05:00 oder -5.

SKIPUNKNOWNEVENT

Gültig für MySQL.

Sie können diesen Parameter in der Extract-Parameterdatei verwenden, um das Überspringen von nicht behandelten oder unbekannten Ereignissen im Binärlog MySQL zu aktivieren. Wenn dieser Parameter angegeben ist, wird die Verarbeitung von Oracle GoldenGate für MySQL Extract ohne Fehler beim Suchen eines Ereignisses fortgesetzt, das nicht vom aktuellen Extract-Prozess verarbeitet wird.

STREAMINGOPTIONS

Gültig für PostgreSQL.

Mit diesem Parameter können Sie Parameter angeben, die beim Hochfahren der Replikation erforderlich sind. Weitere Informationen finden Sie unter Export für PostgreSQL registrieren in der Dokumentation zu Oracle GoldenGate-Microservices.

Beispiel:

TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2, my_publication";)

SUPPRESSNOOOPUPDATES

Gültig für Extract in Oracle AI Database.

Sie können steuern, ob No-OP-Aktualisierungen in Integrated Extract gefiltert werden. Der Standardwert lautet keine Unterdrückung.

TRACKSCHEMACHANGES NOTRACKSCHEMACHANGES

Gültig für Db2 z/OS und MySQL

Für Oracle GoldenGate für Db2 z/OS ermöglicht dieser Parameter Extract, DDL-Anweisungen auf Tabellenebene zu erfassen und eine Historie der Änderungen beizubehalten, die zur Verarbeitung von DML verwendet werden sollen, wenn sich die Logdatensätze auf eine Tabellenversion beziehen, die vor der aktuellen Version der Tabelle liegt. Dies wäre in der Regel vor Images von Updates, könnte aber nach Images, Einfügungen oder Löschvorgängen erfolgen, wenn der Extract in einer Verzögerungssituation aus dem Log-Backlog ausgeführt wird. Wenn Extract die entsprechenden DDL-Vorgänge findet, wird die Versionsnummer der DDL notiert, und die DDL-Historientabelle wird mit den neuen Informationen aktualisiert. Der Extract erstellt einen neuen TDR-Datensatz, der sich auch auf die Änderung im Trail bezieht. Wenn Extract frühere Versionen der Tabelle im Log findet, referenziert es die DDL-Historie, um die DDL für die ältere Version der Tabelle korrekt interpretieren zu können. Die Änderung DDL wird nicht tatsächlich repliziert, und die Synchronisierung aller Änderungen an der Quelltabelle muss weiterhin manuell vom Benutzer in der Zieldatenbank ausgeführt werden.

Wenn Sie diesen Befehl eingeben, können die Änderungen auf Tabellenebene DDL vom Extract verfolgt werden, und die Trailmetadaten werden entsprechend aktualisiert. Um TRACKSCHEMACHANGES richtig zu verwenden, müssen die Tabellenmetadaten einen bekannten konsistenten Status aufweisen. Das bedeutet, dass alle Tabellen, die Versionsverfolgung benötigen, erstellt und vor der Verwendung von TRACKSCHEMACHANGES nie geändert oder reorganisiert werden müssen, damit keine vorherigen Tabellenversionen im Transaktionslog für Aktualisierungs- oder Löschvorgänge angezeigt werden. Das Skript ddl_update.sh wurde bereitgestellt, um die Erstellung eines anfänglichen Sets von DDL-Historiendatensätzen für die Datenbank zu unterstützen.

Um die DDL-Verarbeitung zu verwenden, muss die Datenbank mit einer Historientabelle eingerichtet werden, die DDL-Änderungen der verschiedenen Versionen aller Tabellen im Datenbanksystem erfasst. Außerdem müssen Systemtabellen für Datenerfassungsänderungen aktiviert werden. Zum Erstellen und Verwalten der Historientabelle werden die folgenden UNIX-Shell-Skripte bereitgestellt:

Diese Skripte können verwendet werden, um die Tabellen direkt mit einer Db2-Verbindung zu erstellen, oder sie können verwendet werden, um SQL-Dateien zu erstellen, die in einem SQL-Verarbeitungsprogramm der Wahl ausgeführt werden können. Die Dateien wurden auf Kompatibilität mit Db2 remote und SPUFI geprüft.

Im Folgenden finden Sie eine Beschreibung der Optionen, die von diesen Skripten akzeptiert werden:

Bei Oracle GoldenGate für MySQL wird die DDL-Replikation mit Erfassung und Zustellung unterstützt. Wenn die DDL-Replikation aktiviert ist, erkennt Extract die DDL-Vorgänge in der Quelldatentabelle, verarbeitet die DDL-Anweisung, aktualisiert die Tabellenmetadaten und schreibt die DDL-Anweisung und Metadaten in die Traildatei. Replicat wendet diese DDL-Vorgänge in der MySQL-Zieldatenbank an und wählt auch die neue Version der Metadaten aus dem Trail aus, und verarbeitet nachfolgende DML-Vorgänge. Dieser gesamte Prozess ist nahtlos und es sind keine Ausfallzeiten erforderlich, dies ist jedoch nur für das gleiche Szenario möglich, wie z. B. (MySQL bis MySQL).

Mit dem Parameter TRACKSCHEMACHANGES können Sie die Tabellenmetadatenänderungen nach dem DDL-Vorgang in Quelltabellen erfassen, sodass der Capture-Vorgang nachfolgende DML-Vorgänge ohne Ausfallzeit verarbeiten kann. Wenn TRACKSCHEMACHANGES aktiviert ist, schreibt der Capture-Prozess einen neuen TDR-Datensatz in den Trail, der die neuen Metadaten für jeden DDL-Vorgang gefolgt von den entsprechenden Daten enthält. Capture verarbeitet und schreibt die DDL-Anweisung nicht in die Traildatei, sodass die DDL-Änderungen nicht tatsächlich in der Zieldatenbank repliziert werden. Die Synchronisierung aller DDL-Änderungen, die der Quelle entsprechen, muss manuell in der Zieldatenbank ausgeführt werden. Der Vorteil der Verwendung dieses Features besteht darin, dass TRACKSCHEMACHANGES im Gegensatz zur DDL-Replikation in datenbankübergreifenden Replikationsszenarios verwendet werden kann, z.B. MySQL bis Db2 z/OS.

Beachten Sie Folgendes, wenn Sie den Befehl TRANLOGOPTIONS TRACKSCHEMACHANGES verwenden:

TRANCOUNT

Gültig für SQL-Server.

Ermöglicht die Anpassung der Anzahl der pro Aufruf von Extract verarbeiteten Transaktionen, um Daten aus den Staging-Tabellen für Change Data Capture des SQL-Servers abzurufen. Je nach Transaktions-Workload kann die Anpassung dieses Werts den Durchsatz der Erfassungsrate verbessern. Der Mindestwert ist 1, der Höchstwert 100 und der Standardwert 10.

Beispiel:

TRANLOGOPTIONS TRANCOUNT 20

In diesem Beispiel wird Extract angewiesen, jeweils 20 Transaktionen aus Tabellen abzurufen, die für die Änderungsdatenerfassung aktiviert sind.

[TSLOOKUPBEGINLRI TSLOOKUPENDLRI]

Gültig für Db2 LUW Version 10.1 und höher.

Wenn Sie einen LRI-Bereich mit diesen Parametern angeben, sucht Extract nach dem Zeitstempel, der im Befehl ADD oder ALTER EXTRACT innerhalb dieses Bereichs angegeben ist. Auf diese Weise kann Extract den Suchprozess für einen bestimmten Zeitstempel im Datenbanktransaktionslog optimieren. Der Parameter TSLOOKUPBEGINLRI ist obligatorisch, während TSLOOKUPENDLRI optional ist. Die Angabe von nur TSLOOKUPENDLRI ohne TSLOOKUPBEGINLRI ist ungültig, wodurch der Extract abgebrochen wird. Beispiel:

TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197, TSLOOKUPENDLRI  75207.666216
TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197

Wenn der angegebene Zeitstempel zwischen den angegebenen LRI-Bereichen liegt oder der angegebene Zeitstempel nach dem LRI-Zeitstempel TSLOOKUPBEGINLRI liegt, beginnt Extract mit einem Datensatz mit einem Zeitstempel, der kleiner/gleich dem angegebenen Zeitstempel ist.

Wenn der angegebene Zeitstempel vor dem LRI-Zeitstempel TSLOOKUPBEGINLRI liegt, wird Extract aus dem angegebenen LRI TSLOOKUPBEGINLRI gestartet. Wenn der angegebene Zeitstempel nach dem TSLOOKUPENDLRI-Zeitstempel liegt, wird Extract abgebrochen.

USENATIVEOBJSUPPORT NOUSENATIVEOBJSUPPORT

Gültig für Extract im integrierten Capture-Modus für Oracle.

Integrated Capture fügt eine Redo-basierte Erfassung für die Datentypen "User Defined Type" (UDT) und "ANYDATA" hinzu. Er ist standardmäßig aktiviert und kann nur aktiviert werden, wenn die Quelldatenbankversion 12.1.0.1 oder höher und die Kompatibilität der Quelldatenbank 12.0.0.0.0 oder höher ist. Replicat von Oracle GoldenGate Release 12.1.2.1.0 muss verwendet werden. Um Native Support verwenden zu können, müssen alle Oracle AI Database- und Oracle GoldenGate-Instanzen Release 12.1.0.1 oder höher sein, um kompatibel zu sein.

Wenn der Redo-basierte Capture-Prozess aktiviert ist, ein benutzerdefiniertes Feld jedoch ein nicht unterstütztes Attribut enthält, versucht der integrierte Capture-Prozess, das benutzerdefinierte Feld mithilfe des Abrufs zu erfassen. Einschränkungen der Unterstützung für Capture-Prozesse finden Sie unter XML-Datentypen. Wenn Sie Objekttabellen mit einer CREATE TABLE AS SELECT-(CTAS-)Anweisung erstellen, muss Integrated Capture so konfiguriert werden, dass DML aus dem CTAS-Vorgang erfasst wird, damit Objekttabellen vollständig unterstützt werden. Informationen zu CTAS finden Sie unter How Oracle GoldenGate Handles Derived Object Names in der Dokumentation zu Oracle GoldenGate Microservices

Der Standardwert ist USENATIVEOBJSUPPORT, sofern unterstützt.

Aktivieren Sie den Parameter TRANLOGOPTIONS NOUSENATIVEOBJSUPPORT in der Oracle Extract-Parameterdatei, um die UDT-Daten als XML-Daten in der Traildatei zu erfassen. Diese Daten können dann auf jede Zielspalte angewendet werden, die XML-Daten wie CLOB/TEXT/CHAR/VARCHAR usw. akzeptiert.

USE_ROOT_CONTAINER_TIMEZONE

Gültig nur für den integrierten Extrakt von Oracle.

Dieser Parameter gilt für eine CDB-Umgebung. Jede PDB in einer CDB kann eine andere Datenbankzeitzone verwenden. Wenn die Datenbank-Zeitzone verfügbar ist, versucht Extract, die Zeitzone einer PDB aus dem integrierten Dictionary abzurufen. Für die Zeitzonenextraktion ist ein Patch in der Mining-Datenbank erforderlich. Wenn der Patch nicht verfügbar ist, sendet Extract eine Abfrage an die PDB, um die Zeitzone abzurufen. Wenn der Datenbankpatch oder eine Verbindung zur PDB nicht verfügbar ist und dieser Parameter angegeben ist, geht Extract davon aus, dass die PDB-Datenbank-Zeitzone mit der Zeitzone der Root-Containerdatenbank identisch ist.

VERSIONCHECK DYNAMIC IMMEDIATE

Dies gilt für den SQL-Server.

Verwenden Sie diese Option, wenn Extract CDC-Objektversionen allgemein gespeicherter Prozeduren wie OracleCDCExtract und OracleGGCreateProcs beim Start validieren soll.

DYNAMIC (Standard) identifiziert die CDC-Objektversionen der Tabelle, die in der Parameterdatei einmal pro Tabelle angegeben werden, während Datensätze verarbeitet werden.

IMMEDIATE identifiziert Probleme mit CDC-Objektversionen im Voraus, anstatt während Datensätze verarbeitet werden. Datenbanken mit einer großen Anzahl von Tabellen, die für Capture konfiguriert sind, erfordern eine längere Startvalidierung.

WARNCREATEASSELECT

Gültig für Extract für MySQL.

Der DDL-Vorgang CREATE TABLE AS SELECT wird nicht unterstützt, und Oracle GoldenGate Extract für MySQL wird abgebrochen, wenn er auf diese DDL trifft. Ein Fehler wie der Folgende tritt auf, wenn Extract zum ersten Mal abgebrochen wird:

DDL statement "CREATE TABLE AS SELECT" is detected for table <table-name> at binary log
number <binlog number> and offset <binlog offset>. The DDL operation "CREATE TABLE AS SELECT"
is not supported. Execute all 'CREATE TABLE AS SELECT' DDL operations manually to the target
database and start Extract by adding Extract parameter TRANLOGOPTIONS WARNCREATEASSELECT. Once
Extract gets past the 'CREATE TABLE AS SELECT' operation, restart Extract after disabling the
parameter TRANLOGOPTIONS WARNCREATEASSELECT.

Wenn Sie die Einstellung TRANLOGOPTIONS WARNCREATEASSELECT in der Extract-Datei <parameter> verwenden, wird Extract fortgesetzt, nachdem die folgende Warnmeldung in der Extract-Berichtsdatei ausgegeben wurde:

DDL statement 'CREATE TABLE AS SELECT' is detected for table <table-name> at binary
log number <binlog number> and offset <binlog offset>. The DDL operation 'CREATE TABLE AS SELECT' is not supported.
The DDL and the associated DMLs are ignored.