TRANLOGOPTIONS

Valido per

Extract

Descrizione

Utilizzare il parametro TRANLOGOPTIONS per controllare il modo in cui Extract interagisce con il log delle transazioni o con l'API che passa i dati delle transazioni, a seconda del database o della modalità di acquisizione. È possibile utilizzare più istruzioni TRANLOGOPTIONS nello stesso file di parametri oppure specificare più opzioni nella stessa istruzione TRANLOGOPTIONS se le opzioni specificate le consentono.

Utilizzare una determinata opzione TRANLOGOPTIONS solo per il database o i database a cui è destinata.

Predefinito

Nessuno

Sintassi

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]

Valido per MySQL

Utilizzare ALLOW_BINLOG_ROW_METADATA_MINIMAL nel file dei parametri di estrazione per continuare a utilizzare la variabile BINLOG_ROW_METADATA di MySQL Server impostata su MINIMAL.

La variabile BINLOG_ROW_METADATA di MySQL Server non supporta funzioni quali la replica TRACKSCHEMACHANGES e DDL. Per utilizzare queste funzioni, impostare BINLOG_ROW_METADATA su Full all'interno del file di configurazione del server MySQL. Se queste funzioni non sono necessarie, continuare a utilizzare MINIMAL con il parametro ALLOW_BINLOG_ROW_METADATA_MINIMAL.

ALWAYSONREADONLYROUTING

Valido per SQL Server

Il parametro ALWAYSONREADONLYROUTING consente al server Extract per SQL di instradare la relativa elaborazione di sola lettura a un secondario con intento di lettura disponibile quando è connesso a un listener del gruppo di disponibilità Sempre attivo.

ALTLOGDEST <path | REMOTE>

Valido per MySQL.

Specifica la posizione del file di indice del log MySQL. Extract cerca i file di log in questa posizione anziché la posizione predefinita del database. ALTLOGDEST può essere utilizzato quando la configurazione del database non include il nome del percorso completo dei log o quando sono presenti più installazioni MySQL sul computer. Extract legge il file di indice di log per trovare il file di log binario che deve leggere. Quando si utilizza ALTLOGDEST, Extract presume che i log e l'indice si trovino nella stessa posizione.

Fornire il nome del percorso completo alla directory.

In Windows, racchiudere il percorso tra virgolette doppie se il percorso contiene spazi, ad esempio nell'esempio seguente.

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

Sul sistema Linux:

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

Quando si esegue l'acquisizione in un database MySQL remoto, utilizzare l'opzione REMOTE anziché il percorso del file di indice. Inoltre, se ALTLOGDEST non viene specificato, il sistema presume che l'opzione sia REMOTE.

Dall'acquisizione remota, specificare quanto segue nel file dei parametri Extract.

TRANLOGOPTIONS ALTLOGDEST REMOTE

Per ulteriori informazioni sull'uso dell'opzione REMOTE, vedere Configura proprietà di log.

ASYNCTRANSPROCESSING <buffer_size>

Valido per Extract in modalità di acquisizione integrata per Oracle.

Controlla se l'acquisizione integrata viene eseguita in modalità di elaborazione asincrona o sincrona e controlla la dimensione del buffer quando Extract è in modalità asincrona. Il minimo è 1 e il massimo è 1024; il valore predefinito è 300.

ASYNCTRANSPROCESSING <buffer_size>

In modalità di elaborazione <transaction> asincrona, ci sono due thread di controllo:

• Un thread raggruppa i record di modifica logica (LCR) nelle transazioni, filtra a livello di oggetto ed esegue l'elaborazione parziale del rollback,

• L'altro thread formatta le transazioni sottoposte a commit, esegue le trasformazioni specificate dall'utente e scrive nel file trail.

Il buffer delle transazioni è il buffer tra questi due thread e viene utilizzato per trasferire il lavoro da un thread all'altro. La dimensione predefinita del buffer delle transazioni è pari a 300 transazioni di cui è stato eseguito il commit, ma viene adeguata verso il basso dal gestore della memoria di Oracle GoldenGate se la memoria cache è vicina all'esaurimento.

NOASYNCTRANSPROCESSING

Disabilita l'elaborazione asincrona e causa il funzionamento di Extract in modalità sincrona. In questa modalità, un thread esegue tutto il lavoro di acquisizione.

BUFSIZE <size>

Valido per Db2 LUW e Db2 z/OS. Valido per Db2 per i da Oracle GoldenGate 19c e versioni successive. Valido per il database Oracle AI da Oracle GoldenGate 21c e versioni successive.

Controlla la dimensione massima, in byte, dei buffer allocati per contenere i dati letti dal log delle transazioni.

Valori elevati aumentano la velocità di acquisizione, ma fanno sì che Extract consumi più memoria. I valori bassi riducono l'uso della memoria, ma aumentano l'I/O perché Extract deve memorizzare dati che superano la dimensione della cache su disco.

Per Oracle AI Database, la dimensione dei record dell'operazione DDL è limitata dalla dimensione interna del buffer di acquisizione dei record di Oracle GoldenGate. La dimensione DDL può essere fino al limite della dimensione di Oracle RDBMS. Sebbene il database Oracle 21c consenta la creazione di DDL con dimensioni superiori a 10 MB, la dimensione massima del buffer di acquisizione dei record interni è limitata a 10 MB.

Il buffer <default> <size> è determinato dall'origine dei redo data. Di seguito sono riportati gli intervalli validi e le dimensioni <default>, in byte:

Db2 LUW:

• Minimo: 8,192

• Massima: 10,000,000

• Predefinito: 204,800

• I valori precedenti devono essere in multipli della dimensione della pagina 4096. Extract verrà troncato a un multiplo se un determinato valore non soddisfa questo requisito.

Db2 z/OS e Db2 per i:

• Minimo: 36KB (36864)

• Massimo: 32 MB (33554432)

• Impostazione predefinita: 2MB (2097152)

• I valori precedenti devono essere in multipli della dimensione della pagina 4096. Extract verrà troncato a un multiplo se un determinato valore non soddisfa questo requisito.

• Ogni Extract utilizza un 32bytes fisso di ECSA sul sistema Db2 z/OS a cui si connette Extract. Questo non si applica a Db2 per i.

CHECKPOINTRETENTIONTIME <days>

Valido per Extract in modalità integrata solo per Oracle.

Controlla il numero di giorni durante i quali Extract conserva i checkpoint prima che vengano rimossi. È possibile specificare giorni parziali utilizzando valori decimali. Ad esempio, 8.25 specifica 8 giorni e 6 ore. Quando il checkpoint di un Extract in modalità acquisizione integrata viene rimosso, le informazioni sul dizionario dati di LogMiner per il redo log file archiviato corrispondenti al checkpoint vengono reimpostate sul valore first_scn corrispondente alla prima modifica nel successivo redo log file archiviato. Il valore predefinito è sette giorni e il valore minimo è 0,00001.

DB2APIRETRY <number> di nuovi tentativi

Se Extract riceve un errore dal log Db2 durante la lettura dell'API db2ReadLog(),, per determinati errori verrà eseguito un nuovo tentativo di chiamata all'API. Utilizzare DB2APIRETRY per modificare il numero di nuovi tentativi. Il numero predefinito di tentativi è impostato su 3. Il codice SQL per il quale viene eseguito un nuovo tentativo dell'API è SQLCODE -30108.

DB2ZV11COMPATIBILITYMODE

Valido per Extract per Db2 z/OS.

Quando si utilizza Oracle GoldenGate per l'estrazione da Db2 z/OS versione 11 in alcune modalità di compatibilità, il processo Extract potrebbe non determinare a livello di programmazione la versione effettiva del database e si verifica un errore OGG-00551 o OGG-00804. Utilizzare questa opzione nel file dei parametri Extract per impostare manualmente la versione del database richiesta.

DICTIONARY_CACHE_SIZE <value>

Utilizzare questa opzione per ottimizzare le dimensioni della cache del dizionario da Extract. Il valore predefinito è 5000. Se PERFORMANCEPROFILE è impostato su HIGH, il valore predefinito è 10000.

DLFAILOVER_TIMEOUT <seconds>

Valido per Extract in modalità integrata per Oracle.

Fornisce un timeout configurabile in secondi per consentire la transizione post-ruolo del ripristino del database di standby. Viene utilizzato in combinazione con HANDLEDLFAILOVER per consentire l'avvio di Integrated Extract immediatamente dopo una transizione di ruolo. Alla fine del periodo di timeout, se il database in standby non è ancora disponibile, Extract verrà interrotto.

Il valore predefinito è 300 secondi. È inoltre possibile utilizzare centisecondi o millisecondi.

DISABLESOFTEOFDELAY

Valido per Extract solo in modalità integrata per Oracle e Db2 LUW.

Utilizzare DISABLESOFTEOFDELAY nel file dei parametri Extract per impostare che il tempo di attesa diventi effettivo quando viene segnalato uno stato EOF senza record da restituire.

ENABLE_AUTO_CAPTURE

DISABLE_AUTO_CAPTURE

Impostare questa opzione per abilitare la modalità auto_capture, che consente di fornire i report LCR delle tabelle abilitate per l'acquisizione automatica. Questa opzione può essere impostata quando la versione binaria Oracle del database di origine è 21c o successiva.

EXCLUDETAG {<tag> | + | NULL}]

Valido per Extract. (Solo Oracle)

EXCLUDETAG viene utilizzato per escludere le modifiche precedentemente contrassegnate da Replicat utilizzando l'opzione DBOPTIONS SET TAG o all'interno della sessione di Oracle AI Database utilizzando la procedura DBMS_XSTREAM_ADM.SET_TAG.

Utilizzare EXCLUDETAG tag> per indirizzare il processo Extract a ignorare i singoli record contrassegnati con il redo tag specificato.

Utilizzare EXCLUDETAG NULL per escludere tutte le operazioni non contrassegnate. Questo è il contrario di EXCLUDETAG +.

Utilizzare EXCLUDETAG + per indirizzare il processo Extract a ignorare i singoli record contrassegnati con qualsiasi redo tag.

Esempio

Di seguito sono riportati alcuni esempi di utilizzo degli identificatori di tag con EXCLUDETAG.

Per escludere tutte le modifiche contrassegnate:

TRANLOGOPTIONS EXCLUDETAG +

Per escludere modifiche specifiche contrassegnate:

TRANLOGOPTIONS EXCLUDETAG 00
TRANLOGOPTIONS EXCLUDETAG 0952

Linee guida durante l'uso dei parametri EXCLUDETAG e INCLUDETAG

Durante l'uso dei parametri EXCLUDETAG e INCLUDETAG con i comandi TRANLOGOPTIONS e DDLOPTIONS, tenere presente quanto riportato di seguito.

• Se si specifica TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG e non si specifica DDLOPTIONS EXCLUDETAG/INCLUDETAG, i parametri TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG vengono applicati sia alle operazioni DML che a quelle DDL.

• Se vengono specificate le opzioni TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG e vengono specificati anche DDLOPTIONS EXCLUDETAG/INCLUDETAG, TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG si applica alle operazioni DML e DDLOPTIONS EXCLUDETAG/INCLUDETAG si applica alle operazioni DDL.

• Se il valore TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG non viene specificato e il valore DDLOPTIONS EXCLUDETAG/INCLUDETAG viene specificato, il valore DDLOPTIONS EXCLUDETAG/INCLUDETAG viene applicato alle operazioni DDL e non viene applicato alcun filtro tag per le operazioni DML.

• Se TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG non viene specificato e anche DDLOPTIONS EXCLUDETAG/INCLUDETAG non viene specificato, è applicabile l'opzione predefinita DDLOPTIONS EXCLUDETAG +, che esclude tutte le operazioni DDL contrassegnate.

• Per DDLOPTIONS quando si specificano sia EXCLUDETAG che INCLUDETAG, è necessario che venga prima EXCLUDETAG.

EXCLUDETRANS <transaction>

Valido per Integrated Extract per Oracle.

Specifica il nome della transazione dell'utente del database Replicat o di qualsiasi altro utente in modo che tali transazioni non vengano acquisite da Extract. Utilizzare per l'elaborazione bidirezionale per impedire il loop dei dati tra i database.

Per ulteriori informazioni sulla sincronizzazione bidirezionale, vedere Configuring Bidirectional Replication in Oracle GoldenGate Microservices Documentation.

EXCLUDEUSER <user>

Valido per Db2 LUW, Db2 per z/OS, Db2 per i, Oracle e Sybase.

Specifica il nome dell'utente del database Replicat o di qualsiasi altro utente da utilizzare come filtro. In genere, questa opzione viene utilizzata per identificare le transazioni Replicat in una configurazione di elaborazione bidirezionale o a catena, al fine di escluderle o acquisirle. Tuttavia, può essere utilizzato per identificare le transazioni di qualsiasi altro utente, ad esempio quelle di un'applicazione aziendale specifica.

È possibile utilizzare EXCLUDEUSER e EXCLUDEUSERID nello stesso file di parametri. Non utilizzare caratteri jolly in entrambi i parametri.

Il nome utente deve essere valido. Oracle GoldenGate esegue una query sul database per ottenere l'utente associato ID e riporta l'identificativo numerico al nome utente. Per questo motivo, se l'utente specificato viene eliminato e ricreato mentre la risoluzione del nome è impostata sul valore predefinito DYNAMICRESOLUTION, EXCLUDEUSER rimane valido. Se la stessa transazione viene eseguita quando la risoluzione dei nomi è impostata su NODYNAMICRESOLUTION, EXCLUDEUSER diventa non valido e Extract deve essere arrestato e quindi iniziare a rendere effettivo EXCLUDEUSER, vedere DYNAMICRESOLUTION \| NODYNAMICRESOLUTION.

• Db2 linee guida z/OS: In Db2 per z/OS, l'utente è sempre l'autorizzazione primaria ID della transazione, che è in genere quella dell'utente RACF originale che ha effettuato l'accesso, ma potrebbe anche essere un'autorizzazione diversa ID se modificata da un processore di transazione o da Db2 esce.

• Linee guida Oracle: per un Oracle AI Database è possibile utilizzare più istruzioni EXCLUDEUSER. Tutti gli utenti specificati vengono considerati uguali all'utente Replicat.

Esempio

L'esempio Oracle riportato di seguito filtra per due utenti (uno per nome e uno per utente ID). Le transazioni generate da questi utenti verranno gestite utilizzando tag di filtro e verrà specificata una nuova dimensione del buffer delle transazioni.

TRANLOGOPTIONS EXCLUDEUSER ggsrep, EXCLUDEUSERID 90, BUFSIZE 100000

Per utilizzare EXCLUDEUSER con multi-tenant, è necessario specificare PDB.USERNAME. L'esempio seguente esclude qualsiasi operazione DML eseguita da PDBXYZ.SCOTT:

TRANLOGOPTIONS EXCLUDEUSER PDBXYZ.SCOTT

EXCLUDEUSERID <Database_uid>

Valido per Extract per Oracle.

Specifica l'utente del database ID (uid) dell'utente del database Replicat o di qualsiasi altro utente da utilizzare come filtro. Questo parametro non è valido per le estrazioni multi-tenant. Utilizzare invece l'applicazione di tag e EXCLUDETAG.

L'uso è uguale a quello di EXCLUDEUSER.

<Oracle_uid> è un numero intero non negativo con un valore massimo di 2147483638. Esistono diverse viste di sistema su cui è possibile eseguire query per ottenere l'utente ID. La più semplice è la vista ALL_USERS. Oracle GoldenGate non convalida l'utente ID. Se l'utente associato all'utente specificato ID viene eliminato e ricreato, viene assegnato un nuovo utente ID; pertanto, EXCLUDEUSERID non è più valido per tale utente.

FAILOVERTARGETDESTID <n>

Valido per Extract per Oracle.

Quando si utilizzano i processi Extract di Oracle GoldenGate in una configurazione Oracle Data Guard, il processo Extract GoldenGate deve rimanere indietro rispetto al redo applicato al database di standby Oracle Data Guard. Il parametro FAILOVERTARGETDESTID viene utilizzato per identificare il parametro di inizializzazione LOG_ARCHIVE_DEST_n che punta allo standby, ovvero la destinazione di failover in cui Extract deve rimanere indietro. Questo parametro viene utilizzato in combinazione con HANDLEDLFAILOVER per controllare se Extract limiterà la scrittura dei dati di trail in base all'avanzamento dell'applicazione del database di standby Oracle Data Guard. Tenere presente che FAILOVERTARGETDESTID non è necessario se per la configurazione Data Guard è abilitato Fast Start Failover (FSFO). Il valore minimo è 0, il massimo è 32 e il valore predefinito è 0.

Esempio

Per determinare il valore appropriato per il parametro Extract TRANLOGOPTIONS FAILOVERTARGETDESTID, connettersi al database da cui Extract sta estraendo i dati ed eseguire il comando seguente.

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)

Il parametro Extract TRANLOGOPTIONS FAILOVERTARGETDESTID verrà impostato su 2 perché Oracle GoldenGate del database di standby deve rimanere indietro. La prima voce (log_archive_dest_1) riguarda i log dell'archivio locale per quel database, mentre la seconda riguarda il database in standby.

Verrà impostato su 2 perché Oracle GoldenGate, il database in standby, dovrebbe rimanere indietro. La prima voce (log_archive_dest_1) riguarda i log dell'archivio locale per quel database, mentre la seconda riguarda il database in standby.

FETCHPARTIALJSON

Valido per Extract per MySQL

Utilizzare questa opzione nel file dei parametri Extract per recuperare direttamente i dati dalla tabella, se sono presenti aggiornamenti parziali alle colonne dei tipi di dati JSON di una tabella. Nota: l'elaborazione degli aggiornamenti dei dati della colonna JSON dipende dal valore della variabile del server MySQL, binlog_row_value_options, il cui valore deve essere impostato come PARTIAL_JSON e il file dei parametri Extract include il parametro FETCHPARTIALJSON.

FETCHPARTIALLOB

Valido per Extract in modalità di acquisizione integrata per Oracle.

Utilizzare questa opzione quando si esegue la replica in una destinazione eterogenea o in altre condizioni in cui è richiesta l'immagine LOB completa. Consente a Extract di recuperare l'oggetto LOB completo invece di utilizzare l'oggetto di modifica parziale dal redo record. Per impostazione predefinita, il server di logmining del database invia Extract un LOB intero o parziale, a seconda che sia stato aggiornato tutto o parte del LOB di origine. Per garantire lo snapshot corretto di LOB, la funzione Oracle Flashback deve essere abilitata per la tabella ed Extract deve essere configurato per utilizzarla. Il parametro Extract FETCHOPTIONS controlla il recupero e deve essere impostato su USESNAPSHOT (impostazione predefinita in assenza di NOUSESNAPSHOT). Senza uno snapshot di flashback, Extract recupera il file LOB dalla tabella, che potrebbe essere un'immagine diversa dal momento in cui è stato generato il redo record.

FETCHPARTIALXML

Valido per Extract in modalità di acquisizione integrata Oracle.

Utilizzare questa opzione quando si esegue la replica in una destinazione eterogenea o in altre condizioni in cui è richiesta l'immagine LOB completa. In questo modo Extract recupera il documento XML completo invece di utilizzare l'immagine di modifica parziale dal redo record. Per impostazione predefinita, il server di logmining del database invia a Extract un documento XML intero o parziale, a seconda che sia stato aggiornato tutto o parte del documento XML di origine. Per garantire lo snapshot corretto di XML, la funzione Oracle Flashback deve essere abilitata per la tabella ed Extract deve essere configurato per utilizzarla. Il parametro Extract FETCHOPTIONS controlla il recupero e deve essere impostato su USESNAPSHOT (impostazione predefinita in assenza di NOUSESNAPSHOT). Senza uno snapshot di flashback, Extract recupera il documento XML dalla tabella, che potrebbe essere un'immagine diversa dal momento in cui è stato generato il redo record.

EXCLUDEFILTERTABLE <table>

Valido per Extract per i server MySQL, PostgreSQL e SQL.

Utilizzare questa opzione per identificare una transazione di origine per l'applicazione di filtri. Se una transazione di origine include operazioni per il valore EXCLUDEFILTERTABLE specificato, tale transazione viene identificata come transazione replicata. Il filtro delle transazioni si basa sui tag.

Quando Replicat utilizza una tabella di checkpoint, scrive un record di recupero nella tabella di checkpoint alla fine di ogni transazione applicata. Poiché tutte le transazioni applicate da Replicat contengono un aggiornamento alla tabella dei checkpoint, Extract ignora l'intera transazione applicata da Replicat, il che impedisce il loop dei dati. Per il server PostgreSQL e SQL, assicurarsi che sia stato aggiunto TRANDATA per la tabella dei checkpoint.

Se si utilizza un Replicat parallelo in una replica bidirezionale, mediante l'opzione TRANLOGOPTIONS EXCLUDEFILTERTABLE sono supportate più tabelle filtro. Più tabelle di filtro consentono di specificare più volte TRANLOGOPTIONS EXCLUDEFILTERTABLE con nomi di tabella o caratteri jolly diversi.

È possibile includere una o più voci TRANLOGOPTIONS EXCLUDEFILTERTABLE nel file dei parametri Extract. Nell'esempio seguente, nel file dei parametri Extract sono incluse più voci TRANLOGOPTIONS EXCLUDEFILTERTABLE con nomi di oggetto espliciti e caratteri jolly.

TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt2
TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt_RABC_*

Per informazioni sulla creazione di una tabella di checkpoint, vedere Aggiungere un'estrazione primaria. Per specificare correttamente i nomi degli oggetti e i caratteri jolly, vedere Utilizzo dei caratteri jolly negli argomenti dei comandi nella documentazione dei microservizi di Oracle GoldenGate.

FORCEFETCHLOB

Valido per Extract per Oracle.

Sovrascrive il comportamento predefinito dell'acquisizione dei dati LOB dal redo log. Fa sì che i LOB vengano recuperati dal database per impostazione predefinita.

Attenzione: se un valore viene eliminato prima del recupero, Extract scrive un valore nullo nel trail. Se un valore viene aggiornato prima di un recupero, Extract scrive il valore aggiornato. Per evitare queste imprecisioni, cerca di mantenere bassa la latenza di Extract. La documentazione di Oracle GoldenGate fornisce le linee guida per l'ottimizzazione delle prestazioni dei processi. Vedere anche Interazioni tra i recuperi da una tabella e DDL per istruzioni sull'impostazione delle opzioni di recupero.

GETCTASDML | NOGETCTASDML

Abilita la funzionalità Crea tabella come selezione (CTAS). Quando GETCTASDML è abilitato, i DML CTAS vengono inviati da LogMiner e replicati sulla destinazione. Per impostazione predefinita, questa opzione è abilitata. L'esecuzione di CTAS DDL viene eliminata sulla destinazione.

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

Valido per Extract per Oracle

STANDBY_WARNING e STANDBY_ABEND validi per Oracle Database 21c e versioni successive.

Controlla se Extract limiterà la scrittura dei dati di trail in base all'avanzamento dell'applicazione del database di standby Fast Start Failover. È destinato a mantenere Extract in un punto sicuro dietro qualsiasi failover di perdita di dati.

Quando si utilizza questa opzione per la perdita di dati in una configurazione Data Guard senza Fast Start Failover (FSFO), è necessario impostare il parametro Extract FAILOVERTARGETDESTID per identificare la destinazione del log di archivio ID in cui è possibile connettere lo standby.

Extract si trova in stato di stallo quando esegue le query Extract, il database di standby applica le informazioni SCN (SELECT applied_scn FROM v$archive_dest where dest_id=n) e questo SCN è minore di Extract che elabora LCR SCN. In questo caso, Extract non elaborerà l'LCR e attende che applied_scn diventi maggiore o uguale all'SCN LCR di elaborazione Extract.

STANDBY_WARNING <value>

Il periodo di tempo prima che un messaggio di avvertenza venga scritto nel file del report di estrazione, se Extract è in stallo. L'impostazione predefinita è 60 secondi.

STANDBY_ABEND <value>

Il periodo di tempo prima dell'interruzione dell'estrazione, se l'estrazione è bloccata. Il valore predefinito è 30 minuti.

Se vengono specificati sia STANDBY_WARNING che STANDBY_ABEND, STANDBY_ABEND deve essere sempre maggiore di STANDBY_WARNING.

IFILOCKSECONDS <seconds>

Valido per Db2 z/OS

Imposta l'intervallo in <seconds>, per il quale Extract contiene i lock impliciti detenuti nel database dalle chiamate a IFCID

1. I lock possono influire sulla capacità di eseguire determinate operazioni del database, ad esempio REORGS. Il valore predefinito è 20 secondi, con valori minimi e massimi rispettivamente di 1 secondo e 300 secondi. Nota: se il parametro IFILOCKSECONDS è impostato per una durata maggiore, altre operazioni del database, ad esempio REORGS, possono essere interessate a causa del blocco interno causato dalle chiamate Extract IFI. Pertanto, se si verifica un conflitto di lock in relazione a un Extract, impostare il timeout di lock per l'operazione su una durata maggiore del valore del parametro IFILOCKSECONDS oppure arrestare Extract.

IGNOREDATACAPTURECHANGES

NOIGNOREDATACAPTURECHANGES

Valido per Db2 LUW

Controlla se Extract acquisisce le tabelle per le quali non è impostato DATA CAPTURE CHANGES. IGNOREDATACAPTURECHANGES ignora le tabelle per le quali DATA CAPTURE CHANGES non è impostato. Utilizzare se le tabelle sono state specificate con un carattere jolly per garantire che l'elaborazione continui per le tabelle per le quali è stata impostata l'acquisizione delle modifiche. Viene inviata un'avvertenza al log degli errori per le tabelle saltate. L'impostazione predefinita è NOIGNOREDATACAPTURECHANGES.

INCLUDEREGIONID

INCLUDEREGIONIDWITHOFFSET

Valido per Extract per Oracle.

Queste opzioni supportano il tipo di dati Oracle TIMESTAMP WITH TIME ZONE specificato come TZR (che rappresenta l'area del fuso orario, ad esempio US/Pacific). Per impostazione predefinita, Extract viene interrotto su TIMESTAMP WITH TIME ZONE se include un'area del fuso orario. Queste opzioni consentono di gestire questo indicatore orario in base al tipo di database di destinazione.

Quando Extract rileva che il tipo di dati di origine è TIMESTAMP e che esiste un token di mapping ID dell'area, Replicat applica l'indicatore orario come indicato di seguito.

• Se la versione Oracle di destinazione lo supporta, viene applicato un valore TIMESTAMP WITH TIME ZONE con TZR.

• Un indicatore orario con offset UTC viene applicato a un database eterogeneo o a una versione precedente di Oracle che non supporta TIMESTAMP WITH TIME ZONE con TZR.

INCLUDEREGIONID

Valido per Integrated Extract per Oracle.

INCLUDEREGIONID non è più valido per Oracle GoldenGate 19c (19.1.0). Da Oracle GoldenGate 19c (19.1.0) in poi, TIMESTAMP WITH TIME ZONE con dati dell'area ID è incluso per impostazione predefinita, incluso il caricamento iniziale.

Da utilizzare quando si esegue la replica da un'origine Oracle a una destinazione Oracle della stessa versione o versione successiva. Quando si specifica INCLUDEREGIONID, Extract aggiunge un indice di colonna e il valore TMZ a due byte come token di mapping del fuso orario e lo restituisce al trail nel formato UTC di YYYY-MM-DD HH:MI.SS.FFFFFF +00:00.

INCLUDEREGIONIDWITHOFFSET

Valido per Integrated Extract per Oracle.

Utilizzare questa opzione per convertire l'area ID in un valore di offset di ore e minuti (+06:00 come esempio). Se l'opzione non viene specificata, l'indicatore orario viene sempre scritto nel file trail in UTC e il fuso orario è sempre +00:00.

Se è necessario conservare il valore del fuso orario in ore e minuti anziché in UTC, è possibile utilizzare questa opzione.

Nei seguenti casi, l'opzione è forzata ad accendersi per conservare il TIMEZONE <value> in ore e minuti <offset>:

• Vecchio formato di file trail perché Replicat non supporta l'area ID.

• I formati XML, TEXT e SQL non supportano l'area ID.

INCLUDETAG {<tag>| +}

Valido per Extract. (Solo Oracle)

Utilizzare INCLUDETAG <tag> per includere specifiche operazioni DDL con tag nei file trail. Il valore del tag può contenere fino a 2000 cifre esadecimali (0-9 A-F).

Per evitare conflitti, non utilizzare INCLUDETAG insieme a EXCLUDETAG.

Esempio: tranlogoptions includetag 00

LOB_CHUNK_SIZE

Valido per SQL Server, PostgreSQL.

Se hai enormi dimensioni di dati LOB, allora puoi regolare LOB_CHUNK_SIZE dal valore predefinito di 4000 byte, a un valore superiore fino a 65535 byte, in modo che la dimensione di recupero sia aumentata, riducendo i viaggi necessari per recuperare l'intero LOB

Esempio: TRANLOGOPTIONS LOB_CHUNK_SIZE 8000

(PostgreSQL) Specifica la dimensione del chunk per i dati LOB (CLOB/BLOB) che verranno utilizzati per eseguire il push in COM. L'unità è in byte. I valori minimi e massimi di lob_chunk_size sono compresi tra 4000 e 65535 byte.

LOGREADTIMEOUT

Valido per Extract per PostgreSQL versione 12 e successive.

Abilita o disabilita l'opzione wal_sender_timeout per il processo del mittente WAL.

L'opzione value può essere solo un valore intero, con 60000 millisecondi come valore predefinito. Il valore massimo è 2147483647 millisecondi e il valore minimo è 0 millisecondi.

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

Valido per Extract in modalità di acquisizione integrata per Oracle Standard o Enterprise Edition 12c o versioni successive.

Passa i parametri e i valori al server di logmining di Oracle AI Database quando Extract è in modalità di acquisizione integrata. L'input deve essere in formato <parameter value>, come in:

TRANLOGOPTIONS INTEGRATEDPARAMS (downsream_real_time_mine Y)

Le specifiche dei parametri valide e i relativi valori sono i seguenti:

max_sga_size

Specifica la quantità di memoria SGA utilizzata dal server di logmining del database. Può essere un numero intero positivo in megabyte. L'impostazione predefinita è 1 GB se streams_pool_size è maggiore di 1 GB, altrimenti è il 75% di streams_pool_size.

parallelism

Specifica il numero di processi che supportano il server di logmining del database. Può essere un numero intero positivo. Il valore predefinito è 2.

downstream_real_time_mine

Specifica se l'acquisizione integrata estrae un database di mining a valle in modalità in tempo reale. Un valore Y specifica l'acquisizione in tempo reale e richiede la configurazione dei redo log in standby nel database di mining a valle. Il valore N specifica l'acquisizione dai log archiviati spediti al database di mining a valle. L'impostazione predefinita è N.

enable_procedural_replication

Abilita la replica procedurale all'acquisizione. La replica delle procedure è disabilitata per impostazione predefinita. Il valore Y abilita la replica procedurale. Quando questa opzione è attivata per un Extract, rimane attiva. Impossibile ripristinare il valore del parametro.

MANAGESECONDARYTRUNCATIONPOINT

NOMANAGESECONDARYTRUNCATIONPOINT

Valido per PostgreSQL.

MANAGESECONDARYTRUNCATIONPOINT è l'impostazione predefinita e controlla il valore restart_lsn dello slot di replica per l'estrazione specifica.

NOMANAGESECONDARYTRUNCATIONPOINT non sposta lo slot di replica di Extract ed è in genere utilizzato solo per scopi di sviluppo e test in cui un Extract deve essere riposizionato in un LSN precedente dal LSN di recupero dell'Estratto. Se utilizzato, il log write-ahead PostgreSQL continuerà ad aumentare e a consumare spazio su disco.

MAXAUTOCMTTRANSSIZE (<range>, <default>)

Valido solo per DB2 per i

Fornisce l'intervallo della dimensione massima della transazione con commit automatico.

Db2 per i record con commit automatico i (la scrittura contabile ha CCID uguale a 0) non dispone di un record di commit nel giornale e pertanto Oracle GoldenGate deve creare una transazione implicita per includere questi record nel trail. L'impostazione predefinita consente di includere un singolo record in una singola transazione, che mantiene l'accuratezza del tempo di I/O indicato per ogni record perché il tempo di I/O è basato sul commit per la transazione.

Questo parametro imposta il numero massimo di record che verranno inclusi in una transazione creata in modo implicito, ma il numero potrebbe essere inferiore se qualsiasi altro tipo di scrittura viene visualizzato nel giornale prima del raggiungimento del valore massimo. Questa risposta evita problemi di sovrapposizione per i checkpoint nei record appartenenti a record con commit esplicito.

L'impostazione del valore per questo parametro su 1 (defulat) fornirà un tempo di I/O accurato per ogni record nel trail per i record sottoposti a commit automatico (con CCID 0 nella scrittura contabile), a spese potenziali del throughput per l'estrazione. Il valore di questo parametro influisce anche sulla dimensione potenziale massima di una transazione memorizzata nella cache per questi record in memoria. Impostandolo su un valore inferiore, la memoria della transazione risulta inferiore se Extract è in grado di memorizzare il numero massimo di voci per transazione implicita. Per definizione, può esistere solo una di queste transazioni implicite in memoria in un dato momento, poiché qualsiasi altro record di transazione causerà un commit immediato sulla traccia di qualsiasi record in una transazione implicita già in memoria.

L'intervallo predefinito è compreso tra 1 e 10000 e il valore predefinito è 1.

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

Valido per Oracle GoldenGate Extract per Oracle.

Specifica le credenziali di login per consentire a Extract di eseguire il login a un database Oracle mining a valle per interagire con il server di logmining. Può essere utilizzato al posto dell'opzione MININGUSERIDALIAS se non si utilizza un'area di memorizzazione delle credenziali Oracle GoldenGate.

Questo utente deve:

• Disporre dei privilegi concessi nel ruolo OGG_CAPTURE e OGG_APPLY per Oracle GoldenGate 26ai e versioni successive. Per Oracle Database 21c, è necessario applicare i privilegi concessi in dbms_goldengate_auth.grant_admin_privilege.

• Eseguire il comando MININGDBLOGIN o MININGDBLOGIN USERIDALIAS e REGISTER EXTRACT o UNREGISTER EXTRACT per il gruppo Extract associato a questo MININGDBLOGIN USERIDALIAS.

• Non essere modificato.

/

Fornisce istruzioni a Oracle GoldenGate per l'uso di un login di sistema operativo per Oracle e non un login di utente di database. Utilizzare questo argomento solo se il database consente l'autenticazione a livello di sistema operativo. L'esclusione dell'autenticazione a livello di database elimina la necessità di aggiornare i file dei parametri di Oracle GoldenGate se le password dell'applicazione cambiano di frequente.

Per utilizzare questa opzione, il nome utente corrispondente deve esistere nel database, in relazione al valore del parametro d'inizializzazione OS_AUTHENT_PREFIX Oracle. Il set di valori con OS_AUTHENT_PREFIX viene concatenato all'inizio del nome account del sistema operativo di un utente e quindi confrontato con il nome del database. Questi due nomi devono corrispondere.

Se OS_AUTHENT_PREFIX è impostato su ' (stringa nulla), il nome utente deve essere creato con IDENTIFIED EXTERNALLY. Ad esempio, se il nome utente OS è ogg, per creare l'utente del database si utilizzerà quanto riportato di seguito.

CREATE USER ogg IDENTIFIED EXTERNALLY;

Se OS_AUTHENT_PREFIX è impostato su OPS$ o su un'altra stringa, il nome <user> deve essere creato nel formato seguente:

<OS_AUTHENT_PREFIX_value><OS_user_name>

Ad esempio, se il nome OS <user> è ogg, si utilizzerà quanto segue per creare il database <user>:

CREATE USER ops$ogg IDENTIFIED BY oggpassword;

<user>

Specifica il nome dell'utente del database di mining o una stringa di connessione SQL*Net.

<password>

Password dell'utente. Utilizzare quando è richiesta l'autenticazione del database per specificare la password per l'utente del database. Se la password è stata cifrata con il comando ENCRYPT PASSWORD, fornire la password cifrata, altrimenti utilizzare la password in chiaro. Se per la password viene fatta distinzione tra maiuscole e minuscole, digitarla nel rispetto di questa regola. Se l'utente ID o la password cambia, la modifica deve essere apportata nei file dei parametri di Oracle GoldenGate, inclusa la nuova cifratura della password, se necessario.

<algorithm>

Specifica la cifratura <algorithm> utilizzata per cifrare <password> con ENCRYPT PASSWORD. Può essere uno dei seguenti:

AES128
AES192
AES256

ENCRYPTKEY {<key_name> | DEFAULT}

Specifica la chiave di cifratura specificata con ENCRYPT PASSWORD.

• ENCRYPTKEY <key_name> specifica il nome logico di una chiave di cifratura creata dall'utente nel file della ricerca ENCKEYS. Utilizzare se è stato utilizzato il comando ENCRYPT PASSWORD con l'opzione KEYNAME <key_name>.

• ENCRYPTKEY DEFAULT indica a Oracle GoldenGate di utilizzare una chiave casuale. Da utilizzare se l'opzione KEYNAME DEFAULT è stata utilizzata con il comando ENCRYPT PASSWORD.

SYSDBA

Specifica che l'utente esegue il login come sysdba.

MININGUSERIDALIAS <alias>

Valido per Extract per Oracle.

Specifica l'alias per le credenziali di login utilizzate da Extract per eseguire il login a un database Oracle mining a valle per interagire con il server di logmining. Può essere utilizzato al posto di MININGUSER se si utilizza un'area di memorizzazione delle credenziali Oracle GoldenGate.

Questo alias deve essere:

• Associata a una credenziale di login utente del database memorizzata nell'area di memorizzazione delle credenziali Oracle GoldenGate locale. Questo utente deve disporre dei privilegi concessi in dbms_goldengate_auth.grant_admin_privilege per Oracle Database 21c e versioni successive e del ruolo OGG_CAPTURE e OGG_APPLY per Oracle AI Database 26ai e versioni successive.

• L'utente che esegue i comandi MININGDBLOGIN o MININGDBLOGINALIAS e REGISTER EXTRACT o UNREGISTER EXTRACT per il gruppo Extract associato a questo MININGUSERIDALIAS.

Questo alias e questo utente non devono essere modificati mentre Extract è in modalità di acquisizione integrata.

MIXEDENDIAN [ON

OFF]

Valido per LUW Db2 con estrazione primaria di Oracle GoldenGate

Oracle GoldenGate Extract for Db2 LUW supporta l'acquisizione cross-endian in cui il database e Oracle GoldenGate sono in esecuzione su server di ordine di byte diversi. Il rilevamento dell'ordine dei byte è automatico per il database Db2 LUW versione 10.5 e successive. Se è necessario disabilitare il rilevamento automatico su Db2 LUW 10.5, è possibile sostituirlo specificando questo parametro. Per la versione 10.1, il parametro deve essere utilizzato nel file dei parametri Extract per l'acquisizione cross-endian. Per impostazione predefinita, il valore è impostato su OFF per la versione 10.1.

Sintassi:

TRANLOGOPTIONS MIXEDENDIAN [ON|OFF]

ON: se questa opzione è impostata, Extract presume che il database e Oracle GoldenGate siano in esecuzione su server con un ordine di byte diverso e che venga eseguita la conversione di storno dei byte necessaria.

OFF: se questa opzione è impostata, Extract presume che il database e Oracle GoldenGate siano in esecuzione su server con lo stesso ordine di byte e che non venga eseguita alcuna conversione di storno dell'ordine di byte.

MANAGECDCCLEANUP

NOMANAGECDCCLENUP

Valido per il server SQL.

MANAGECDCCLEANUP è l'impostazione predefinita e consigliata che indica a Extract di convalidare l'esistenza del job di cleanup CDC di Oracle GoldenGate o del task Rimuovi dati modifica, a seconda dell'architettura e della versione di Oracle GoldenGate.

Per tutte le versioni di Oracle GoldenGate Classic Architecture e per le versioni di Microservizi precedenti a Oracle GoldenGate 21.4, utilizzare il programma ogg_cdc_cleanup_setup.bat/sh per installare il job di cleanup CDC di Oracle GoldenGate e le tabelle e le stored procedure associate.

Per le installazioni di Oracle GoldenGate Microservices 21.4 e versioni successive, creare un task Rimuovi dati di modifica dalla pagina Task della sezione Configurazione del servizio di amministrazione di WebUI. Il task Rimuovi dati modifica crea le stored procedure e le tabelle associate necessarie e gestisce la funzione di rimozione all'interno di Oracle GoldenGate e non tramite il job Agente server SQL.

L'opzione NOMANAGECDCCLEANUP indica a Extract di non verificare l'esistenza del job di cleanup CDC di Oracle GoldenGate o del task Rimuovi dati modifica. Questa opzione non è consigliata per gli ambienti di produzione, ma può essere utilizzata per eseguire il test di un processo Extract senza dover creare il job o il task di cleanup CDC di Oracle GoldenGate.

PERFORMANCEPROFILE HIGH

MEDIUM

LOW_RES

LOW_WORKLOAD

Valido per Extract in modalità di acquisizione integrato.

Per ottimizzare l'acquisizione integrata.

Può essere impostato su HIGH, MEDIUM (impostazione predefinita) o LOW_RES. Consente di ottenere prestazioni migliori raggruppando i parametri che influiscono sulle prestazioni. Una volta impostato il profilo delle prestazioni, questa opzione configura automaticamente i parametri pertinenti per ottenere il throughput e la latenza richiesti.

• L'opzione HIGH consente di elaborare in modo più efficiente carichi di lavoro elevati con un throughput continuo in termini di replica end-to-end. L'opzione HIGH aumenta la dimensione del buffer del file trail a 4 MB e riduce i valori delle opzioni di fine file e flush a 0,1 secondi.

• L'opzione MEDIUM imposta la dimensione del buffer del file trail su 1 MB e i valori per il ritardo di fine file e lo svuotamento su 1 secondo.

• L'opzione LOW_RES è applicabile quando le risorse sono insufficienti ed è stata aggiunta per la distribuzione di memoria o risorse limitate.

• L'opzione LOW_WORKLOAD viene utilizzata con Oracle GoldenGate per gli ambienti Oracle AI Database con un carico di lavoro basso, ma la latenza deve essere in secondi secondari.

Quando l'opzione HIGH è abilitata per il carico di lavoro a bassa e media intensità, aumenta la latenza Extract integrata di diversi secondi. Questo perché l'opzione HIGH aumenta la dimensione del buffer di lettura di Extract a 8 MB. Tuttavia, la regola per svuotare il buffer di lettura dell'estrazione è quando il buffer è pieno o quando non sono presenti record in entrata per una durata di 0,2 secondi. Pertanto, qualsiasi carico di lavoro continuo con velocità di inclusione Extract inferiore a 8 MB comporterà una latenza Extract integrata superiore a 1 secondo. Assicurarsi che se i tassi di inclusione Extract (o i tassi di generazione dei redo in caso di acquisizione del 100% dei redo) sono inferiori al valore specificato, ad esempio ~15 MB/sec per ottenere una latenza di estrazione di circa 0,5 secondi, non utilizzare l'opzione HIGH. Se è richiesta una latenza inferiore al secondo, si consiglia di ridurre di conseguenza la dimensione del buffer. Ad esempio, impostare la dimensione del buffer su un terzo della velocità di generazione dei redo in MB/sec per ottenere una latenza massima di estrazione di circa 0,3 secondi.

QUERYTIMEOUT <seconds>

Valido per il server SQL.

Specifica il tempo di attesa delle query per il server SQL prima di segnalare un messaggio di errore di timeout. Questa opzione richiede un valore intero per rappresentare il numero di secondi. Il valore predefinito del timeout di query è 300 secondi (5 minuti). Il valore minimo è di 0 secondi (timeout infinito). Il massimo è di 2147483645 secondi.

Nell'esempio seguente viene indicato al server SQL di attendere 60 secondi per i risultati prima del timeout.

TRANLOGOPTIONS QUERYTIMEOUT 60

QUERYRETRYCOUNT <seconds>

Valido per Extract per il server SQL e MySQL.

Specifica il numero di tentativi di chiamata alla stored procedure CDC utilizzata da Extract, in caso di timeout del set di risultati.

È possibile specificare QUERYRETRYCOUNT per riprovare più volte. Se tutti i tentativi di nuovo tentativo non riescono, Extract termina con il normale messaggio di errore di timeout della connessione.

Per il server SQL, l'impostazione predefinita è un tentativo di nuovo tentativo, dopo il quale l'impostazione minima del processo abends.The (0) è infinita, il massimo è 1000 e l'impostazione predefinita è 1.

Per MySQL, l'impostazione minima e predefinita è 50 e massima è 1000. Non esiste un valore infinito. Qualsiasi tentativo di impostare QUERYRETRYCOUNT su un valore inferiore al minimo verrà ignorato senza errori o avvisi.

L'esempio seguente fa sì che Extract tenti di chiamare la procedura memorizzata CDC 4 volte:

TRANLOGOPTIONS QUERYRETRYCOUNT 4

L'esempio seguente fa sì che Extract tenti di chiamare la procedura memorizzata CDC 100 volte:

TRANLOGOPTIONS QUERYRETRYCOUNT 100

READQUEUESIZE <size>

Valido per MySQL.

Specifica la dimensione della coda interna, espressa in byte, per i dati della transazione. Può essere aumentato per migliorare le prestazioni. I valori validi vanno da 3 a 1500 numeri interi. Il valore predefinito è 256 byte; iniziare con il valore predefinito e valutare le prestazioni prima di regolare verso l'alto.

REDO_TRANSPORT_LAG_THRESHOLD <seconds>

Valido per l'estrazione integrata in modalità mining a valle.

Esegue il monitoraggio della latenza di rete tra un database di origine e un database di destinazione quando vengono spediti i redo log. Se la latenza supera la soglia specificata, viene visualizzata un'avvertenza nel file di report e viene visualizzato un messaggio di informazioni successivo quando il ritardo scende al livello normale.

Il valore di soglia predefinito è 30 secondi. Il valore di soglia minimo che è possibile specificare è di 15 secondi.

Per ulteriori informazioni, vedere Estrazione a valle.

REDO_TRANSPORT_LAG_TIMEOUT <value>

Valido per l'estrazione integrata in modalità mining a valle.

Il valore fornito come input in questa opzione parametro è il periodo di tempo per il quale Extract attenderà il redo da ogni thread. Se tutti i thread hanno atteso il timeout (in secondi) e non hanno ricevuto alcun redo, Extract verrà interrotto.

REQUIRELONGDATACAPTURECHANGES

NOREQUIRELONGDATACAPTURECHANGES

Valido per Db2 LUW.

Controlla la risposta di Extract quando DATA CAPTURE è impostato su NONE o su CHANGES senza INCLUDE LONGVAR COLUMNS e il file dei parametro include una delle impostazioni di Oracle GoldenGate riportate di seguito che richiedono la presenza di immagini precedenti per alcuni o tutti i valori delle colonna: GETBEFOREUPATES, NOCOMPRESSUPDATES e NOCOMPRESSDELETES. Entrambe queste impostazioni DATA CAPTURE impediscono la registrazione dei valori precedenti per le colonne LONGVAR. Se tali colonne non sono disponibili per Extract, possono influire sull'integrità dei dati di destinazione.

REQUIRELONGDATACAPTURECHANGES

L'estrazione si interrompe con un errore.

NOREQUIRELONGDATACAPTURECHANGES

L'estrazione emette un avviso, ma continua l'elaborazione del record di dati.

REMOTESCHEMA <value>

Valido per l'estrazione Db2 z/OS.

Quando si utilizzano più versioni di Oracle GoldenGate per Db2 z/OS Extract, è necessario creare più versioni dei componenti Extract GoldenGate all'interno di Db2 z/OS con nomi di schema diversi. Il parametro REMOTESCHEMA viene utilizzato per indicare allo schema Extract quale utilizzare.

Per i dettagli, consultare Install Extract Components on Db2 z/OS in Oracle GoldenGate Microservices Documentation.

SOURCE_OS_TIMEZONE <timezone>

Valido per Extract in modalità di acquisizione integrata per Oracle.

Specifica il fuso orario del sistema del database di origine. Il fuso orario di un database viene in genere indicato dal fuso orario predefinito del sistema operativo e può essere sostituito anche impostando la variabile di ambiente TZ all'avvio del database. Specificare questa opzione solo se il database di origine e il processo Extract utilizzano fusi orari di sistema diversi. Ad esempio, in una distribuzione di acquisizione a valle in cui il database di origine e il processo Extract vengono eseguiti su server diversi in fusi orari diversi.

È possibile specificare il valore di questa opzione in un nome di area del fuso orario o in un form di offset UTC ed è necessario utilizzare lo stesso form utilizzato dal database di origine. Ad esempio, se il database di origine utilizza un formato di nome area come America/New_York, è necessario specificare America/New_York, US/Eastern o EST5EDT. In alternativa, se il database di origine utilizza un formato di offset UTC come -05:00, è necessario utilizzare la sintassi (GMT)[+|-]hh[:mm]. Ad esempio, GMT-05:00 o -5.

SKIPUNKNOWNEVENT

Valido per MySQL.

È possibile utilizzare questo parametro nel file dei parametri Extract per abilitare l'eliminazione di qualsiasi evento non gestito o sconosciuto nel log binario MySQL. Se si specifica questo parametro, l'elaborazione di Oracle GoldenGate for MySQL Extract continua senza errori durante la ricerca di un evento non gestito dal processo Extract corrente.

STREAMINGOPTIONS

Valido per PostgreSQL.

Utilizzare questo parametro per fornire i parametri richiesti durante l'avvio della replica. Vedere anche Registra estrazione per PostgreSQL nella documentazione dei microservizi di Oracle GoldenGate.

Ad esempio:

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

SUPPRESSNOOOPUPDATES

Valido per Extract su Oracle AI Database.

È possibile controllare se gli aggiornamenti non operativi vengono filtrati o meno in Integrated Extract. Il valore predefinito non è un'eliminazione.

TRACKSCHEMACHANGES

NOTRACKSCHEMACHANGES

Valido per Db2 z/OS e MySQL

Per Oracle GoldenGate for Db2 z/OS, questo parametro consente a Extract di acquisire le istruzioni DDL a livello di tabella e di conservare una cronologia delle modifiche da utilizzare per elaborare DML quando i record di log fanno riferimento a una versione di tabella precedente alla versione corrente della tabella. Questo in genere avviene prima delle immagini degli aggiornamenti, ma potrebbe essere dopo immagini, inserimenti o eliminazioni se Extract è in esecuzione in una situazione di ritardo dal backlog del log. Quando Extract rileva le operazioni DDL appropriate, annoterà il numero di versione di DDL e aggiornerà la tabella di cronologia DDL con le nuove informazioni. Extract creerà un nuovo record TDR relativo alla modifica del trail. Quando Extract rileva versioni precedenti della tabella nel log, farà riferimento alla cronologia DDL per poter interpretare correttamente DDL per la versione precedente della tabella. La modifica DDL non viene effettivamente replicata e la sincronizzazione di eventuali modifiche alla tabella di origine deve essere ancora eseguita manualmente dall'utente nel database di destinazione.

Quando si immette questo comando, le modifiche a livello di tabella DDL verranno tracciate da Extract e i metadati trail verranno aggiornati, a seconda dei casi. Per utilizzare correttamente TRACKSCHEMACHANGES, i metadati della tabella devono trovarsi in uno stato coerente noto, il che significa che tutte le tabelle che richiedono il tracciamento delle versioni devono essere create e mai modificate o riorganizzate prima di utilizzare TRACKSCHEMACHANGES in modo che nessuna versione precedente della tabella venga visualizzata nel log delle transazioni per le operazioni di aggiornamento o eliminazione. Lo script ddl_update.sh è stato fornito per facilitare la creazione di un set iniziale di record di cronologia DDL per il database.

Per utilizzare l'elaborazione DDL, il database deve essere impostato con una tabella di cronologia che acquisirà le modifiche DDL delle varie versioni di tutte le tabelle nel sistema di database. Inoltre, è necessario abilitare le tabelle di sistema per le modifiche all'acquisizione dei dati. Per creare e gestire la tabella di cronologia, sono disponibili i seguenti script della shell UNIX:

• ddl_create.sh: questo script viene utilizzato per creare la tabella di cronologia DDL. Consente inoltre di modificare l'acquisizione dei dati per le tabelle di sistema riportate di seguito.

  • SYSIBM.SYSTABLES

  • SYSIBM.SYSCOLUMNS

  • SYSIBM.SYSINDEXES

  • SYSIBM.SYSKEYCOLUSE

  Esempio:

  ./ddl_create.sh -f crt_ddl_hist.sql -s OGGSCHEMA

  In questo esempio, il file risultante, crt_ddl_hist.sql deve essere elaborato da un altro programma.

  ./ddl_create.sh -d DB2DSXY -u gguser -p ggpw -s OGGSCHEMA

  Questa operazione chiamerà un Db2 locale per stabilire una connessione remota a un database mainframe e creare immediatamente la tabella di cronologia DDL.

• ddl_remove.sh: questo script viene utilizzato per rimuovere la tabella di cronologia DDL. Le tabelle di sistema, tuttavia, non vengono modificate.

• ddl_update.sh: questo script deve essere eseguito per stabilire un punto iniziale per il tracciamento della versione DDL utilizzando TRACKSCHEMACHANGES. Deve essere eseguito dopo la creazione della tabella di cronologia DDL e non dovrebbe essere necessario eseguire di nuovo a meno che l'estrazione non debba essere riposizionata in modo tale che le versioni della tabella potrebbero non essere presenti nel log delle transazioni. Se si esegue di nuovo ddl_update.sh, verranno aggiunte solo le informazioni per le tabelle non già presenti nella cronologia DDL.

• execsql.sh: questo script non deve essere eseguito direttamente, ma deve essere disponibile per gli altri script di origine. Fornisce funzionalità comuni per l'analisi della riga di comando e l'esecuzione di SQL o la scrittura in un file.

Questi script possono essere utilizzati per creare le tabelle direttamente utilizzando una connessione Db2 o possono essere utilizzati per creare file SQL che possono essere eseguiti in un programma di elaborazione SQL di scelta. I file sono stati controllati per essere compatibili con Db2 remoto e SPUFI.

Di seguito è riportata una descrizione delle opzioni accettate da questi script.

• -h mostra questa Guida all'uso.

• -d dsn specifica il DSN Db2 a cui connettersi.

• -u userid specifica l'utente ID con cui connettersi al database.

• -p password specifica la password con cui connettersi al database.

• -s ggschema specifica il nome dello schema in cui deve essere memorizzata la tabella di cronologia DDL. Questo schema deve essere uguale a GGSCHEMA in GLOBALS.

• -t ddltable specifica il nome della tabella della cronologia DDL. GGS_DDL_HIST è l'impostazione predefinita.

• -f outfile specifica il nome di un file in cui scrivere le istruzioni SQL anziché eseguirle. Se -d, -u, -p deve essere specificato se utilizzato o -f. Attualmente -t non deve essere utilizzato. È necessario utilizzare -f se nell'host remoto è disponibile solo il comando db2cli poiché db2cli non può eseguire le istruzioni SQL generate.

Per Oracle GoldenGate for MySQL, la replica DDL è supportata con acquisizione e consegna. Quando la replica DDL è abilitata, Extract rileva le operazioni DDL nella tabella del database di origine, elabora l'istruzione DDL, aggiorna i metadati della tabella e scrive l'istruzione e i metadati DDL nel file trail. Replicat applica queste operazioni DDL nel database di destinazione MySQL e seleziona anche la nuova versione dei metadati dal trail ed elabora le operazioni DML successive. L'intero processo è trasparente e non sono coinvolti tempi di inattività, ma questo è possibile solo per lo scenario simile come (da MySQL a MySQL).

Il parametro TRACKSCHEMACHANGES consente di acquisire le modifiche ai metadati della tabella dopo l'operazione DDL nelle tabelle di origine in modo che Capture sia in grado di elaborare le operazioni DML successive senza tempi di inattività. Quando TRACKSCHEMACHANGES è abilitato, Capture scrive un nuovo record TDR nel trail contenente i nuovi metadati in ogni operazione DDL seguita dai dati corrispondenti. Capture non elabora e scrive l'istruzione DDL nel file trail, pertanto le modifiche DDL non vengono effettivamente replicate nel database di destinazione. La sincronizzazione di qualsiasi modifica DDL corrispondente all'origine deve essere eseguita manualmente nel database di destinazione. Il vantaggio dell'uso di questa funzione è che, a differenza della replica DDL, TRACKSCHEMACHANGES può essere utilizzato negli scenari di replica tra database, ad esempio da MySQL a Db2 z/OS.

Di seguito sono riportate le considerazioni da tenere presenti quando si utilizza il comando TRANLOGOPTIONS TRACKSCHEMACHANGES.

• Per impostazione predefinita, il parametro TRACKSCHEMACHANGES è abilitato da Oracle GoldenGate 23.7 in poi. Pertanto, anche i metadati modificati vengono acquisiti per impostazione predefinita.

• DDL e TRACKSCHEMCHANGES non sono in conflitto. Se DDL è abilitato, DDL viene acquisito ed elaborato.

• Per acquisire le modifiche allo schema, l'utente deve abilitare in modo esplicito TRACKSCHEMACHANGES nel file dei parametri Extract.

• Se binlog_row_metadata non è FULL in MariaDB e MySQL, TRACKSCHEMCHANGES viene disabilitato con il seguente messaggio di avvertenza visualizzato nel file del report Extract:

  "Schema change tracking has been disabled because the MySQL system variable binlog_row_metadata is set to MINIMAL.
  The metadata recorded in the MySQL binlog is insufficient for schema change tracking and may result in data discrepancies.
  It is recommended to set it to FULL."

• L'opzione del parametro TRANLOGOPTIONS NOTRACKSCHEMACHANGES consente di disabilitare il tracciamento dello schema. Tuttavia, si consiglia di non disattivare il tracciamento dello schema. Se si disabilita il tracciamento dello schema, nel report Estrai viene visualizzato un messaggio di avvertenza come indicato di seguito.

  Schema change tracking has been disabled because TRANLOGOPTIONS NOTRACKSCHEMACHANGES is specified in the Extract parameter file.
  It is recommended to enable the schema change tracking. To enable the schema tracking, set the MySQL system variable binlog_row_metadata to FULL
  and remove the parameter TRANLOGOPTIONS NOTRACKSCHEMACHANGES from the extract parameter file.

• Sebbene TRACKSCHMEACHANGES sia abilitato per impostazione predefinita, quando DDL e TRACKSCHMEACHANGES non sono abilitati nel file dei parametri Extract e CREATE TABLE AS SELECT viene trovato da Extract, l'operazione DDL CREATE TABLE viene ignorata dall'elaborazione e le operazioni DML (INSERT) associate vengono acquisite da Extract.

  Durante l'elaborazione dei DML per tale tabella, il Replicat di destinazione viene interrotto poiché la tabella DDL non viene replicata nella destinazione.

  La tabella nella destinazione deve essere creata manualmente in questi casi emettendo solo l'operazione CREATE TABLE e non l'operazione CREATE TABLE AS SELECT.

• Se nel file dei parametri Extract non sono abilitati né TRACKSCHEMACHANGES né DDL e viene eseguita un'operazione DDL su una tabella specifica che fa parte dell'elenco Extract, Extract verrà interrotto.

• Se nel file dei parametri Extract non sono abilitati né TRACKSCHEMACHANGES né DDL e viene eseguita un'operazione DDL su una tabella specifica che non fa parte dell'elenco di acquisizione, Extract non interromperà l'operazione

TRANCOUNT

Valido per il server SQL.

Consente l'adeguamento del numero di transazioni elaborate per chiamata da Extract per estrarre i dati dalle tabelle intermedie di acquisizione dati modifica server SQL. In base al carico di lavoro delle transazioni, la modifica di questo valore può migliorare il throughput della velocità di acquisizione. Il valore minimo è 1, il massimo è 100 e il valore predefinito è 10.

Esempio:

TRANLOGOPTIONS TRANCOUNT 20

Questo esempio indica a Extract di recuperare 20 transazioni alla volta dalle tabelle abilitate per l'acquisizione dei dati delle modifiche.

[TSLOOKUPBEGINLRI

TSLOOKUPENDLRI]

Valido per Db2 LUW v 10.1 e versioni successive.

Quando si specifica un intervallo LRI utilizzando questi parametri, Extract cerca l'indicatore orario specificato nel comando ADD o ALTER EXTRACT all'interno di questo intervallo. Ciò consente a Extract di ottimizzare il processo di ricerca di un determinato indicatore orario nel log delle transazioni del database. Il parametro TSLOOKUPBEGINLRI è obbligatorio mentre TSLOOKUPENDLRI è facoltativo. La specifica di solo TSLOOKUPENDLRI senza TSLOOKUPBEGINLRI non è valida e causa l'interruzione dell'estrazione. Ad esempio:

TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197, TSLOOKUPENDLRI  75207.666216
TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197

Se l'indicatore orario fornito rientra tra gli intervalli LRI specificati o l'indicatore orario fornito cade dopo l'indicatore orario LRI TSLOOKUPBEGINLRI, Extract inizia da un record con indicatore orario uguale o inferiore all'indicatore orario fornito.

Se l'indicatore orario fornito è precedente all'indicatore orario LRI TSLOOKUPBEGINLRI, Extract viene avviato dall'indicatore LRI TSLOOKUPBEGINLRI specificato. Se l'indicatore orario fornito cade dopo l'indicatore orario TSLOOKUPENDLRI, Extract termina.

USENATIVEOBJSUPPORT

NOUSENATIVEOBJSUPPORT

Valido per Extract in modalità di acquisizione integrata per Oracle.

Integrated Capture aggiunge l'acquisizione basata su redo per i tipi di dati UDP (User Defined Type) e ANYDATA. È abilitato per impostazione predefinita e può essere abilitato solo se la versione del database di origine è 12.1.0.1 o successiva e la compatibilità del database di origine è 12.0.0.0.0 o successiva. È necessario utilizzare Replicat di Oracle GoldenGate release 12.1.2.1.0. Per utilizzare il supporto nativo, tutte le istanze di Oracle AI Database e Oracle GoldenGate devono essere release 12.1.0.1 o successive per essere compatibili.

Se l'acquisizione basata su redo è abilitata ma un tipo definito dall'utente contiene un attributo non supportato, l'acquisizione integrata tenta di acquisire il tipo definito dall'utente mediante il recupero. Per informazioni sulle limitazioni del supporto per l'acquisizione, vedere XML Tipi di dati. Se si creano tabelle di oggetti utilizzando un'istruzione CREATE TABLE AS SELECT (CTAS), Integrated Capture deve essere configurato in modo da acquisire DML dall'operazione CTAS per supportare completamente le tabelle di oggetti. Per CTAS, consultare Come Oracle GoldenGate gestisce i nomi di oggetti derivati nella documentazione dei microservizi di Oracle GoldenGate

Se supportato, l'impostazione predefinita è USENATIVEOBJSUPPORT.

Abilitare il parametro TRANLOGOPTIONS NOUSENATIVEOBJSUPPORT nel file dei parametri di Oracle Extract per acquisire i dati UDT come dati XML nel file trail. Questi dati possono quindi essere applicati a qualsiasi colonna di destinazione che accetta dati XML come CLOB/TEXT/CHAR/VARCHAR e così via.

USE_ROOT_CONTAINER_TIMEZONE

Valido solo per Extract integrato Oracle.

Questo parametro si riferisce a un ambiente CDB. Ogni PDB in un CDB può utilizzare un fuso orario del database diverso. Se il fuso orario del database è disponibile, Extract tenta di ottenere il fuso orario di un PDB dal dizionario integrato. L'estrazione del fuso orario richiede una patch nel database di mining. Se la patch non è disponibile, Extract invia una query al PDB per ottenere il fuso orario. Se la patch di database o una connessione al PDB non è disponibile e questo parametro è specificato, Extract presume che il fuso orario del database PDB sia uguale al fuso orario del container database radice.

VERSIONCHECK DYNAMIC

IMMEDIATE

Valido per il server SQL.

Utilizzare questa opzione quando si desidera che Extract convalidi le versioni degli oggetti CDC delle stored procedure comuni, ad esempio OracleCDCExtract e OracleGGCreateProcs, all'avvio.

DYNAMIC (impostazione predefinita) identifica le versioni oggetto CDC della tabella specificata nel file dei parametri una volta per tabella durante l'elaborazione dei record.

IMMEDIATE identifica in anticipo i problemi relativi alla versione dell'oggetto CDC invece che durante l'elaborazione dei record. I database con un numero elevato di tabelle configurate per l'acquisizione richiedono una convalida di avvio più lunga.

WARNCREATEASSELECT

Valido per Extract per MySQL.

L'operazione DDL CREATE TABLE AS SELECT non è supportata e Oracle GoldenGate Extract per MySQL viene interrotto quando incontra questo DDL. Si verifica un errore simile al seguente quando Extract viene interrotto per la prima volta:

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.

Quando si utilizza l'impostazione TRANLOGOPTIONS WARNCREATEASSELECT nel file Extract <parameter>, Extract continua dopo aver emesso il seguente messaggio di avvertenza nel file del report Extract:

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.