TRANLOGOPTIONS

Durée de validité

Extraction

Description

Utilisez le paramètre TRANLOGOPTIONS pour contrôler la façon dont le processus Extract interagit avec le journal de transactions ou avec l'API qui transmet les données de transaction, en fonction de la base de données ou du mode de capture. Vous pouvez utiliser plusieurs instructions TRANLOGOPTIONS dans le même fichier de valeurs ou indiquer plusieurs options dans la même instruction TRANLOGOPTIONS, si cela est autorisé pour ces options.

Utilisez une option TRANLOGOPTIONS donnée uniquement pour la ou les bases de données auxquelles elle est destinée.

Valeur par défaut

Aucun

Syntaxe

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]

Valide pour MySQL

Utilisez ALLOW_BINLOG_ROW_METADATA_MINIMAL dans le fichier de paramètres d'extraction pour continuer à utiliser la variable MySQL Server BINLOG_ROW_METADATA définie sur MINIMAL.

La variable BINLOG_ROW_METADATA de MySQL Server ne prend pas en charge les fonctionnalités telles que la réplication TRACKSCHEMACHANGES et DDL. Pour utiliser ces fonctionnalités, définissez BINLOG_ROW_METADATA sur Full dans le fichier de configuration du serveur MySQL. Si ces fonctionnalités ne sont pas requises, continuez à utiliser MINIMAL avec le paramètre ALLOW_BINLOG_ROW_METADATA_MINIMAL.

ALWAYSONREADONLYROUTING

Valide pour SQL Server

Le paramètre ALWAYSONREADONLYROUTING permet au processus d'extraction pour le serveur SQL d'acheminer son traitement en lecture seule vers une instance secondaire d'intention de lecture disponible lorsqu'il est connecté à un processus d'écoute de groupe de disponibilité Always On.

ALTLOGDEST <path | REMOTE>

Valide pour MySQL.

Indique l'emplacement du fichier d'index de journal MySQL. Le processus Extract recherche les fichiers journaux à cet emplacement au lieu de l'emplacement par défaut de la base de données. ALTLOGDEST peut être utilisé lorsque la configuration de base de données n'inclut pas le chemin d'accès complet aux journaux ou lorsqu'il existe plusieurs installations MySQL sur l'ordinateur. Le processus Extract lit le fichier d'index de journal pour trouver le fichier journal binaire qu'il doit lire. Lorsque ALTLOGDEST est utilisé, le processus d'extraction suppose que les journaux et l'index se trouvent au même emplacement.

Indiquez le chemin d'accès complet au répertoire.

Sous Windows, placez le chemin entre guillemets doubles si le chemin contient des espaces, comme dans l'exemple suivant.

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

Sur un système Linux :

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

Lors de la capture sur une base de données MySQL distante, utilisez l'option REMOTE au lieu du chemin du fichier d'index. En outre, si ALTLOGDEST n'est pas spécifié, le système considère que l'option est REMOTE.

A partir de la capture distante, indiquez les informations suivantes dans le fichier de paramètres Extract.

TRANLOGOPTIONS ALTLOGDEST REMOTE

Pour plus d'informations sur l'utilisation de l'option REMOTE, reportez-vous à Configuration des propriétés de journalisation.

ASYNCTRANSPROCESSING <buffer_size>

Valide pour l'extraction en mode de capture intégrée pour Oracle.

Détermine si la capture intégrée s'exécute en mode de traitement asynchrone ou synchrone et contrôle la taille de la mémoire tampon lorsque le processus Extract est en mode asynchrone. La valeur minimale est 1 et la valeur maximale est 1024. La valeur par défaut est 300.

ASYNCTRANSPROCESSING <buffer_size>

En mode de traitement <transaction> asynchrone, il existe deux threads de contrôle :

Un thread regroupe les enregistrements de modification logique (LCR) en transactions, effectue un filtrage au niveau objet et effectue un traitement d'annulation partiel,
L'autre thread formate les transactions validées, effectue les transformations spécifiées par l'utilisateur et écrit dans le fichier trace.

Le tampon de transaction est le tampon entre ces deux threads et est utilisé pour transférer le travail d'un thread à l'autre. La taille par défaut du tampon de transaction est de 300 transactions validées, mais est ajustée à la baisse par le gestionnaire de mémoire Oracle GoldenGate si sa mémoire cache est proche d'être épuisée.

NOASYNCTRANSPROCESSING

Désactive le traitement asynchrone et fait fonctionner le processus d'extraction en mode synchrone. Dans ce mode, un thread effectue tout le travail de capture.

BUFSIZE <size>

Valide pour Db2 LUW, et Db2 z/OS. Valide pour Db2 pour i à partir d'Oracle GoldenGate 19c et versions ultérieures. Valide pour la base de données Oracle AI à partir d'Oracle GoldenGate 21c et versions ultérieures.

Contrôle la taille maximale (en octets) des tampons alloués afin de contenir les données lues à partir du journal des transactions.

Les valeurs élevées augmentent la vitesse de capture, mais entraînent une consommation accrue de mémoire par le processus Extract. Les valeurs faibles réduisent l'utilisation de la mémoire mais augmentent les E/S car le processus Extract doit stocker sur le disque des données dont la taille dépasse celle du cache.

Pour Oracle AI Database, la taille de l'enregistrement d'opération DDL est limitée par la taille du tampon de capture d'enregistrement interne Oracle GoldenGate. La taille DDL peut atteindre la limite de taille du SGBDR Oracle. Bien que la base de données Oracle 21c autorise la création de DDL de plus de 10 Mo, la taille maximale du tampon de capture d'enregistrement interne est limitée à 10 Mo.

Le tampon <default> <size> est déterminé par la source des données de journalisation. Les plages valides et les tailles <default>, en octets, sont les suivantes :

DB2 LUW:

Valeur minimale : 8,192
Maximum: 10,000,000
Valeur par défaut : 204,800
Les valeurs précédentes doivent être des multiples de la taille de page 4096. Le processus Extract tronque vers un multiple si une valeur donnée ne répond pas à cette exigence.

Db2 z/OS et Db2 pour i :

Minimum : 36 Ko (36864)
Maximum : 32 Mo (33554432)
Par défaut : 2 Mo (2097152)
Les valeurs précédentes doivent être des multiples de la taille de page 4096. Le processus Extract tronque vers un multiple si une valeur donnée ne répond pas à cette exigence.
Chaque extraction utilise un 32bytes fixe d'ECSA sur le système Db2 z/OS auquel elle se connecte. Cela ne s'applique pas à Db2 pour i.

CHECKPOINTRETENTIONTIME <days>

Valide pour Extract en mode intégré uniquement pour Oracle.

Contrôle le nombre de jours pendant lesquels le processus Extract conserve les points de reprise avant leur purge. Les jours partiels peuvent être indiqués à l'aide de valeurs décimales. Par exemple, 8.25 indique 8 jours et 6 heures. Lorsque le point d'extraction en mode capture intégrée est purgé, les informations sur le dictionnaire LogMiner d'une extraction en mode saisie intégrée sont purgées, et la valeur first_scn du processus est réinitialisée avec la valeur SCN correspondant à la première modification dans le prochain fichier. La valeur par défaut est de sept jours et la valeur minimale est 0,00001.

DB2APIRETRY <number> de nouvelles tentatives

Si le processus d'extraction reçoit une erreur du journal Db2 en lisant l'API db2ReadLog(),, pour certaines erreurs, l'appel d'API fait l'objet d'une nouvelle tentative. Utilisez DB2APIRETRY pour modifier le nombre de nouvelles tentatives. Le nombre de tentatives par défaut est défini sur 3. Le code SQL pour lequel l'API fait l'objet d'une nouvelle tentative est SQLCODE -30108.

DB2ZV11COMPATIBILITYMODE

Valide pour l'extraction pour Db2 z/OS.

Lors de l'utilisation d'Oracle GoldenGate pour extraire à partir de Db2 z/OS version 11 dans certains modes de compatibilité, le processus d'extraction peut ne pas déterminer par programmation la version de base de données réelle et une erreur OGG-00551 ou OGG-00804 se produit. Utilisez cette option dans le fichier de paramètres Extract pour définir manuellement la version de base de données requise.

DICTIONARY_CACHE_SIZE <value>

Utilisez cette option pour régler la taille du cache du dictionnaire à partir du processus Extract. La valeur par défaut est 5 000. Si PERFORMANCEPROFILE est défini sur HIGH, la valeur par défaut est 10000.

DLFAILOVER_TIMEOUT <seconds>

Valide pour Extract en mode intégré pour Oracle.

Fournit un délai d'expiration configurable en secondes pour permettre la transition post-rôle de rétablissement de la base de données de secours. Il est utilisé conjointement avec HANDLEDLFAILOVER pour permettre au processus d'extraction intégré de démarrer immédiatement après une transition de rôle. A la fin de la période d'expiration, si la base de données de secours n'est toujours pas disponible, le processus Extract s'arrête.

La valeur par défaut est de 300 secondes. Vous pouvez également utiliser des centisecondes ou des millisecondes.

DISABLESOFTEOFDELAY

Valide pour l'extraction uniquement en mode intégré pour Oracle et Db2 LUW.

Utilisez DISABLESOFTEOFDELAY dans le fichier de paramètres d'extraction pour indiquer que le temps d'attente prend effet lorsque le statut EOF est signalé sans enregistrement à renvoyer.

ENABLE_AUTO_CAPTURE DISABLE_AUTO_CAPTURE

Définissez cette option pour activer le mode auto_capture, qui distribuerait les LCR des tables activées pour la capture automatique. Cette option peut être définie lorsque la version binaire Oracle de la base de données source est 21c ou supérieure.

EXCLUDETAG {<tag> | + | NULL}]

Valide pour le processus d'extraction. (Oracle uniquement)

EXCLUDETAG permet d'exclure les modifications précédemment balisées par le processus Replicat à l'aide de l'option DBOPTIONS SET TAG ou dans la session Oracle AI Database à l'aide de la procédure DBMS_XSTREAM_ADM.SET_TAG.

Utilisez EXCLUDETAG tag> pour indiquer au processus d'extraction d'ignorer les enregistrements individuels balisés avec la balise de journalisation indiquée.

Utilisez EXCLUDETAG NULL pour exclure toutes les opérations qui ne sont pas balisées. C'est le contraire de EXCLUDETAG +.

Utilisez EXCLUDETAG + pour indiquer au processus Extract d'ignorer les enregistrements individuels marqués d'une balise redo.

Exemple

Voici des exemples d'utilisation des indicateurs de balise avec EXCLUDETAG.

Pour exclure toutes les modifications étiquetées :

TRANLOGOPTIONS EXCLUDETAG +

Pour exclure des modifications marquées spécifiques, procédez comme suit :

TRANLOGOPTIONS EXCLUDETAG 00
TRANLOGOPTIONS EXCLUDETAG 0952

Instructions relatives à l'utilisation des paramètres EXCLUDETAG et INCLUDETAG

Lors de l'utilisation des paramètres EXCLUDETAG et INCLUDETAG avec les commandes TRANLOGOPTIONS et DDLOPTIONS, tenez compte des points suivants :

Si TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG est spécifié et que DDLOPTIONS EXCLUDETAG/INCLUDETAG n'est pas spécifié, les paramètres TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG s'appliquent aux opérations DML et DDL.
Si les options TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG sont indiquées et que DDLOPTIONS EXCLUDETAG/INCLUDETAG est également spécifié, TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG s'applique aux opérations DML et DDLOPTIONS EXCLUDETAG/INCLUDETAG aux opérations DDL.
Si TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG n'est pas spécifié et que DDLOPTIONS EXCLUDETAG/INCLUDETAG est spécifié, DDLOPTIONS EXCLUDETAG/INCLUDETAG s'applique aux opérations DDL et il n'existe aucun filtrage de balises pour les opérations DML.
Si TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG n'est pas spécifié et que DDLOPTIONS EXCLUDETAG/INCLUDETAG n'est pas non plus spécifié, l'option par défaut DDLOPTIONS EXCLUDETAG + est applicable, ce qui exclut toutes les opérations DDL balisées.
Pour DDLOPTIONS, lorsque vous indiquez EXCLUDETAG et INCLUDETAG, EXCLUDETAG doit apparaître en premier.

EXCLUDETRANS <transaction>

Valide pour l'extraction intégrée pour Oracle.

Indique le nom de transaction de l'utilisateur de la base de données Replicat ou de tout autre utilisateur afin que ces transactions ne soient pas capturées par le processus Extract. A utiliser pour le traitement bidirectionnel afin d'éviter les boucles de données entre les bases de données.

Pour plus d'informations sur la synchronisation bidirectionnelle, reportez-vous à Configuration de la réplication bidirectionnelle dans la documentation des microservices Oracle GoldenGate.

EXCLUDEUSER <user>

Valide pour Db2 LUW, Db2 pour z/OS, Db2 pour i, Oracle et Sybase.

Spécifie le nom de l'utilisateur de base de données Replicat, ou de tout autre utilisateur, à utiliser comme filtre. En général, cette option est utilisée pour identifier les transactions de réplication dans une configuration de traitement bidirectionnelle ou en cascade, dans le but de les exclure ou de les capturer. Toutefois, il peut être utilisé pour identifier les transactions effectuées par tout autre utilisateur, par exemple celles d'une application métier spécifique.

Vous pouvez utiliser EXCLUDEUSER et EXCLUDEUSERID dans le même fichier de paramètres. N'utilisez pas de caractères génériques dans les deux paramètres.

Le nom d'utilisateur doit être valide. Oracle GoldenGate interroge la base de données pour obtenir l'utilisateur associé ID et met en correspondance l'identificateur numérique avec le nom utilisateur. Par conséquent, si l'utilisateur indiqué est supprimé et recréé alors que la résolution de nom est définie sur la valeur par défaut DYNAMICRESOLUTION, EXCLUDEUSER reste valide. Si la même transaction est effectuée lorsque la résolution de nom est définie sur NODYNAMICRESOLUTION, EXCLUDEUSER devient non valide, et l'extraction doit être arrêtée puis démarrée pour que EXCLUDEUSER prenne effet, reportez-vous à DYNAMICRESOLUTION \| NODYNAMICRESOLUTION.

Recommandations Db2 z/OS : dans Db2 pour z/OS, l'utilisateur est toujours l'autorisation principale ID de la transaction, qui est généralement celle de l'utilisateur RACF d'origine qui s'est connecté, mais peut également être une autorisation différente ID si elle est modifiée par un processeur de transaction ou par Db2.
Directives Oracle : pour une base de données Oracle AI Database, plusieurs instructions EXCLUDEUSER peuvent être utilisées. Tous les utilisateurs indiqués sont considérés comme identiques à l'utilisateur Replicat.

Exemple

L'exemple Oracle suivant filtre deux utilisateurs (un par nom et un par utilisateur ID). Les transactions générées par ces utilisateurs seront gérées à l'aide de balises de filtre et une nouvelle taille de tampon de transaction est indiquée.

TRANLOGOPTIONS EXCLUDEUSER ggsrep, EXCLUDEUSERID 90, BUFSIZE 100000

Pour utiliser EXCLUDEUSER avec un domaine colocatif, vous devez indiquer PDB.USERNAME. L'exemple suivant exclut toute opération DML effectuée par PDBXYZ.SCOTT :

TRANLOGOPTIONS EXCLUDEUSER PDBXYZ.SCOTT

EXCLUDEUSERID <Database_uid>

Valide pour le processus d'extraction Oracle.

Indique l'utilisateur de base de données ID (uid) de l'utilisateur de base de données Replicat, ou de tout autre utilisateur, à utiliser comme filtre. Ce paramètre n'est pas valide pour les extractions colocatives. Utilisez plutôt le balisage et EXCLUDETAG.

L'utilisation est identique à celle de EXCLUDEUSER.

<Oracle_uid> est un entier non négatif dont la valeur maximale est 2147483638. Plusieurs vues système peuvent être interrogées pour obtenir l'utilisateur ID. La plus simple est la vue ALL_USERS. Oracle GoldenGate ne valide pas l'utilisateur ID. Si l'utilisateur associé à l'utilisateur spécifié ID est supprimé et recréé, un nouvel utilisateur ID est affecté. Par conséquent, EXCLUDEUSERID devient non valide pour cet utilisateur.

FAILOVERTARGETDESTID <n>

Valide pour le processus d'extraction Oracle.

Lorsque vous utilisez des processus d'extraction Oracle GoldenGate dans une configuration Oracle Data Guard, le processus d'extraction GoldenGate doit rester derrière les informations de journalisation qui ont été appliquées à la base de données de secours Oracle Data Guard. Le paramètre FAILOVERTARGETDESTID permet d'identifier le paramètre d'initialisation LOG_ARCHIVE_DEST_n qui pointe vers la base de données de secours, c'est-à-dire la cible de basculement que l'extraction doit conserver. Ce paramètre est utilisé en combinaison avec HANDLEDLFAILOVER pour déterminer si le processus Extract ralentit l'écriture des données de trace en fonction de la progression de l'application de la base de données de secours Oracle Data Guard. Notez que FAILOVERTARGETDESTID n'est pas nécessaire si la fonction FFSFO (Fast Start Failover) est activée pour la configuration Data Guard. La valeur minimale est 0, la valeur maximale est 32 et la valeur par défaut est 0.

Exemple

Afin de déterminer la valeur appropriée pour le paramètre d'extraction TRANLOGOPTIONS FAILOVERTARGETDESTID, connectez-vous à la base de données à partir de laquelle le processus d'extraction extrait des données et exécutez la commande suivante.

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)

Le paramètre d'extraction TRANLOGOPTIONS FAILOVERTARGETDESTID sera défini sur 2 car la base de données de secours Oracle GoldenGate doit rester en retard. La première entrée (log_archive_dest_1) concerne les fichiers de journalisation archivés locaux de cette base de données et la seconde, la base de données de secours.

Elle est définie sur 2 car la base de données de secours Oracle GoldenGate doit rester en retard. La première entrée (log_archive_dest_1) concerne les fichiers de journalisation archivés locaux de cette base de données et la seconde, la base de données de secours.

FETCHPARTIALJSON

Valide pour le processus d'extraction pour MySQL

Utilisez cette option dans le fichier de paramètres d'extraction pour extraire directement les données de la table, si des mises à jour partielles sont apportées aux colonnes de type de données JSON d'une table. Remarque : le traitement des mises à jour de données de colonne JSON dépend de la valeur de la variable de serveur MySQL, binlog_row_value_options, dont la valeur doit être définie sur PARTIAL_JSON et le fichier de paramètres d'extraction inclut le paramètre FETCHPARTIALJSON.

FETCHPARTIALLOB

Valide pour l'extraction en mode de capture intégrée pour Oracle.

Utilisez cette option lors de la réplication vers une cible hétérogène ou dans d'autres cas où l'image LOB complète est requise. L'extraction entraîne l'extraction de l'objet LOB complet, au lieu d'utiliser l'objet de modification partielle à partir de l'enregistrement de journalisation. Par défaut, le serveur de journalisation de base de données envoie au processus Extract un élément LOB entier ou partiel, selon que tout ou partie de l'élément LOB source a été mis à jour. Pour garantir le cliché correct de LOB, la fonctionnalité Oracle Flashback doit être activée pour la table et l'extraction doit être configurée pour l'utiliser. Le paramètre d'extraction FETCHOPTIONS contrôle l'extraction et doit être défini sur USESNAPSHOT (valeur par défaut en l'absence de NOUSESNAPSHOT). Sans cliché Flashback, le processus Extract extrait le fichier LOB de la table, qui peut être une image différente du moment où l'enregistrement de journalisation a été généré.

FETCHPARTIALXML

Valide pour l'extraction en mode de capture intégrée Oracle.

Utilisez cette option lorsque vous effectuez une réplication vers une cible hétérogène ou dans d'autres cas où l'image LOB complète est requise. Le processus Extract extrait le document XML complet au lieu d'utiliser l'image de modification partielle à partir de l'enregistrement de journalisation. Par défaut, le serveur de journalisation de base de données envoie au processus Extract un document XML entier ou partiel, selon que la totalité ou une partie de la source XML a été mise à jour. Pour garantir le cliché correct de XML, la fonctionnalité Oracle Flashback doit être activée pour la table et l'extraction doit être configurée pour l'utiliser. Le paramètre d'extraction FETCHOPTIONS contrôle l'extraction et doit être défini sur USESNAPSHOT (valeur par défaut en l'absence de NOUSESNAPSHOT). Sans instantané Flashback, le processus Extract extrait le document XML de la table, qui peut être une image différente du moment où l'enregistrement de journalisation a été généré.

EXCLUDEFILTERTABLE <table>

Valide pour l'extraction pour les serveurs MySQL, PostgreSQL et SQL.

Utilisez cette option pour identifier une transaction source à filtrer. Si une transaction source inclut une opération pour le fichier EXCLUDEFILTERTABLE indiqué, cette transaction est identifiée comme une transaction répliquée. Le filtrage des transactions est basé sur des balises.

Lorsqu'un processus Replicat utilise une table de points de reprise, il écrit un enregistrement de récupération dans la table de points de reprise à la fin de chaque transaction qu'il applique. Etant donné que toutes les transactions appliquées par le processus Replicat contiennent une mise à jour de la table de points de reprise, le processus Extract ignore la totalité de la transaction appliquée par le processus Replicat, ce qui empêche la mise en boucle des données. Pour les serveurs PostgreSQL et SQL, assurez-vous que TRANDATA a été ajouté pour la table de points de reprise.

Si vous utilisez une réplication parallèle dans une réplication bidirectionnelle, plusieurs tables de filtres sont prises en charge à l'aide de l'option TRANLOGOPTIONS EXCLUDEFILTERTABLE. Plusieurs tables de filtre permettent de spécifier TRANLOGOPTIONS EXCLUDEFILTERTABLE plusieurs fois avec des noms de table ou des caractères génériques différents.

Vous pouvez inclure une ou plusieurs entrées TRANLOGOPTIONS EXCLUDEFILTERTABLE dans le fichier de paramètres d'extraction. Dans l'exemple suivant, plusieurs entrées TRANLOGOPTIONS EXCLUDEFILTERTABLE sont incluses dans le fichier de paramètres Extract avec des noms d'objet explicites et des caractères génériques.

TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt2
TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt_RABC_*

Pour plus d'informations sur la création d'une table de point de reprise, reportez-vous à Ajouter une extraction principale. Pour indiquer correctement les noms d'objet et les caractères génériques, reportez-vous à Utilisation de caractères génériques dans les arguments de commande dans la documentation des microservices Oracle GoldenGate.

FORCEFETCHLOB

Valide pour le processus d'extraction Oracle.

Remplace le comportement par défaut de capture des données LOB à partir du journal de journalisation. Les objets LOB sont extraits de la base de données par défaut.

Attention : si une valeur est supprimée avant l'extraction, le processus Extract écrit une valeur NULL dans la trace. Si une valeur est mise à jour avant une extraction, le processus Extract écrit la valeur mise à jour. Pour éviter ces inexactitudes, essayez de maintenir la latence d'extraction faible. La documentation Oracle GoldenGate fournit des instructions pour le réglage des performances des processus. Pour obtenir des instructions sur la définition des options d'extraction, reportez-vous également à la section Interactions Between Fetches from a Table and DDL.

GETCTASDML | NOGETCTASDML

Active la fonctionnalité Créer une table en tant que sélection (CTAS). Lorsque GETCTASDML est activé, les instructions LMD CTAS sont envoyées à partir de LogMiner et répliquées sur la cible. Cette option est activée par défaut. L'exécution de CTAS DDL est supprimée sur la cible.

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

Valide pour le processus d'extraction pour Oracle

STANDBY_WARNING et STANDBY_ABEND valides pour Oracle Database 21c et versions ultérieures.

Détermine si le processus Extract ralentit l'écriture des données de trace en fonction de la progression de l'application de la base de données de secours Fast Start Failover. Il est destiné à maintenir le processus Extract à un point sûr derrière tout basculement en cas de perte de données.

Lorsque vous l'utilisez pour la perte de données dans une configuration Data Guard sans basculement Fast Start Failover (FSFO), vous devez définir le paramètre d'extraction FAILOVERTARGETDESTID pour identifier la destination de fichier de journalisation archivé ID vers laquelle la base de données de secours peut être connectée.

L'extraction est bloquée lorsque l'extraction interroge les informations de SCN d'application de la base de données de secours (SELECT applied_scn FROM v$archive_dest where dest_id=n) et que ce SCN est inférieur au SCN de LCR de traitement d'extraction. Dans ce cas, l'extraction ne traitera pas le LCR et attend que applied_scn devienne supérieur ou égal au SCN du LCR de traitement de l'extraction.

STANDBY_WARNING <value>

Temps écoulé avant l'écriture d'un message d'avertissement dans le fichier d'état Extract, si l'extraction est bloquée. La valeur par défaut est 60 secondes.

STANDBY_ABEND <value>

Durée avant l'abandon de l'extraction, si l'extraction est bloquée. La valeur par défaut est de 30 minutes.

Si STANDBY_WARNING et STANDBY_ABEND sont indiqués, STANDBY_ABEND doit toujours être supérieur à STANDBY_WARNING.

IFILOCKSECONDS <seconds>

Valide pour Db2 z/OS

Définit l'intervalle dans <seconds>, pour lequel l'extraction contient les verrous implicites détenus dans la base de données par les appels à IFCID.

Les verrous peuvent avoir une incidence sur la possibilité d'effectuer certaines opérations de base de données telles que REORGS. La valeur par défaut est de 20 secondes, avec des valeurs minimum et maximum de 1 seconde et 300 secondes, respectivement. Remarque : si le paramètre IFILOCKSECONDS est défini pour une durée plus longue, d'autres opérations de base de données telles que REORGS peuvent être impactées en raison du verrouillage interne causé par les appels d'extraction IFI. Par conséquent, si un conflit de verrouillage se produit par rapport à une extraction, définissez le délai d'expiration du verrou pour l'opération sur une durée supérieure à la valeur du paramètre IFILOCKSECONDS ou arrêtez l'extraction.

IGNOREDATACAPTURECHANGES NOIGNOREDATACAPTURECHANGES

Valide pour DB2 LUW

Détermine si l'extraction capture ou non les tables pour lesquelles DATA CAPTURE CHANGES n'est pas défini. IGNOREDATACAPTURECHANGES ignore les tables pour lesquelles DATA CAPTURE CHANGES n'est pas défini. Utilisez cette option si des tables ont été indiquées avec un caractère générique pour vous assurer que le traitement se poursuit pour les tables dont la capture des modifications est définie. Un avertissement est émis dans le journal des erreurs pour les tables ignorées. La valeur par défaut est NOIGNOREDATACAPTURECHANGES.

INCLUDEREGIONID INCLUDEREGIONIDWITHOFFSET

Valide pour le processus d'extraction Oracle.

Ces options prennent en charge le type de données Oracle TIMESTAMP WITH TIME ZONE indiqué sous la forme TZR (qui représente la région de fuseau horaire, telle que US/Pacific). Par défaut, l'extraction est abandonnée sur TIMESTAMP WITH TIME ZONE si elle inclut une région de fuseau horaire. Ces options vous permettent de gérer cet horodatage en fonction du type de base de données cible.

Lorsque le processus d'extraction détecte que le type de données source est TIMESTAMP et qu'il existe un jeton de mapping ID de région, le processus de réplication applique l'horodatage comme suit :

Une valeur TIMESTAMP WITH TIME ZONE avec TZR est appliquée si la version cible d'Oracle la prend en charge.
Un horodatage avec un décalage UTC est appliqué à une base de données hétérogène ou à une version antérieure d'Oracle qui ne prend pas en charge TIMESTAMP WITH TIME ZONE avec TZR.

INCLUDEREGIONID

Valide pour l'extraction intégrée pour Oracle.

INCLUDEREGIONID est en phase d'abandon pour Oracle GoldenGate 19c (19.1.0). A partir de la version 19c (19.1.0) d'Oracle GoldenGate, les données TIMESTAMP WITH TIME ZONE avec la région ID sont incluses par défaut, y compris le chargement initial.

A utiliser lors de la réplication à partir d'une source Oracle vers une cible Oracle de même version ou ultérieure. Lorsque INCLUDEREGIONID est indiqué, le processus d'extraction ajoute un index de colonne et la valeur TMZ à deux octets en tant que jeton de mapping de fuseau horaire et le renvoie vers la trace au format UTC YYYY-MM-DD HH:MI.SS.FFFFFF +00:00.

INCLUDEREGIONIDWITHOFFSET

Valide pour l'extraction intégrée pour Oracle.

Utilisez cette option pour convertir la région ID en valeur de décalage des heures et des minutes (+06:00, par exemple). Si l'option n'est pas spécifiée, l'horodatage est toujours écrit dans le fichier trace au format UTC et le fuseau horaire est toujours +00:00.

Si vous devez conserver la valeur du fuseau horaire en heures et minutes au lieu de UTC, cette option peut être utilisée.

Dans les cas suivants, l'option est forcée de s'activer pour conserver le fichier TIMEZONE <value> en heures et minutes <offset> :

Ancien format de fichier trace car le processus de réplication ne prend pas en charge la région ID.
Format XML, TEXT et SQL car ils ne prennent pas en charge la région ID.

INCLUDETAG {<tag>| +}

Valide pour le processus d'extraction. (Oracle uniquement)

Utilisez INCLUDETAG <tag> pour inclure des opérations DDL balisées spécifiques dans les fichiers trace. La valeur de balise peut comporter jusqu'à 2000 chiffres hexadécimaux (0-9 A-F).

Pour éviter les conflits, n'utilisez pas INCLUDETAG conjointement avec EXCLUDETAG.

Exemple : tranlogoptions includetag 00

LOB_CHUNK_SIZE

Valide pour SQL Server, PostgreSQL.

Si vous disposez de grandes tailles de données LOB, vous pouvez ajuster LOB_CHUNK_SIZE à partir de la valeur par défaut de 4000 octets, à une valeur supérieure allant jusqu'à 65535 octets, de sorte que la taille d'extraction soit augmentée, ce qui réduit les déplacements nécessaires pour extraire l'intégralité de LOB

Exemple : TRANLOGOPTIONS LOB_CHUNK_SIZE 8000

(PostgreSQL) Spécifie la taille du bloc pour les données LOB (CLOB/BLOB) qui seront utilisées pour la propagation dans COM. Son unité est en octets. Les valeurs lob_chunk_size minimum et maximum sont comprises entre 4000 et 65535 octets.

LOGREADTIMEOUT

Valide pour l'extraction pour PostgreSQL version 12 et supérieure.

Active ou désactive l'option wal_sender_timeout pour le processus d'expéditeur WAL.

L'option value peut être une valeur entière uniquement, avec 60000 millisecondes comme valeur par défaut. La valeur maximale est 2147483647 millisecondes et la valeur minimale est 0 milliseconde.

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

Valide pour l'extraction en mode de capture intégrée pour Oracle Standard ou Enterprise Edition 12c ou version ultérieure.

Transmet des paramètres et des valeurs au serveur de journalisation Oracle AI Database lorsque le processus Extract est en mode de capture intégrée. L'entrée doit être au format <parameter value>, comme dans :

TRANLOGOPTIONS INTEGRATEDPARAMS (downsream_real_time_mine Y)

Les spécifications de paramètre valides et leurs valeurs sont les suivantes :

max_sga_size

Indique la quantité de mémoire SGA utilisée par le serveur de journalisation de la base de données. Il peut s'agir d'un entier positif en mégaoctets. La valeur par défaut est de 1 Go si streams_pool_size est supérieur à 1 Go ; sinon, il est de 75 % de streams_pool_size.

parallelism

Indique le nombre de processus prenant en charge le serveur de journalisation de base de données. Peut être un entier positif. La valeur par défaut est 2.

downstream_real_time_mine

Indique si la capture intégrée extrait ou non une base de données d'exploration en aval en mode temps réel. La valeur Y indique la capture en temps réel et requiert la configuration des fichiers de journalisation de secours au niveau de la base de données d'exploration en aval. La valeur N indique la capture à partir des fichiers de journalisation archivés envoyés à la base de données d'exploration en aval. La valeurs par défaut est N.

enable_procedural_replication

Active la réplication procédurale lors de la capture. Par défaut, la réplication procédurale est désactivée. La valeur Y permet la réplication procédurale. Une fois que cette option est activée pour une extraction, elle le reste. La valeur du paramètre ne peut pas être rétrogradée.

MANAGESECONDARYTRUNCATIONPOINT NOMANAGESECONDARYTRUNCATIONPOINT

Valide pour PostgreSQL.

MANAGESECONDARYTRUNCATIONPOINT est le paramètre par défaut et contrôle le paramètre restart_lsn de l'emplacement de réplication pour l'extraction spécifique.

NOMANAGESECONDARYTRUNCATIONPOINT ne déplace pas l'emplacement de réplication de l'extraction et est généralement utilisé uniquement à des fins de développement et de test lorsqu'une extraction doit être repositionnée sur un LSN antérieur à partir du LSN de récupération de l'extraction. S'il est utilisé, le journal d'écriture anticipée PostgreSQL continue d'augmenter et de consommer de l'espace disque.

MAXAUTOCMTTRANSSIZE (<range>, <default>)

Valide pour DB2 pour i uniquement

Fournit la plage de la taille maximale des transactions validées automatiquement.

Db2 pour les enregistrements validés automatiquement (l'entrée de journal a un CCID égal à 0) n'a pas d'enregistrement de validation dans le journal et Oracle GoldenGate doit donc créer une transaction implicite pour inclure ces enregistrements dans la trace. La valeur par défaut permet d'inclure un seul enregistrement dans une seule transaction, ce qui maintient l'exactitude de l'heure d'E/S indiquée pour chaque enregistrement car l'heure d'E/S est basée sur la validation de la transaction.

Ce paramètre définit le nombre maximum d'enregistrements qui seront inclus dans une transaction implicitement créée, mais ce nombre peut être inférieur si un autre type d'écriture est vu dans le journal avant que le nombre maximum ne soit atteint. Cette réponse évite les problèmes de chevauchement pour les points de reprise sur les enregistrements qui appartiennent à des enregistrements explicitement validés.

La définition de la valeur de ce paramètre sur 1 (la valeur defulat) fournira une heure d'E/S précise pour chaque enregistrement de la trace pour les enregistrements qui sont validés automatiquement (ont un CCID égal à 0 dans l'écriture comptable), au détriment du débit potentiel pour l'extraction. La valeur de ce paramètre affecte également la taille maximale potentielle d'une transaction mise en cache pour ces enregistrements en mémoire. Si elle est définie sur une valeur inférieure, la mémoire de transaction est réduite si le processus Extract peut stocker le nombre maximal d'entrées par transaction implicite. Par définition, il ne peut y avoir qu'une seule transaction implicite de ce type en mémoire à un moment donné, car tout autre enregistrement de transaction entraînera une validation immédiate dans la trace des enregistrements d'une transaction implicite déjà en mémoire.

La plage par défaut est comprise entre 1 et 10000 et la valeur par défaut est 1.

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

Valide pour l'extraction Oracle GoldenGate pour Oracle.

Spécifie les informations d'identification pour que le processus Extract se connecte à une base de données Oracle Mining en aval afin d'interagir avec le serveur de journalisation. Peut être utilisé à la place de l'option MININGUSERIDALIAS si aucune banque d'informations d'identification Oracle GoldenGate n'est utilisée.

Cet utilisateur doit :

Vous disposez des privilèges accordés dans les rôles OGG_CAPTURE et OGG_APPLY pour Oracle GoldenGate 26ai et versions ultérieures. Pour Oracle Database 21c, les privilèges accordés dans dbms_goldengate_auth.grant_admin_privilege doivent être appliqués.
Il s'agit de l'utilisateur qui émet les commandes MININGDBLOGIN ou MININGDBLOGIN USERIDALIAS et REGISTER EXTRACT ou UNREGISTER EXTRACT pour le groupe d'extraction associé à ce paramètre MININGDBLOGIN USERIDALIAS..
Ne pas modifier.

Indique à Oracle GoldenGate d'utiliser une connexion du système d'exploitation pour Oracle, et non une connexion d'utilisateur de base de données. Utilisez cet argument uniquement si la base de données autorise l'authentification au niveau du système d'exploitation. Le contournement de l'authentification au niveau de la base de données évite de mettre à jour les fichiers de paramètres Oracle GoldenGate si les mots de passe de l'application changent fréquemment.

Pour employer cette option, le nom utilisateur approprié doit exister dans la base de données, en lien avec la valeur du paramètre d'initialisation Oracle OS_AUTHENT_PREFIX. La valeur définie avec OS_AUTHENT_PREFIX est concaténée au début du nom de compte du système d'exploitation d'un utilisateur, puis comparée au nom de la base de données. Ces deux noms doivent correspondre.

Lorsque OS_AUTHENT_PREFIX est défini sur ' ' (chaîne NULL), le nom utilisateur doit être créé avec IDENTIFIED EXTERNALLY. Par exemple, si le nom utilisateur OS est ogg, vous devez utiliser les éléments suivants pour créer l'utilisateur de base de données :

CREATE USER ogg IDENTIFIED EXTERNALLY;

Lorsque OS_AUTHENT_PREFIX est défini sur OPS$ ou une autre chaîne, le nom <user> doit être créé au format suivant :

<OS_AUTHENT_PREFIX_value><OS_user_name>

Par exemple, si le nom OS <user> est ogg, vous devez utiliser ce qui suit pour créer la base de données <user> :

CREATE USER ops$ogg IDENTIFIED BY oggpassword;

<user>

Indique le nom de l'utilisateur de base de données d'exploration ou une chaîne SQL*Net.

<password>

Mot de passe de l'utilisateur. Utilisez-la lorsque l'authentification de base de données est requise pour indiquer le mot de passe de l'utilisateur de base de données. Si le Mot de passe a été crypté à l'aide de la commande ENCRYPT PASSWORD, fournissez le Mot de passe crypté. Sinon, fournissez le Mot de passe en clair. Si le mot de passe fait la distinction entre les minuscules et les majuscules, indiquez-le en respectant cette distinction. Si l'utilisateur ID ou le mot de passe change, la modification doit être effectuée dans les fichiers de paramètres Oracle GoldenGate, y compris le re-cryptage du mot de passe si nécessaire.

<algorithm>

Spécifie le cryptage <algorithm> qui a été utilisé pour crypter le fichier <password> avec ENCRYPT PASSWORD. Valeurs possibles :

AES128
AES192
AES256

ENCRYPTKEY {<key_name> | DEFAULT}

Spécifie la clé de cryptage spécifiée avec ENCRYPT PASSWORD.

ENCRYPTKEY <key_name> indique le nom logique d'une clé de cryptage créée par l'administrateur dans le fichier ENCKEYS. Si la commande ENCRYPT PASSWORD a été employée avec l'option KEYNAME <key_name>.
ENCRYPTKEY DEFAULT indique à Oracle GoldenGate d'utiliser une clé aléatoire. Si la commande ENCRYPT PASSWORD a été employée avec l'option KEYNAME DEFAULT.

SYSDBA

Indique que l'utilisateur se connecte en tant que sysdba.

MININGUSERIDALIAS <alias>

Valide pour le processus d'extraction Oracle.

Indique l'alias des informations d'identification de connexion que le processus Extract utilise pour se connecter à une base de données Oracle Mining en aval afin d'interagir avec le serveur de journalisation. Peut être utilisé à la place de MININGUSER si une banque d'informations d'identification Oracle GoldenGate est utilisée.

Cet alias doit être :

Associé à des informations d'identification de connexion d'utilisateur de base de données stockées dans la banque d'informations d'identification Oracle GoldenGate locale. Cet utilisateur doit disposer des privilèges accordés dans dbms_goldengate_auth.grant_admin_privilege pour Oracle Database 21c et versions inférieures, ainsi que du rôle OGG_CAPTURE et OGG_APPLY pour Oracle AI Database 26ai et versions supérieures.
Utilisateur qui émet les commandes MININGDBLOGIN ou MININGDBLOGINALIAS et REGISTER EXTRACT ou UNREGISTER EXTRACT pour le groupe d'extraction associé à ce paramètre MININGUSERIDALIAS.

Cet alias et cet utilisateur ne doivent pas être modifiés lorsque le processus Extract est en mode de capture intégrée.

MIXEDENDIAN [ON OFF]

Valide pour Db2 LUW avec l'extraction principale Oracle GoldenGate

L'extraction Oracle GoldenGate pour Db2 LUW prend en charge la capture inter-endian où la base de données et Oracle GoldenGate sont exécutés sur des serveurs de commande d'octets différents. La détection de l'ordre des octets est automatique pour la base de données Db2 LUW version 10.5 et supérieure. Si vous devez désactiver la détection automatique sur Db2 LUW 10.5, vous pouvez la remplacer en spécifiant ce paramètre. Pour la version 10.1, le paramètre doit être utilisé dans le fichier de paramètres Extract pour la capture inter-endienne. Par défaut, la valeur est définie sur OFF pour la version 10.1.

Syntaxe :

TRANLOGOPTIONS MIXEDENDIAN [ON|OFF]

ON : si cette option est définie, l'extraction suppose que la base de données et Oracle GoldenGate s'exécutent sur des serveurs avec un ordre d'octets différent et que la conversion d'inversion d'octets nécessaire est effectuée.

OFF : si cette option est définie, l'extraction suppose que la base de données et Oracle GoldenGate s'exécutent sur des serveurs avec le même ordre d'octets et qu'aucune conversion d'inversion d'ordre d'octets n'est effectuée.

MANAGECDCCLEANUP NOMANAGECDCCLENUP

Valide pour SQL Server.

MANAGECDCCLEANUP est le paramètre par défaut et recommandé qui indique au processus Extract de valider l'existence du travail de nettoyage CDC Oracle GoldenGate ou de la tâche Purger les données de modification, en fonction de l'architecture et de la version d'Oracle GoldenGate.

Pour toutes les versions de l'architecture Oracle GoldenGate Classic et pour les versions de microservices antérieures à Oracle GoldenGate 21.4, utilisez le programme ogg_cdc_cleanup_setup.bat/sh pour installer le travail de nettoyage CDC Oracle GoldenGate, ainsi que les tables et procédures stockées associées.

Pour les installations Oracle GoldenGate Microservices 21.4 et ultérieures, créez une tâche Purger les données de modification à partir de la page Tâches à partir de la section Configuration du service d'administration de WebUI. La tâche Purger les données de modification crée les procédures stockées requises et les tables associées, et gère la fonction de purge dans Oracle GoldenGate et non via le travail d'agent serveur SQL.

L'option NOMANAGECDCCLEANUP indique au processus Extract de ne pas vérifier l'existence du travail de nettoyage CDC Oracle GoldenGate ou de la tâche Purger les données de modification. Cette option n'est pas recommandée pour les environnements de production, mais elle peut être utilisée pour tester une extraction sans avoir à créer le travail ou la tâche de nettoyage CDC Oracle GoldenGate.

PERFORMANCEPROFILE HIGH MEDIUM LOW_RES LOW_WORKLOAD

Valide pour l'extraction en mode de capture intégrée.

Pour régler la capture intégrée.

Il peut être défini sur HIGH, MEDIUM (par défaut) ou LOW_RES. Il permet d'améliorer les performances en regroupant les paramètres qui affectent les performances. Une fois le profil de performances défini, cette option configure automatiquement des paramètres pertinents pour atteindre le débit et le temps d'attente requis.

L'option HIGH permet un traitement plus efficace de la charge globale élevée avec un débit continu en termes de réplication de bout en bout. L'option HIGH augmente la taille du tampon de fichier trace à 4 Mo et réduit les valeurs des options de fin de fichier et de vidage à 0,1 seconde.
L'option MEDIUM définit la taille du tampon du fichier trace sur 1 Mo, ainsi que les valeurs de délai de fin de fichier et de vidage sur 1 seconde.
L'option LOW_RES est applicable lorsque les ressources sont faibles et qu'elles ont été ajoutées pour un déploiement limité en mémoire ou en ressources.
L'option LOW_WORKLOAD est utilisée avec Oracle GoldenGate pour les environnements Oracle AI Database avec une charge globale faible, mais la latence doit être en sous-secondes.

Lorsque l'option HIGH est activée pour la charge globale d'intensité faible à moyenne, elle fait passer la latence d'extraction intégrée à plusieurs secondes. En effet, l'option HIGH augmente la taille du tampon de lecture de l'extraction à 8 Mo. Cependant, la règle de vidage du tampon de lecture d'extraction est soit lorsque le tampon est plein, soit lorsqu'il n'y a pas d'enregistrements entrants pour une durée de 0,2 seconde. Par conséquent, toute charge globale continue avec un taux d'inclusion d'extraction inférieur à 8 Mo entraînera une latence d'extraction intégrée supérieure à 1 seconde. Assurez-vous que si les taux d'inclusion d'extraction (ou de génération des informations de journalisation si 100 % des informations de journalisation sont capturées) sont inférieurs à la valeur indiquée, par exemple ~15 Mo/s pour obtenir une latence d'extraction d'environ 0,5 seconde, n'utilisez pas l'option HIGH. Si une latence inférieure à la seconde est requise, il est recommandé de réduire la taille du tampon en conséquence. Par exemple, définissez la taille du tampon sur un tiers du taux de génération des informations de journalisation en Mo/s pour obtenir une latence d'extraction maximale d'environ 0,3 seconde.

QUERYTIMEOUT <seconds>

Valide pour SQL Server.

Indique la durée pendant laquelle les requêtes adressées au serveur SQL attendent les résultats avant de signaler un message d'erreur d'expiration. Cette option prend une valeur entière pour représenter le nombre de secondes. Le délai d'expiration par défaut de la requête est de 300 secondes (5 minutes). La valeur minimale est de 0 seconde (délai d'expiration infini). Le maximum est de 2147483645 secondes.

L'exemple suivant indique au serveur SQL d'attendre les résultats pendant 60 secondes avant d'expirer.

TRANLOGOPTIONS QUERYTIMEOUT 60

QUERYRETRYCOUNT <seconds>

Valide pour l'extraction pour le serveur SQL et MySQL.

Indique le nombre de tentatives d'appel de la procédure stockée CDC utilisée par le processus Extract en cas d'expiration de l'ensemble de résultats.

QUERYRETRYCOUNT peut être indiqué pour réessayer plusieurs fois. Si toutes les tentatives échouent, le processus Extract abandonne avec le message d'erreur de délai d'expiration de connexion normal.

Pour le serveur SQL, la valeur par défaut est une tentative de nouvelle tentative, après quoi le paramètre minimum (0) du processus abends.The est infini, la valeur maximale est 1000 et la valeur par défaut est 1.

Pour MySQL, le paramètre minimum et le paramètre par défaut sont 50 et le paramètre maximum 1000. Il n'y a pas de valeur infinie. Toute tentative de définition de QUERYRETRYCOUNT sur une valeur inférieure au minimum sera ignorée sans erreur ni avertissement.

L'exemple suivant fait que le processus Extract tente 4 fois son appel de procédure stockée CDC :

TRANLOGOPTIONS QUERYRETRYCOUNT 4

L'exemple suivant fait que le processus Extract tente 100 fois son appel de procédure stockée CDC :

TRANLOGOPTIONS QUERYRETRYCOUNT 100

READQUEUESIZE <size>

Valide pour MySQL.

Indique la taille de la file d'attente interne, en octets, pour les données de transaction. Il peut être augmenté pour améliorer les performances. Les valeurs valides sont des entiers compris entre 3 et 1500. La valeur par défaut est de 256 octets. Commencez par la valeur par défaut et évaluez les performances avant de procéder à un ajustement vers le haut.

REDO_TRANSPORT_LAG_THRESHOLD <seconds>

Valide pour l'extraction intégrée en mode Extraction en aval.

Surveille la latence réseau entre une base de données source et une base de données cible lorsque les fichiers de journalisation sont envoyés. Si la latence dépasse le seuil spécifié, un avertissement s'affiche dans le fichier de rapport et un message d'information suivant s'affiche lorsque le décalage passe au niveau normal.

La valeur de seuil par défaut est de 30 secondes. La valeur de seuil minimum pouvant être spécifiée est de 15 secondes.

Pour plus d'informations, voir Extraction en aval.

REDO_TRANSPORT_LAG_TIMEOUT <value>

Valide pour l'extraction intégrée en mode Extraction en aval.

La valeur fournie en tant qu'entrée dans cette option de paramètre est la période pendant laquelle le processus Extract attend les informations de journalisation de chaque thread. Si tous les threads ont attendu le délai d'expiration (en secondes) et n'ont reçu aucune information de journalisation, le processus Extract abandonne.

REQUIRELONGDATACAPTURECHANGES NOREQUIRELONGDATACAPTURECHANGES

Valide pour DB2 LUW.

Détermine la réponse du traitement d'extraction lorsque DATA CAPTURE est défini sur NONE ou sur CHANGES sans INCLUDE LONGVAR COLUMNS, et le fichier de paramètre comprend l'un des paramètres Oracle GoldenGate suivants, qui exige la présence d'images "avant" pour tout ou partie des valeurs des colonnes : GETBEFOREUPATES, NOCOMPRESSUPDATES et NOCOMPRESSDELETES. Ces deux paramètres DATA CAPTURE empêchent la journalisation des valeurs before pour les colonnes LONGVAR. Si ces colonnes ne sont pas disponibles pour le processus Extract, cela peut affecter l'intégrité des données cible.

REQUIRELONGDATACAPTURECHANGES

L'extraction est abandonnée avec une erreur.

NOREQUIRELONGDATACAPTURECHANGES

L'extraction émet un avertissement mais poursuit le traitement de l'enregistrement de données.

REMOTESCHEMA <value>

Valide pour l'extraction Db2 z/OS.

Lorsque vous utilisez plusieurs versions d'Oracle GoldenGate pour l'extraction Db2 z/OS, vous devez créer plusieurs versions des composants d'extraction GoldenGate dans Db2 z/OS sous différents noms de schéma. Le paramètre REMOTESCHEMA permet de demander au processus Extract quel schéma utiliser.

Pour plus d'informations, reportez-vous à la section Install Extract Components on Db2 z/OS in Oracle GoldenGate Microservices Documentation.

SOURCE_OS_TIMEZONE <timezone>

Valide pour l'extraction en mode de capture intégrée pour Oracle.

Indique le fuseau horaire système de la base de données source. Le fuseau horaire système d'une base de données est généralement défini par le fuseau horaire par défaut de son système d'exploitation. Vous pouvez également le remplacer en définissant la variable d'environnement TZ lors du démarrage de la base de données. Vous devez indiquer cette option uniquement si la base de données source et le traitement d'extraction utilisent des fuseaux horaires système différents. Par exemple, dans un déploiement de capture en aval où la base de données source et le processus Extract s'exécutent sur différents serveurs dans différents fuseaux horaires.

Vous pouvez spécifier la valeur de cette option dans un nom de région de fuseau horaire ou un formulaire de décalage UTC et vous devez utiliser le même formulaire que celui utilisé par la base de données source. Par exemple, si la base de données source utilise un nom de région tel que America/New_York, vous devez indiquer America/New_York, US/Eastern ou EST5EDT. Sinon, si la base de données source utilise une forme de décalage UTC telle que -05:00, vous devez utiliser la syntaxe (GMT)[+|-]hh[:mm]. Par exemple, GMT-05:00 ou -5.

SKIPUNKNOWNEVENT

Valide pour MySQL.

Vous pouvez utiliser ce paramètre dans le fichier de paramètres d'extraction pour permettre d'ignorer tout événement non géré ou inconnu dans le journal binaire MySQL. Si ce paramètre est indiqué, le traitement de l'extraction Oracle GoldenGate pour MySQL continue sans erreur lors de la recherche d'un événement qui n'est pas géré par le processus d'extraction en cours.

STREAMINGOPTIONS

Valide pour PostgreSQL.

Utilisez ce paramètre pour fournir les paramètres requis lors du démarrage de la réplication. Reportez-vous également à Inscription de l'extraction pour PostgreSQL dans la documentation des microservices Oracle GoldenGate.

Exemple :

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

SUPPRESSNOOOPUPDATES

Valide pour le processus d'extraction sur Oracle AI Database.

Vous pouvez contrôler si les mises à jour sans intervention sont filtrées ou non dans l'extraction intégrée. Par défaut, aucune suppression n'est effectuée.

TRACKSCHEMACHANGES NOTRACKSCHEMACHANGES

Valide pour Db2 z/OS et MySQL

Pour Oracle GoldenGate pour Db2 z/OS, ce paramètre permet au processus Extract de capturer les instructions de niveau table DDL et de conserver un historique des modifications à utiliser pour traiter DML lorsque les enregistrements de journal font référence à une version de table antérieure à la version en cours de la table. Il s'agit généralement d'images antérieures aux mises à jour, mais il peut s'agir d'images ultérieures, d'insertions ou de suppressions si le processus Extract s'exécute dans une situation de décalage à partir du journal des transactions en attente. Lorsque le processus Extract rencontre les opérations DDL appropriées, il prend en compte le numéro de version de DDL et met à jour la table d'historique DDL avec les nouvelles informations. Le processus Extract créera également un nouvel enregistrement TDR lié à la modification de la trace. Lorsque le processus Extract rencontre des versions antérieures de la table dans le journal, il référence l'historique DDL afin de pouvoir interpréter correctement DDL pour l'ancienne version de la table. La modification DDL n'est pas réellement répliquée et la synchronisation des modifications apportées à la table source doit toujours être exécutée manuellement par l'utilisateur dans la base de données cible.

Lorsque vous entrez cette commande, les modifications de niveau table DDL sont suivies par le processus Extract et les métadonnées de trace sont mises à jour, le cas échéant. Pour utiliser correctement TRACKSCHEMACHANGES, les métadonnées de table doivent présenter un état cohérent connu, ce qui signifie que toutes les tables nécessitant un suivi des versions doivent être créées et jamais modifiées ou réorganisées avant d'utiliser TRACKSCHEMACHANGES afin qu'aucune version de table précédente n'apparaisse dans le journal de transactions pour les opérations de mise à jour ou de suppression. Le script ddl_update.sh a été fourni pour faciliter la création d'un ensemble initial d'enregistrements d'historique DDL pour la base de données.

Pour utiliser le traitement DDL, la base de données doit être configurée avec une table d'historique qui capture les modifications DDL des différentes versions de toutes les tables du système de base de données. Les tables système doivent également être activées pour les modifications de capture de données. Pour créer et tenir à jour le tableau d'historique, les scripts shell UNIX suivants sont fournis :

ddl_create.sh : ce script permet de créer la table d'historique DDL. Il permet également de capturer des données pour les tables système suivantes :
- SYSIBM.SYSTABLES
- SYSIBM.SYSCOLUMNS
- SYSIBM.SYSINDEXES
- SYSIBM.SYSKEYCOLUSE
Exemple :

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

Dans cet exemple, le fichier résultant, crt_ddl_hist.sql, doit être traité par un autre programme.

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

Cette opération appelle un élément Db2 local pour établir une connexion distante à une base de données mainframe afin de créer immédiatement la table d'historique DDL.
ddl_remove.sh : ce script est utilisé pour enlever la table d'historique DDL. Toutefois, les tables système ne sont pas modifiées.
ddl_update.sh : ce script doit être exécuté pour établir un point de départ initial pour le suivi de version DDL à l'aide de TRACKSCHEMACHANGES. Il doit être exécuté après la création de la table d'historique DDL et ne doit pas être réexécuté, sauf si l'extraction doit être repositionnée de telle sorte que les versions de table puissent être manquées dans le journal de transactions. La réexécution de ddl_update.sh ajoutera uniquement des informations pour les tables qui ne sont pas déjà présentes dans l'historique DDL.
execsql.sh : ce script ne doit pas être exécuté directement, mais doit être disponible pour les autres scripts à générer. Il fournit des fonctionnalités communes pour l'analyse de la ligne de commande et l'exécution de SQL ou son écriture dans un fichier.

Ces scripts peuvent être utilisés pour créer les tables directement à l'aide d'une connexion Db2 ou pour créer des fichiers SQL qui peuvent être exécutés dans un programme de traitement SQL de votre choix. Les fichiers ont été vérifiés pour être compatibles avec Db2 remote et SPUFI.

Voici une description des options acceptées par ces scripts :

-h affiche l'aide relative à cette utilisation.
-d dsn indique le DSN Db2 auquel se connecter.
-u userid indique l'utilisateur ID avec lequel se connecter à la base.
-p password indique le mot de passe avec lequel se connecter à la base de données.
-s ggschema indique le nom du schéma dans lequel la table d'historique DDL doit être stockée. Ce schéma doit être identique à GGSCHEMA dans GLOBALS.
-t ddltable indique le nom de la table d'historique DDL. GGS_DDL_HIST est la valeur par défaut.
-f outfile indique le nom d'un fichier dans lequel écrire les instructions SQL au lieu de les exécuter. Si -d, -u, -p doit tous être spécifié s'il est utilisé ou -f. Actuellement, -t ne doit pas être utilisé. -f doit être utilisé si seule la commande db2cli est disponible sur l'hôte distant, car db2cli ne peut pas exécuter les instructions SQL générées.

Pour Oracle GoldenGate for MySQL, la réplication DDL est prise en charge avec la capture et la distribution. Lorsque la réplication DDL est activée, le processus d'extraction détecte les opérations DDL dans la table de base de données source, traite l'instruction DDL, actualise les métadonnées de la table et écrit l'instruction DDL et les métadonnées dans le fichier trace. Le processus de réplication applique ces opérations DDL sur la base de données cible MySQL et sélectionne également la nouvelle version des métadonnées à partir de la trace et traite les opérations DML suivantes. L'ensemble de ce processus est transparent et aucun temps d'inactivité n'est impliqué, mais cela n'est possible que pour le scénario J'aime tel que (MySQL à MySQL).

Le paramètre TRACKSCHEMACHANGES permet de capturer les modifications de métadonnées de table après l'opération DDL sur les tables source afin que la capture puisse traiter les opérations DML suivantes sans temps d'arrêt. Lorsque TRACKSCHEMACHANGES est activé, la capture écrit un nouvel enregistrement TDR dans la trace contenant les nouvelles métadonnées sur chaque opération DDL, suivi des données correspondantes. Capture ne traite pas et n'écrit pas l'instruction DDL dans le fichier trace. Par conséquent, les modifications DDL ne sont pas réellement répliquées vers la base de données cible. La synchronisation des modifications DDL correspondant à la source doit être exécutée manuellement dans la base de données cible. L'avantage de cette fonctionnalité est que, contrairement à la réplication DDL, TRACKSCHEMACHANGES peut être utilisé dans des scénarios de réplication entre bases de données, par exemple MySQL à Db2 z/OS.

Voici les points à prendre en compte lors de l'utilisation de la commande TRANLOGOPTIONS TRACKSCHEMACHANGES :

Par défaut, le paramètre TRACKSCHEMACHANGES est activé à partir d'Oracle GoldenGate 23.7. Les métadonnées modifiées sont donc également capturées par défaut.
DDL et TRACKSCHEMCHANGES ne sont pas en conflit. Si DDL est activé, DDL est capturé et traité.
Pour capturer les modifications de schéma, l'utilisateur doit activer explicitement TRACKSCHEMACHANGES dans le fichier de paramètres d'extraction.

Lorsque binlog_row_metadata n'est pas FULL sur MariaDB et MySQL, TRACKSCHEMCHANGES est désactivé avec le message d'avertissement suivant affiché dans le fichier de rapport d'extraction :

"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'option de paramètre TRANLOGOPTIONS NOTRACKSCHEMACHANGES vous permet de désactiver le suivi de schéma. Cependant, il est recommandé de ne pas désactiver le suivi de schéma. Si vous désactivez le suivi de schéma, un message d'avertissement est émis dans le rapport Extract comme suit :

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.

Bien que TRACKSCHMEACHANGES soit activé par défaut, lorsque DDL et TRACKSCHMEACHANGES ne sont pas activés dans le fichier de paramètres d'extraction et que CREATE TABLE AS SELECT est trouvé par l'extraction, l'opération DDL CREATE TABLE est ignorée du traitement et les opérations DML (INSERT) associées sont capturées par l'extraction.

Lors du traitement des instructions LMD pour une telle table, le processus Replicat cible est abandonné car la table DDL n'est pas répliquée sur la cible.

Dans ce cas, la table de la cible doit être créée manuellement en émettant uniquement l'opération CREATE TABLE et non l'opération CREATE TABLE AS SELECT.
Si ni TRACKSCHEMACHANGES ni DDL n'est activé dans le fichier de paramètres d'extraction et qu'une opération DDL est exécutée sur une table spécifique faisant partie de la liste d'extraction, l'extraction est abandonnée.
Si ni TRACKSCHEMACHANGES ni DDL n'est activé dans le fichier de paramètres d'extraction et qu'une opération DDL est exécutée sur une table spécifique qui ne fait pas partie de la liste de capture, l'extraction n'est pas abandonnée

TRANCOUNT

Valide pour SQL Server.

Permet d'ajuster le nombre de transactions traitées par appel par le processus Extract pour extraire des données des tables intermédiaires de capture des données de modification du serveur SQL. En fonction de votre charge de travail de transaction, l'ajustement de cette valeur peut améliorer le débit de capture. La valeur minimale est 1, la valeur maximale est 100 et la valeur par défaut est 10.

Exemple :

TRANLOGOPTIONS TRANCOUNT 20

Cet exemple indique au processus Extract d'extraire 20 transactions à la fois des tables activées pour la capture des données de modification.

[TSLOOKUPBEGINLRI TSLOOKUPENDLRI]

Valide pour Db2 LUW version 10.1 et ultérieure.

Lorsque vous indiquez une plage LRI à l'aide de ces paramètres, l'extraction recherche l'horodatage indiqué dans la commande ADD ou ALTER EXTRACT dans cette plage. Cela permet au processus Extract d'optimiser le processus de recherche pour un horodatage particulier dans le journal des transactions de la base de données. Le paramètre TSLOOKUPBEGINLRI est obligatoire tandis que TSLOOKUPENDLRI est facultatif. La spécification de TSLOOKUPENDLRI sans TSLOOKUPBEGINLRI n'est pas valide, ce qui entraîne l'abandon de l'extraction. Exemple :

TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197, TSLOOKUPENDLRI  75207.666216
TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197

Si l'horodatage fourni se situe entre les plages LRI indiquées ou si l'horodatage fourni se situe après l'horodatage LRI TSLOOKUPBEGINLRI, l'extraction commence à partir d'un enregistrement dont l'horodatage est inférieur ou égal à l'horodatage fourni.

Si l'horodatage fourni est antérieur à l'horodatage LRI TSLOOKUPBEGINLRI, l'extraction est démarrée à partir de l'heure LRI TSLOOKUPBEGINLRI indiquée. Si l'horodatage fourni est postérieur à l'horodatage TSLOOKUPENDLRI, l'extraction est abandonnée.

USENATIVEOBJSUPPORT NOUSENATIVEOBJSUPPORT

Valide pour l'extraction en mode de capture intégrée pour Oracle.

Integrated Capture ajoute la capture basée sur les informations de journalisation pour les types de données UDT (User Defined Type) et ANYDATA. Elle est activée par défaut et ne peut être activée que si la version de la base de données source est 12.1.0.1 ou supérieure et si la compatibilité de la base de données source est 12.0.0.0.0 ou supérieure. La réplication à partir de la version 12.1.2.1.0 d'Oracle GoldenGate doit être utilisée. Pour utiliser le support natif, toutes vos instances Oracle AI Database et Oracle GoldenGate doivent être compatibles avec la version 12.1.0.1 ou une version supérieure.

Si la capture basée sur les informations de journalisation est activée mais qu'un type de données défini par l'utilisateur contient un attribut non pris en charge, Integrated Capture tente de capturer le type de données défini par l'utilisateur à l'aide de l'extraction. Pour connaître les limites de prise en charge de la capture, reportez-vous à Types de données XML. Si vous créez des tables d'objet à l'aide d'une instruction CREATE TABLE AS SELECT (CTAS), la capture intégrée doit être configurée pour capturer DML à partir de l'opération CTAS afin de prendre entièrement en charge les tables d'objet. Pour CTAS, reportez-vous à la section How Oracle GoldenGate Handles Derived Object Names dans la documentation des microservices Oracle GoldenGate

La valeur par défaut est USENATIVEOBJSUPPORT si elle est prise en charge.

Activez le paramètre TRANLOGOPTIONS NOUSENATIVEOBJSUPPORT dans le fichier de paramètres d'extraction Oracle pour capturer les données UDT en tant que données XML dans le fichier trace. Ces données peuvent ensuite être appliquées à toute colonne cible qui accepte des données XML telles que CLOB/TEXT/CHAR/VARCHAR, etc.

USE_ROOT_CONTAINER_TIMEZONE

Valide pour l'extraction intégrée Oracle uniquement.

Ce paramètre concerne un environnement de base de données Conteneur. Chaque base pluggable d'une base Conteneur peut utiliser un fuseau horaire de base de données différent. Si le fuseau horaire de la base de données est disponible, le processus Extract tente d'obtenir le fuseau horaire d'une base de données pluggable à partir du dictionnaire intégré. L'extraction du fuseau horaire nécessite un patch sur la base de données d'extraction. Si le patch n'est pas disponible, le processus Extract envoie une requête à la base de données pluggable pour obtenir le fuseau horaire. Si le patch de base de données ou une connexion à la base de données pluggable n'est pas disponible et que ce paramètre est indiqué, le processus Extract suppose que le fuseau horaire de la base de données pluggable est identique au fuseau horaire de la base de données Conteneur racine.

VERSIONCHECK DYNAMIC IMMEDIATE

Ceci est valide pour SQL Server.

Utilisez cette option lorsque vous voulez que le processus Extract valide les versions d'objet CDC des procédures stockées courantes, telles que OracleCDCExtract et OracleGGCreateProcs, au démarrage.

DYNAMIC (valeur par défaut) identifie les versions d'objet CDC de la table indiquée dans le fichier de paramètres une fois par table pendant le traitement des enregistrements.

IMMEDIATE identifie les problèmes de version d'objet CDC à l'avance, plutôt que pendant le traitement des enregistrements. Les bases de données avec un grand nombre de tables configurées pour la capture nécessitent une validation de démarrage plus longue.

WARNCREATEASSELECT

Valide pour le processus d'extraction pour MySQL.

L'opération DDL CREATE TABLE AS SELECT n'est pas prise en charge et l'extraction Oracle GoldenGate pour MySQL est abandonnée lorsqu'elle rencontre ce paramètre DDL. Une erreur similaire à la suivante se produit lorsque le processus Extract est abandonné pour la première fois :

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.

Lorsque vous utilisez le paramètre TRANLOGOPTIONS WARNCREATEASSELECT dans le fichier d'extraction <parameter>, l'extraction continue après l'émission du message d'avertissement suivant dans le fichier de rapport d'extraction :

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.