TRANLOGOPTIONS

Válido para

Extracción

Descripción

Utilice el parámetro TRANLOGOPTIONS para controlar la forma en que Extract interactúa con el log de transacciones o con la API que transfiere datos de transacciones, según la base de datos o el modo de captura. Puede utilizar varias sentencias TRANLOGOPTIONS en el mismo archivo de parametros, o bien puede especificar varias opciones dentro de la misma sentencia TRANLOGOPTIONS, si se permite para esas opciones.

Utilice una opción TRANLOGOPTIONS determinada solo para la base de datos o bases de datos para las que está destinada.

Valor por defecto

Ninguno

Sintaxis

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]

Válido para MySQL

Utilice ALLOW_BINLOG_ROW_METADATA_MINIMAL en el archivo de parámetros de extracción para seguir utilizando la variable de MySQL Server BINLOG_ROW_METADATA definida en MINIMAL.

La variable BINLOG_ROW_METADATA de MySQL Server no soporta funciones como la replicación TRACKSCHEMACHANGES y DDL. Para utilizar estas funciones, defina BINLOG_ROW_METADATA en Full dentro del archivo de configuración del servidor MySQL. Si estas funciones no son necesarias, continúe utilizando MINIMAL con el parámetro ALLOW_BINLOG_ROW_METADATA_MINIMAL.

ALWAYSONREADONLYROUTING

Válido para SQL Server

El parámetro ALWAYSONREADONLYROUTING permite a Extract para el servidor SQL enrutar su procesamiento de solo lectura a un secundario de intención de lectura disponible cuando está conectado a un listener de grupo de disponibilidad Always On.

ALTLOGDEST <path | REMOTE>

Válido para MySQL.

Especifica la ubicación del archivo de índice de log MySQL. Extract busca los archivos log en esta ubicación en lugar de la ubicación por defecto de la base de datos. ALTLOGDEST se puede utilizar cuando la configuración de la base de datos no incluye el nombre de ruta de acceso completa a los logs o cuando hay varias instalaciones MySQL en la máquina. Extract lee el archivo de índice de log para buscar el archivo log binario que necesita leer. Cuando se utiliza ALTLOGDEST, Extract asume que los logs y el índice están en la misma ubicación.

Proporcione el nombre completo de la ruta de acceso al directorio.

En Windows, incluya la ruta entre comillas dobles si la ruta contiene espacios, como en el siguiente ejemplo.

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

En el sistema Linux:

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

Al capturar en una base de datos MySQL remota, utilice la opción REMOTE en lugar de la ruta del archivo de índice. Además, si no se especifica ALTLOGDEST, el sistema asume que la opción es REMOTE.

En la captura remota, especifique lo siguiente en el archivo de parámetros Extract.

TRANLOGOPTIONS ALTLOGDEST REMOTE

Para obtener más información sobre el uso de la opción REMOTE, consulte Configuración de Propiedades de Registro.

ASYNCTRANSPROCESSING <buffer_size>

Válido para Extract en modo de captura integrado para Oracle.

Controla si la captura integrada se ejecuta en modo de procesamiento asíncrono o síncrono y controla el tamaño del buffer cuando Extract está en modo asíncrono. El mínimo es 1 y el máximo es 1024; el valor por defecto es 300.

ASYNCTRANSPROCESSING <buffer_size>

En el modo de procesamiento asíncrono <transaction>, hay dos threads de control:

Un thread agrupa registros de cambios lógicos (LCR) en transacciones, realiza filtros a nivel de objeto y realiza un procesamiento de rollback parcial.
El otro thread formatea las transacciones confirmadas, realiza las transformaciones especificadas por el usuario y escribe en el archivo de pista.

El buffer de transacción es el buffer entre estos dos threads y se utiliza para transferir el trabajo de un thread al otro. El tamaño del buffer de transacción por defecto es de 300 transacciones confirmadas, pero el gestor de memoria de Oracle GoldenGate las ajusta hacia abajo si la memoria caché está a punto de agotarse.

NOASYNCTRANSPROCESSING

Desactiva el procesamiento asíncrono y hace que Extract funcione en modo síncrono. En este modo, un thread realiza todo el trabajo de captura.

BUFSIZE <size>

Válido para Db2 LUW y Db2 z/OS. Válido para Db2 para i desde Oracle GoldenGate 19c y superior. Válido para la base de datos Oracle AI desde Oracle GoldenGate 21c y superior.

Controla el tamaño máximo, en bytes, de los búferes que se asignan para contener los datos que se leen del log de transacción.

Los valores altos aumentan la velocidad de captura, pero hacen que Extract consuma más memoria. Los valores bajos reducen el uso de memoria, pero aumentan la E/S porque Extract debe almacenar datos que superen el tamaño de caché en el disco.

Para Oracle AI Database, el tamaño del registro de operación DDL está limitado por el tamaño del buffer de captura de registros internos de Oracle GoldenGate. El tamaño de DDL puede ser hasta el límite de tamaño de Oracle RDBMS. Aunque la base de datos Oracle 21c permite crear DDL de más de 10 MB, el tamaño máximo del buffer de captura de registros internos está limitado a 10 MB.

El buffer <default> <size> está determinado por el origen de los datos de redo. A continuación se muestran los rangos válidos y los tamaños de <default>, en bytes:

Db2 LUW:

Mínimo: 8,192
Máximo: 10 000 000
Valor por defecto: 204,800
Los valores anteriores deben ser múltiplos del tamaño de página 4096. La extracción se truncará a un múltiplo si un valor determinado no cumple este requisito.

Db2 z/OS y Db2 para i:

Mínimo: 36 KB (36864)
Máximo: 32MB (33554432)
Predeterminado: 2MB (2097152)
Los valores anteriores deben ser múltiplos del tamaño de página 4096. La extracción se truncará a un múltiplo si un valor determinado no cumple este requisito.
Cada Extract utiliza un valor 32bytes fijo de ECSA en el sistema Db2 z/OS al que se conecta Extract. Esto no se aplica a Db2 para i.

CHECKPOINTRETENTIONTIME <days>

Válido para Extract en modo integrado solo para Oracle.

Controla el número de días que Extract conserva los puntos de control antes de que se depuren. Los días parciales se pueden especificar con valores decimales. Por ejemplo, 8,25 especifica 8 días y 6 horas. Cuando se depura el punto del control de un Extract en modo integrado de captura, se depura el número de días que Extract conserva los puntos de control antes de depurarse y el valor first_scn del proceso se restablece en el valor SCN correspondiente al primer cambio del siguiente archivo redo log archivado. El valor por defecto es El valor por defecto es siete días y el mínimo es 0,00001.

DB2APIRETRY <number> de reintentos

Si Extract recibe un error del log Db2 que lee la API db2ReadLog(),, se vuelve a intentar la llamada de API para determinados errores. Utilice DB2APIRETRY para cambiar el número de reintentos. El número de reintentos predeterminado se establece en 3. El código SQL para el que se reintenta la API es SQLCODE -30108.

DB2ZV11COMPATIBILITYMODE

Válido para Extract para Db2 z/OS.

Al utilizar Oracle GoldenGate para extraer de Db2 z/OS versión 11 en algunos modos de compatibilidad, es posible que el proceso Extract no determine mediante programación la versión real de la base de datos y se produzca un error OGG-00551 u OGG-00804. Utilice esta opción en el archivo de parámetros Extract para definir manualmente la versión de base de datos necesaria.

DICTIONARY_CACHE_SIZE <value>

Utilice esta opción para ajustar el tamaño de la caché de diccionario desde Extract. El valor por defecto es 5.000. Si PERFORMANCEPROFILE se define en HIGH, el valor por defecto es 10000.

DLFAILOVER_TIMEOUT <seconds>

Válido para Extract en modo integrado para Oracle.

Proporciona un timeout configurable en segundos para permitir la nueva instanciación de la base de datos en espera después de la transición de rol. Se utiliza junto con HANDLEDLFAILOVER para permitir que Integrated Extract se inicie inmediatamente después de una transición de roles. Al final del período de timeout, si la base de datos en espera aún no está disponible, Extract finalizará.

El valor por defecto es 300 segundos. También puede utilizar centisegundos o milisegundos.

DISABLESOFTEOFDELAY

Válido para Extract solo en modo integrado para Oracle y Db2 LUW.

Utilice DISABLESOFTEOFDELAY en el archivo de parámetros Extract para definir que el tiempo de espera se aplica cuando se informa un estado EOF sin registros que devolver.

ENABLE_AUTO_CAPTURE DISABLE_AUTO_CAPTURE

Defina esta opción para activar el modo auto_capture, que entregaría LCR de tablas activadas para la captura automática. Esta opción se puede definir cuando la versión binaria de Oracle de la base de datos origen es 21c o superior.

EXCLUDETAG {<tag> | + | NULL}]

Válido para Extract. (Solo para Oracle)

EXCLUDETAG se utiliza para excluir los cambios etiquetados anteriormente por Replicat mediante la opción DBOPTIONS SET TAG o en la sesión de Oracle AI Database mediante el procedimiento DBMS_XSTREAM_ADM.SET_TAG.

Utilice EXCLUDETAG tag> para indicar al proceso Extract que ignore los registros individuales que están etiquetados con la etiqueta de redo especificada.

Utilice EXCLUDETAG NULL para excluir todas las operaciones que no están etiquetadas. Esto es lo contrario de EXCLUDETAG +.

Utilice EXCLUDETAG + para indicar al proceso Extract que ignore los registros individuales que están etiquetados con cualquier etiqueta de redo.

Ejemplo

A continuación se muestran ejemplos de cómo utilizar los especificadores de etiquetas con EXCLUDETAG.

Para excluir todos los cambios etiquetados:

TRANLOGOPTIONS EXCLUDETAG +

Para excluir cambios etiquetados específicos:

TRANLOGOPTIONS EXCLUDETAG 00
TRANLOGOPTIONS EXCLUDETAG 0952

Directrices al utilizar los parámetros EXCLUDETAG y INCLUDETAG

Al utilizar los parámetros EXCLUDETAG y INCLUDETAG con los comandos TRANLOGOPTIONS y DDLOPTIONS, tenga en cuenta lo siguiente:

Si se especifican TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG y no se especifica DDLOPTIONS EXCLUDETAG/INCLUDETAG, los parámetros TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG se aplican a las operaciones DML y DDL.
Si se especifican las opciones TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG y también se especifica DDLOPTIONS EXCLUDETAG/INCLUDETAG, TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG se aplica a las operaciones DML y DDLOPTIONS EXCLUDETAG/INCLUDETAG se aplica a las operaciones DDL.
Si no se especifica TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG y se especifica DDLOPTIONS EXCLUDETAG/INCLUDETAG, DDLOPTIONS EXCLUDETAG/INCLUDETAG se aplica a las operaciones DDL y no hay ningún filtrado de etiquetas para las operaciones DML.
Si no se especifica TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG y tampoco se especifica DDLOPTIONS EXCLUDETAG/INCLUDETAG, se aplica la opción por defecto DDLOPTIONS EXCLUDETAG +, que excluye todas las operaciones DDL etiquetadas.
Para DDLOPTIONS al especificar EXCLUDETAG y INCLUDETAG, EXCLUDETAG debe aparecer primero.

EXCLUDETRANS <transaction>

Válido para extracción integrada para Oracle.

Especifica el nombre de transacción del usuario de la base de datos de Replicat o de cualquier otro usuario para que Extract no capture esas transacciones. Se utiliza para el procesamiento bidireccional para evitar el bucle de datos entre las bases de datos.

Para obtener más información sobre la sincronización bidireccional, consulte Configuración de replicación bidireccional en la Documentación de microservicios de Oracle GoldenGate.

EXCLUDEUSER <user>

Válido para Db2 LUW, Db2 para z/OS, Db2 para i, Oracle y Sybase.

Especifica el nombre del usuario de la base de datos de Replicat o de cualquier otro usuario que se va a utilizar como filtro. Normalmente, esta opción se utiliza para identificar transacciones de Replicat en una configuración de procesamiento bidireccional o en cascada, con el fin de excluirlas o capturarlas. Sin embargo, se puede utilizar para identificar transacciones de cualquier otro usuario, como las de una aplicación de negocio específica.

Puede utilizar EXCLUDEUSER y EXCLUDEUSERID en el mismo archivo de parámetros. No utilice comodines en ninguno de los parámetros.

El nombre del usuario debe ser válido. Oracle GoldenGate consulta la base de datos para obtener el usuario asociado ID y vuelve a asignar el identificador numérico al nombre de usuario. Por este motivo, si el usuario especificado se borra y se vuelve a crear mientras la resolución de nombres se define en el valor por defecto de DYNAMICRESOLUTION, EXCLUDEUSER sigue siendo válido. Si se realiza la misma transacción cuando la resolución de nombres se define en NODYNAMICRESOLUTION, EXCLUDEUSER pasa a ser no válido y Extract se debe parar y, a continuación, iniciar para que EXCLUDEUSER surta efecto, consulte DYNAMICRESOLUTION \| NODYNAMICRESOLUTION.

Directrices Db2 z/OS: en Db2 para z/OS, el usuario siempre es la autorización principal ID de la transacción, que suele ser la del usuario RACF original que inició sesión, pero también podría ser una autorización diferente ID si se cambia por un procesador de transacciones o si sale Db2.
Directrices de Oracle: para Oracle AI Database, se pueden utilizar varias sentencias EXCLUDEUSER. Todos los usuarios especificados se consideran iguales que el usuario de Replicat.

Ejemplo

Los siguientes filtros de ejemplo de Oracle para dos usuarios (uno por nombre y otro por usuario ID). Las transacciones generadas por estos usuarios se gestionarán mediante etiquetas de filtro y se especificará un nuevo tamaño de buffer de transacción.

TRANLOGOPTIONS EXCLUDEUSER ggsrep, EXCLUDEUSERID 90, BUFSIZE 100000

Para utilizar EXCLUDEUSER con varios inquilinos, debe especificar PDB.USERNAME. En el siguiente ejemplo se excluye cualquier operación DML realizada por PDBXYZ.SCOTT:

TRANLOGOPTIONS EXCLUDEUSER PDBXYZ.SCOTT

EXCLUDEUSERID <Database_uid>

Válido para Extract para Oracle.

Especifica el usuario de base de datos ID (uid) del usuario de base de datos de Replicat, o de cualquier otro usuario, que se va a utilizar como filtro. Este parámetro no es válido para extracciones de varios inquilinos. Utilice el etiquetado y EXCLUDETAG en su lugar.

El uso es el mismo que el de EXCLUDEUSER.

<Oracle_uid> es un entero no negativo con un valor máximo de 2147483638. Hay varias vistas del sistema que se pueden consultar para obtener el usuario ID. La más sencilla es la vista ALL_USERS. Oracle GoldenGate no valida el usuario ID. Si se borra y se vuelve a crear el usuario asociado al usuario especificado ID, se asigna un nuevo usuario ID; por lo tanto, EXCLUDEUSERID no es válido para ese usuario.

FAILOVERTARGETDESTID <n>

Válido para Extract para Oracle.

Al utilizar procesos de extracción de Oracle GoldenGate en una configuración de Oracle Data Guard, el proceso de extracción GoldenGate debe permanecer detrás del redo que se ha aplicado a la base de datos en espera de Oracle Data Guard. El parámetro FAILOVERTARGETDESTID se utiliza para identificar el parámetro de inicialización LOG_ARCHIVE_DEST_n que apunta a la base de datos en espera, es decir, el destino de failover en el que Extract debe permanecer. Este parámetro se utiliza junto con HANDLEDLFAILOVER para controlar si Extract limitará su escritura de datos de pista en función del progreso de aplicación de la base de datos en espera de Oracle Data Guard. Tenga en cuenta que FAILOVERTARGETDESTID no es necesario si la configuración de Data Guard tiene activado el failover de inicio rápido (FSFO). El valor mínimo es 0, el máximo es 32 y el valor predeterminado es 0.

Ejemplo

Para determinar el valor adecuado para el parámetro Extract TRANLOGOPTIONS FAILOVERTARGETDESTID, conéctese a la base de datos de la que Extract está extrayendo datos y emita el siguiente comando.

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)

El parámetro Extract TRANLOGOPTIONS FAILOVERTARGETDESTID se definirá en 2 porque es la base de datos en espera en la que Oracle GoldenGate debe quedarse atrás. La primera entrada (log_archive_dest_1) es para los archive logs locales de esa base de datos y la segunda es para la base de datos en espera.

Se definiría en 2 porque esa es la base de datos en espera en la que Oracle GoldenGate debería quedarse atrás. La primera entrada (log_archive_dest_1) es para los archive logs locales de esa base de datos y la segunda es para la base de datos en espera.

FETCHPARTIALJSON

Válido para Extract para MySQL

Utilice esta opción en el archivo de parámetros Extract para recuperar directamente los datos de la tabla, si hay actualizaciones parciales en las columnas de tipo de dato JSON de una tabla. Nota: El procesamiento de actualizaciones de datos de columna JSON depende del valor de la variable de servidor MySQL, binlog_row_value_options, cuyo valor se debe definir como PARTIAL_JSON y el archivo de parámetros Extract incluye el parámetro FETCHPARTIALJSON.

FETCHPARTIALLOB

Válido para Extract en modo de captura integrado para Oracle.

Utilice esta opción al replicar en un destino heterogéneo o en otras condiciones en las que se necesite la imagen LOB completa. Hace que Extract recupere el objeto LOB completo, en lugar de utilizar el objeto de cambio parcial del registro de redo. Por defecto, el servidor de minería de logs de la base de datos envía Extract un LOB completo o parcial, según si se ha actualizado todo o parte del LOB de origen. Para garantizar la instantánea correcta de LOB, la función de Oracle Flashback debe estar activada para la tabla y Extract debe estar configurado para utilizarla. El parámetro Extract FETCHOPTIONS controla la recuperación y se debe definir en USESNAPSHOT (el valor por defecto en ausencia de NOUSESNAPSHOT). Sin una instantánea de flashback, Extract recupera LOB de la tabla, que puede ser una imagen diferente del punto en el tiempo en que se generó el registro de redo.

FETCHPARTIALXML

Válido para Extract en modo de captura integrado de Oracle.

Utilice esta opción al replicar en un destino heterogéneo o en otras condiciones en las que se necesite la imagen LOB completa. Hace que Extract recupere el documento XML completo, en lugar de utilizar la imagen de cambio parcial del registro de redo. Por defecto, el servidor de minería de logs de la base de datos envía Extract un documento XML completo o parcial, según si se ha actualizado todo o parte del origen XML. Para garantizar la instantánea correcta de XML, la función de Oracle Flashback debe estar activada para la tabla y Extract debe estar configurado para utilizarla. El parámetro Extract FETCHOPTIONS controla la recuperación y se debe definir en USESNAPSHOT (el valor por defecto en ausencia de NOUSESNAPSHOT). Sin una instantánea de flashback, Extract recupera el documento XML de la tabla, que puede ser una imagen diferente del punto en el tiempo en que se generó el registro de redo.

EXCLUDEFILTERTABLE <table>

Válido para Extract para los servidores MySQL, PostgreSQL y SQL.

Utilice esta opción para identificar una transacción de origen para el filtrado. Si una transacción de origen incluye cualquier operación para el EXCLUDEFILTERTABLE especificado, esa transacción se identifica como una transacción replicada. El filtrado de transacciones se basa en etiquetas.

Cuando un Replicat utiliza una tabla de puntos de control, escribe un registro de recuperación en la tabla de puntos de control al final de cada transacción que aplica. Teniendo en cuenta que todas las transacciones aplicadas por el Replicat contienen una actualización de la tabla de puntos de control, el Extract ignora toda la transacción aplicada por el Replicat, lo que impide el bucle de datos. Para el servidor PostgreSQL y SQL, asegúrese de que se ha agregado TRANDATA para la tabla de puntos de control.

Si se utiliza un Replicat paralelo en una replicación bidireccional, se soportan varias tablas de filtros mediante la opción TRANLOGOPTIONS EXCLUDEFILTERTABLE. Varias tablas de filtros permiten que TRANLOGOPTIONS EXCLUDEFILTERTABLE se especifique varias veces con diferentes nombres de tabla o comodines.

Puede incluir una o varias entradas TRANLOGOPTIONS EXCLUDEFILTERTABLE en el archivo de parámetros Extract. En el siguiente ejemplo, se incluyen varias entradas TRANLOGOPTIONS EXCLUDEFILTERTABLE en el archivo de parámetros Extract con nombres de objetos explícitos y comodines.

TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt2
TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt_RABC_*

Para obtener información sobre la creación de una tabla de puntos de control, consulte Adición de una extracción principal. Para especificar correctamente los nombres de objetos y los comodines, consulte Uso de comodines en argumentos de comando en la documentación de microservicios de Oracle GoldenGate.

FORCEFETCHLOB

Válido para Extract para Oracle.

Sustituye el comportamiento por defecto de captura de datos LOB desde el redo log. Hace que los LOB se recuperen de la base de datos por defecto.

Precaución: si se suprime un valor antes de que se produzca la recuperación, Extract escribe un valor nulo en la pista. Si un valor se actualiza antes de una recuperación, Extract escribe el valor actualizado. Para evitar estas inexactitudes, intente mantener baja latencia de Extract. La documentación de Oracle GoldenGate proporciona directrices para ajustar el rendimiento del proceso. Además, consulte Interacciones entre recuperaciones de una tabla y DDL para obtener instrucciones sobre la definición de opciones de recuperación.

GETCTASDML | NOGETCTASDML

Activa la funcionalidad Crear Tabla como Seleccionar (CTAS). Cuando GETCTASDML está activado, las DML de CTAS se envían desde LogMiner y se replican en el destino. Esta opción se encuentra activada por defecto. La ejecución de CTAS DDL se suprime en el destino.

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

Válido para Extract para Oracle

STANDBY_WARNING y STANDBY_ABEND válidos para Oracle Database 21c y superior.

Controla si Extract limitará la escritura de los datos de pista según el progreso de aplicación de la base de datos en espera de failover de inicio rápido. Está diseñado para mantener Extract en un punto seguro detrás de cualquier failover de pérdida de datos.

Cuando se utiliza para la pérdida de datos en una configuración de Data Guard sin failover de inicio rápido (FSFO), debe definir el parámetro Extract FAILOVERTARGETDESTID para identificar el destino de archive log ID al que se puede conectar la base de datos en espera.

Se ha detectado que Extract tiene un estado detenido cuando Extract consulta la información de SCN de aplicación de la base de datos en espera (SELECT applied_scn FROM v$archive_dest where dest_id=n) y este SCN es menor que el SCN de LCR de procesamiento de Extract. En este caso, Extract no procesará el LCR y espera hasta que applied_scn sea mayor o igual que el LCR SCN de procesamiento de Extract.

STANDBY_WARNING <value>

Cantidad de tiempo antes de que se escriba un mensaje de advertencia en el archivo de informe Extract, si Extract está detenido. El valor por defecto es 60 segundos.

STANDBY_ABEND <value>

Cantidad de tiempo antes de que el Extract finalice de forma anormal, si el Extract se ha detenido. El valor por defecto es 30 minutos.

Si se especifican STANDBY_WARNING y STANDBY_ABEND, STANDBY_ABEND siempre debe ser mayor que STANDBY_WARNING.

IFILOCKSECONDS <seconds>

Válido para Db2 z/OS

Define el intervalo en <seconds>, para el que Extract retiene los bloqueos implícitos retenidos en la base de datos por las llamadas al IFCID

Los bloqueos pueden afectar a la capacidad de realizar determinadas operaciones de base de datos, como REORGS. El valor por defecto es 20 segundos, con valores mínimos y máximos de 1 segundo y 300 segundos, respectivamente. Nota: Si el parámetro IFILOCKSECONDS se define durante más tiempo, otras operaciones de base de datos como REORGS se pueden ver afectadas debido al bloqueo interno causado por las llamadas de IFI de Extract. Por lo tanto, si se produce alguna contención de bloqueo con relación a un Extract, defina el timeout de bloqueo para la operación en una duración mayor que el valor del parámetro IFILOCKSECONDS o cierre el Extract.

IGNOREDATACAPTURECHANGES NOIGNOREDATACAPTURECHANGES

Válido para Db2 LUW

Controla si Extract captura o no tablas para las que no se ha definido DATA CAPTURE CHANGES. IGNOREDATACAPTURECHANGES ignora las tablas para las que no se ha definido DATA CAPTURE CHANGES. Se utiliza si las tablas se han especificado con un comodín para asegurarse de que el proceso continúa para las tablas que sí tienen un juego de captura de cambios. Se emite una advertencia en el log de errores para las tablas que se han omitido. El valor por defecto es NOIGNOREDATACAPTURECHANGES.

INCLUDEREGIONID INCLUDEREGIONIDWITHOFFSET

Válido para Extract para Oracle.

Estas opciones soportan el tipo de dato TIMESTAMP WITH TIME ZONE de Oracle especificado como TZR (que representa la región de zona horaria, como US/Pacific). Por defecto, Extract finaliza de forma anormal en TIMESTAMP WITH TIME ZONE si incluye una región de zona horaria. Estas opciones le permiten manejar este registro de hora según el tipo de base de datos de destino.

Cuando Extract detecta que el tipo de dato de origen es TIMESTAMP y que hay un token de asignación ID de región, Replicat aplica el registro de hora de la siguiente manera:

Se aplica un TIMESTAMP WITH TIME ZONE con TZR si la versión de Oracle de destino lo soporta.
Se aplica un registro de hora con un desplazamiento de UTC a una base de datos heterogénea o a una versión anterior de Oracle que no soporta TIMESTAMP WITH TIME ZONE con TZR.

INCLUDEREGIONID

Válido para extracción integrada para Oracle.

INCLUDEREGIONID está en desuso para Oracle GoldenGate 19c (19.1.0). Desde Oracle GoldenGate 19c (19.1.0) en adelante, TIMESTAMP WITH TIME ZONE con datos de región ID se incluye por defecto, incluida la carga inicial.

Se utiliza al replicar desde un origen de Oracle a un destino de Oracle de la misma versión o posterior. Cuando se especifica INCLUDEREGIONID, Extract agrega un índice de columna y el valor TMZ de dos bytes como token de asignación de zona horaria y lo muestra a la pista en el formato UTC de YYYY-MM-DD HH:MI.SS.FFFFFF +00:00.

INCLUDEREGIONIDWITHOFFSET

Válido para extracción integrada para Oracle.

Utilice esta opción para convertir la región ID en valor de desplazamiento de hora y minutos (+06:00 como ejemplo). Si no se especifica la opción, el registro de hora siempre se escribe en el archivo de pista en UTC y la zona horaria siempre es +00:00.

Si necesita conservar el valor de zona horaria en hora y minutos en lugar de UTC, se puede utilizar esta opción.

En los siguientes casos, se fuerza la activación de la opción para conservar la zona horaria <value> en hora y minutos <offset>:

Formato de archivo de pista antiguo porque Replicat no soporta la región ID.
Formato XML, TEXT y SQL porque no soportan la región ID.

INCLUDETAG {<tag>| +}

Válido para Extract. (Solo para Oracle)

Utilice INCLUDETAG <tag> para incluir operaciones DDL etiquetadas específicas en los archivos de pista. El valor de la etiqueta puede tener hasta 2000 dígitos hexadecimales (0-9 A-F).

Para evitar conflictos, no utilice INCLUDETAG junto con EXCLUDETAG.

Ejemplo: tranlogoptions includetag 00

LOB_CHUNK_SIZE

Válido para SQL Server, PostgreSQL.

Si tiene grandes tamaños de datos LOB, puede ajustar LOB_CHUNK_SIZE del valor por defecto de 4000 bytes a un valor superior de hasta 65535 bytes, para que el tamaño de recuperación aumente, lo que reduce los viajes necesarios para recuperar todo LOB

Ejemplo: TRANLOGOPTIONS LOB_CHUNK_SIZE 8000

(PostgreSQL) Especifica el tamaño del fragmento para los datos LOB (CLOB/BLOB) que se utilizarán para transferir en COM. Su unidad está en bytes. Los valores mínimos y máximos de lob_chunk_size se encuentran entre 4000 y 65535 bytes.

LOGREADTIMEOUT

Válido para Extract para PostgreSQL versión 12 y posterior.

Activa o desactiva la opción wal_sender_timeout para el proceso de remitente de WAL.

La opción value sólo puede ser un valor entero, con 60000 milisegundos como valor por defecto. El valor máximo es 2147483647 milisegundos y el valor mínimo es 0 milisegundos.

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

Válido para Extract en modo de captura integrado para Oracle Standard o Enterprise Edition 12c o posterior.

Transfiere parámetros y valores al servidor de minería de logs de Oracle AI Database cuando Extract está en modo de captura integrada. La entrada debe tener el formato <parameter value>, como en:

TRANLOGOPTIONS INTEGRATEDPARAMS (downsream_real_time_mine Y)

Las especificaciones de parámetros válidas y sus valores son los siguientes:

max_sga_size

Especifica la cantidad de memoria SGA que utiliza el servidor de gestión de logs de la base de datos. Puede ser un entero positivo en megabytes. El valor por defecto es 1 GB si streams_pool_size es superior a 1 GB; de lo contrario, es el 75% de streams_pool_size.

parallelism

Especifica el número de procesos que soportan el servidor de logmining de la base de datos. Puede ser un entero positivo. El valor por defecto es 2.

downstream_real_time_mine

Especifica si la captura integrada extrae o no una base de datos de minería descendente en modo de tiempo real. El valor Y especifica la captura en tiempo real y necesita que los redo logs en espera se configuren en la base de datos de minería descendente. Un valor de N especifica la captura de los archive logs enviados a la base de datos de minería descendente. El valor por defecto es N.

enable_procedural_replication

Activa la replicación de procedimiento en la captura. La replicación de procedimiento está desactivada por defecto. Un valor de Y permite la replicación de procedimiento. Una vez que esta opción está activada para un Extract, permanece activada. El valor del parámetro no se puede volver a activar.

MANAGESECONDARYTRUNCATIONPOINT NOMANAGESECONDARYTRUNCATIONPOINT

Válido para PostgreSQL.

MANAGESECONDARYTRUNCATIONPOINT es el valor por defecto y controla el valor restart_lsn del espacio de replicación para el Extract específico.

NOMANAGESECONDARYTRUNCATIONPOINT no mueve la ranura de replicación de Extract y, normalmente, solo se utiliza para fines de desarrollo y prueba en los que se debe cambiar la posición de un Extract a un LSN anterior desde el LSN de recuperación de Extract. Si se utiliza, el log de escritura anticipada PostgreSQL seguirá creciendo y consumiendo espacio en disco.

MAXAUTOCMTTRANSSIZE (<range>, <default>)

Válido solo para DB2 para i

Proporciona el rango del tamaño máximo de transacción de confirmación automática.

Db2 para los registros de confirmación automática de i (el asiento tiene un CCID igual a 0) no tiene un registro de confirmación en el asiento y, por lo tanto, Oracle GoldenGate debe crear una transacción implícita para incluir estos registros en la pista. El valor por defecto permite incluir un único registro en una sola transacción, lo que mantiene la precisión del tiempo de E/S indicado para cada registro porque el tiempo de E/S se basa en la confirmación de la transacción.

Este parámetro define el número máximo de registros que se incluirán en una transacción creada implícitamente, pero el número podría ser menor si se ve cualquier otro tipo de entrada en el asiento antes de que se alcance el máximo. Esta respuesta evita problemas de superposición de puntos de control en registros que pertenecen a registros confirmados explícitamente.

Si se define el valor de este parámetro en 1 (el defulat), se proporcionará un tiempo de E/S preciso para cada registro de la pista para los registros que se confirman automáticamente (tener un CCID de 0 en el asiento contable), a expensas del rendimiento potencial de la extracción. El valor de este parámetro también afecta al tamaño máximo potencial de una transacción almacenada en caché para estos registros en la memoria. Si se define en un valor inferior, la memoria de transacción será menor si Extract puede almacenar el número máximo de entradas por transacción implícita. Por definición, solo puede haber una transacción implícita en la memoria en un momento dado, ya que cualquier otro registro de transacción provocará una confirmación inmediata en la pista de cualquier registro de una transacción implícita que ya esté en la memoria.

El rango predeterminado está entre 1 y 10000 y el valor predeterminado es 1.

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

Válido para Oracle GoldenGate Extract para Oracle.

Especifica las credenciales de conexión para que Extract se conecte a una base de datos de minería de Oracle descendente para interactuar con el servidor de logmining. Se puede utilizar en lugar de la opción MININGUSERIDALIAS si no se está utilizando un almacén de credenciales de Oracle GoldenGate.

Este usuario debe:

Tener los privilegios otorgados en los roles OGG_CAPTURE y OGG_APPLY para Oracle GoldenGate 26ai y posteriores. Para Oracle Database 21c, se deben aplicar los privilegios otorgados en dbms_goldengate_auth.grant_admin_privilege.
Ser el usuario que emite los comandos MININGDBLOGIN o MININGDBLOGIN USERIDALIAS y REGISTER EXTRACT o UNREGISTER EXTRACT para el grupo Extract asociado a este MININGDBLOGIN USERIDALIAS.
No cambiarse.

Indica a Oracle GoldenGate que utilice una Conexión al Sistema Operativo para Oracle, no una Conexión de Usuario a la Base de Datos. Utilice este argumento solo si la base de datos permite la autenticación en el nivel de sistema operativo. Si se omite la autenticación de nivel de base de datos, se elimina la necesidad de actualizar los archivos de parámetros de Oracle GoldenGate si las contraseñas de la aplicación cambian con frecuencia.

Para utilizar esta opción, debe existir el nombre del usuario que coincida en la base, en relación con el valor del parámetro OS_AUTHENT_PREFIX de inicialización de Oracle. El valor definido con OS_AUTHENT_PREFIX se concatena al principio del nombre de cuenta del sistema operativo de un usuario y, a continuación, se compara con el nombre de la base de datos. Estos dos nombres deben coincidir.

Cuando OS_AUTHENT_PREFIX se define en ' ' (una cadena nula), el nombre de usuario se debe crear con IDENTIFIED EXTERNALLY. Por ejemplo, si el nombre de usuario OS es ogg, utilizaría lo siguiente para crear el usuario de base de datos:

CREATE USER ogg IDENTIFIED EXTERNALLY;

Cuando OS_AUTHENT_PREFIX se define en OPS$ u otra cadena, el nombre <user> se debe crear con el formato de:

<OS_AUTHENT_PREFIX_value><OS_user_name>

Por ejemplo, si el nombre OS <user> es ogg, utilizaría lo siguiente para crear la base de datos <user>:

CREATE USER ops$ogg IDENTIFIED BY oggpassword;

<user>

Especifica el nombre del usuario o una cadena SQL*Net de conexión de la base de información de minería.

<password>

Contraseña del usuario. Utilícelo cuando sea necesaria la autenticación de la base de datos para especificar la contraseña para el usuario. Si la contraseña se ha cifrado mediante el comando ENCRYPT PASSWORD, proporcione la contraseña cifrada; en caso contrario, utilice la contraseña de texto no cifrada. Si la contraseña es sensible a mayúsculas/minúsculas, escríbala de esa forma. Si cambia el usuario ID o la contraseña, el cambio se debe realizar en los archivos de parámetros de Oracle GoldenGate, incluido el nuevo cifrado de la contraseña si es necesario.

<algorithm>

Especifica el cifrado <algorithm> que se ha utilizado para cifrar <password> con ENCRYPT PASSWORD. Puede ser una de las siguientes:

AES128
AES192
AES256

ENCRYPTKEY {<key_name> | DEFAULT}

Especifica la clave de cifrado especificada con ENCRYPT PASSWORD.

ENCRYPTKEY <key_name> especifica el nombre lógico de una clave de cifrado creada por la persona en el archivo de consulta ENCKEYS. Utilice si se ha utilizado ENCRYPT PASSWORD con la opción KEYNAME <key_name>.
ENCRYPTKEY DEFAULT indica a Oracle GoldenGate que utilice una clave aleatoria. Uso si se ha utilizado ENCRYPT PASSWORD con la opción KEYNAME DEFAULT.

SYSDBA

Especifica que el usuario se conecta como sysdba.

MININGUSERIDALIAS <alias>

Válido para Extract para Oracle.

Especifica el alias de las credenciales de conexión que Extract utiliza para conectarse a una base de datos de minería de Oracle descendente para interactuar con el servidor de logmining. Se puede utilizar en lugar de MININGUSER si se está utilizando un almacén de credenciales de Oracle GoldenGate.

Este alias debe ser:

Asociado a una credencial de conexión de usuario de base de datos almacenada en el almacén de credenciales local de Oracle GoldenGate. Este usuario debe tener los privilegios otorgados en dbms_goldengate_auth.grant_admin_privilege para Oracle Database 21c y versiones anteriores, y los roles OGG_CAPTURE y OGG_APPLY para Oracle AI Database 26ai y versiones posteriores.
Usuario que emite los comandos MININGDBLOGIN o MININGDBLOGINALIAS y REGISTER EXTRACT o UNREGISTER EXTRACT para el grupo Extract asociado a este MININGUSERIDALIAS.

Este alias y usuario no se deben cambiar mientras Extract está en modo de captura integrada.

MIXEDENDIAN [ON OFF]

Válido para Db2 LUW con extracción principal de Oracle GoldenGate

Oracle GoldenGate Extract para Db2 LUW soporta la captura entre endios en la que la base de datos y Oracle GoldenGate se ejecutan en distintos servidores de orden de bytes. La detección del orden de bytes es automática para la versión 10.5 y posteriores de la base de datos LUW Db2. Si necesita desactivar la detección automática en Db2 LUW 10.5, puede sustituirla especificando este parámetro. Para la versión 10.1, el parámetro se debe utilizar en el archivo de parámetros Extract para la captura de cross-endian. De manera predeterminada, el valor se establece en OFF para la versión 10.1.

Sintaxis:

TRANLOGOPTIONS MIXEDENDIAN [ON|OFF]

ON: si se define, Extract asume que la base de datos y Oracle GoldenGate se están ejecutando en servidores con un orden de bytes diferente y se realiza la conversión de reversión de bytes necesaria.

OFF: si se define, Extract asume que la base de datos y Oracle GoldenGate se están ejecutando en servidores con el mismo orden de bytes y no se realiza ninguna conversión de reversión de orden de bytes.

MANAGECDCCLEANUP NOMANAGECDCCLENUP

Válido para el servidor SQL.

MANAGECDCCLEANUP es el valor por defecto y recomendado que indica al Extract que valide la existencia del trabajo de limpieza de CDC de Oracle GoldenGate o la tarea Depurar datos de cambio, según la arquitectura y la versión de Oracle GoldenGate.

Para todas las versiones de arquitectura clásica de Oracle GoldenGate y para las versiones de microservicios anteriores a Oracle GoldenGate 21.4, utilice el programa ogg_cdc_cleanup_setup.bat/sh para instalar el trabajo de limpieza de CDC de Oracle GoldenGate y las tablas y procedimientos almacenados asociados.

Para instalaciones de Oracle GoldenGate Microservices 21.4 y posteriores, cree una tarea Depurar datos de cambio desde la página Tareas de la sección Configuración del servicio de administración de WebUI. La tarea Depurar Datos de Cambio crea los procedimientos almacenados necesarios y las tablas asociadas, y gestiona la función de depuración en Oracle GoldenGate y no mediante el trabajo del agente del servidor SQL.

La opción NOMANAGECDCCLEANUP indica a Extract que no compruebe la existencia del trabajo de limpieza de CDC de Oracle GoldenGate ni de la tarea Depurar datos de cambio. Esta no es una opción recomendada para entornos de producción, pero se puede utilizar para probar un Extract sin tener que crear la tarea o el trabajo de limpieza de CDC de Oracle GoldenGate.

PERFORMANCEPROFILE HIGH MEDIUM LOW_RES LOW_WORKLOAD

Válido para Extract en modo Integrated Capture.

Para ajustar la captura integrada.

Se puede definir en HIGH, MEDIUM (valor por defecto) o LOW_RES. Ayuda a lograr un mejor rendimiento agrupando los parámetros que afectan al rendimiento. Una vez que se configura el perfil de rendimiento, esta opción configura automáticamente los parámetros relevantes para lograr el rendimiento y la latencia necesarios.

La opción HIGH permite procesar la carga de trabajo alta con un rendimiento continuo de manera más eficiente en términos de replicación completa. La opción HIGH aumenta el tamaño del buffer del archivo de pista a 4 MB y reduce los valores de la opción de fin de archivo y vaciado a 0,1 segundo.
La opción MEDIUM define el tamaño del buffer del archivo de pista en 1 MB y los valores para el retraso de fin de archivo y el vaciado en 1 segundo.
La opción LOW_RES se aplica cuando los recursos son bajos y se ha agregado para el despliegue restringido de memoria o recursos.
La opción LOW_WORKLOAD se utiliza con los entornos de Oracle GoldenGate para Oracle AI Database con una carga de trabajo baja, pero la latencia debe estar en segundos.

Cuando la opción HIGH está activada para cargas de trabajo de baja a media intensidad, aumenta la latencia de Extract integrada a varios segundos. Esto se debe a que la opción HIGH aumenta el tamaño del buffer de lectura de Extract a 8 MB. Sin embargo, la regla para vaciar el buffer de lectura de extracción es cuando el buffer está lleno o cuando no hay registros entrantes durante una duración de 0,2 segundos. Por lo tanto, cualquier carga de trabajo continua con una tasa de ingestión de Extract inferior a 8 MB dará como resultado una latencia de Extract integrada que superará los 1 segundo. Asegúrese de que si los ratios de ingesta de Extract (o ratios de generación de redo si se captura el 100% del redo) son inferiores al valor especificado, como ~15 MB/s para obtener una latencia de extracción de ~0,5 segundos, no utilice la opción HIGH. Si se necesita una latencia inferior al segundo, se recomienda reducir el tamaño del buffer según corresponda. Por ejemplo, defina el tamaño del buffer en un tercio del ratio de generación de redo en MB/s para obtener una latencia máxima de extracción de ~0,3 segundos.

QUERYTIMEOUT <seconds>

Válido para el servidor SQL.

Especifica el tiempo que las consultas al servidor SQL esperarán los resultados antes de informar de un mensaje de error de timeout. Esta opción toma un valor entero para representar el número de segundos. El valor por defecto del timeout de consulta es 300 segundos (5 minutos). El valor mínimo es 0 segundos (tiempo de espera infinito). El máximo es de 2147483645 segundos.

En el siguiente ejemplo, se indica al servidor SQL que espere 60 segundos para obtener resultados antes del timeout.

TRANLOGOPTIONS QUERYTIMEOUT 60

QUERYRETRYCOUNT <seconds>

Válido para Extract para el servidor SQL y MySQL.

Especifica cuántas veces se deben reintentar las llamadas al procedimiento almacenado CDC utilizado por Extract, en caso de que se produzca un timeout de juego de resultados.

QUERYRETRYCOUNT se puede especificar para volver a intentarlo varias veces. Si fallan todos los intentos de reintento, Extract finaliza de forma anormal con el mensaje de error de timeout de conexión normal.

Para el servidor SQL, el valor por defecto es un intento de reintento, después del cual el valor mínimo (0) de abends.The del proceso es infinito, el máximo es 1000 y el valor por defecto es 1.

Para MySQL, el valor mínimo y por defecto es 50 y el máximo es 1000. No hay un valor infinito. Cualquier intento de definir QUERYRETRYCOUNT en un valor inferior al mínimo se ignorará sin errores ni advertencias.

El siguiente ejemplo hace que Extract intente realizar su llamada de procedimiento almacenado CDC 4 veces:

TRANLOGOPTIONS QUERYRETRYCOUNT 4

El siguiente ejemplo hace que Extract intente realizar su llamada de procedimiento almacenado CDC 100 veces:

TRANLOGOPTIONS QUERYRETRYCOUNT 100

READQUEUESIZE <size>

Válido para MySQL.

Especifica el tamaño de la cola interna, en bytes, para los datos de transacción. Se puede aumentar para mejorar el rendimiento. Los valores válidos son enteros del 3 al 1500. El valor por defecto es 256 bytes; empiece por el valor por defecto y evalúe el rendimiento antes de ajustar hacia arriba.

REDO_TRANSPORT_LAG_THRESHOLD <seconds>

Válido para extracción integrada en modo de minería descendente.

Supervisa la latencia de red entre una base de datos origen y una base de datos destino cuando se envían los redo logs. Si la latencia supera el umbral especificado, aparece una advertencia en el archivo de informe y aparece un mensaje de información posterior cuando la demora se reduce al nivel normal.

El valor de umbral por defecto es 30 segundos. El valor de umbral mínimo que se puede especificar es de 15 segundos.

Para obtener más información, consulte Extracción descendente.

REDO_TRANSPORT_LAG_TIMEOUT <value>

Válido para extracción integrada en modo de minería descendente.

El valor proporcionado como entrada en esta opción de parámetro es el período de tiempo durante el cual Extract esperará el redo de cada thread. Si todos los threads han esperado el timeout (en segundos) y no han recibido ningún redo, Extract finalizará de forma anormal.

REQUIRELONGDATACAPTURECHANGES NOREQUIRELONGDATACAPTURECHANGES

Válido para Db2 LUW.

Controla la respuesta de Extract cuando DATA CAPTURE se define en NONE o en CHANGES sin INCLUDE LONGVAR COLUMNS y el archivo de parámetro incluye cualquiera de los siguientes parámetros de la instancia de Oracle GoldenGate para aquellos que se necesita la presencia de imágenes anteriores para algunos o todos los valores de columna: GETBEFOREUPATES, NOCOMPRESSUPDATES y NOCOMPRESSDELETES Ambos valores de DATA CAPTURE evitan el registro de valores anteriores para las columnas LONGVAR. Si esas columnas no están disponibles para Extract, puede afectar a la integridad de los datos de destino.

REQUIRELONGDATACAPTURECHANGES

La extracción finaliza de forma anormal con un error.

NOREQUIRELONGDATACAPTURECHANGES

La extracción emite un aviso, pero continúa procesando el registro de datos.

REMOTESCHEMA <value>

Válido para Db2 z/OS Extract.

Al utilizar varias versiones de Oracle GoldenGate para Db2 z/OS Extract, debe crear varias versiones de componentes de Extract GoldenGate dentro de Db2 z/OS con diferentes nombres de esquema. El parámetro REMOTESCHEMA se utiliza para indicar al Extract qué esquema utilizar.

Consulte la Instalación de componentes de Extract en Db2 z/OS en la documentación de microservicios de Oracle GoldenGate para obtener más información.

SOURCE_OS_TIMEZONE <timezone>

Válido para Extract en modo de captura integrado para Oracle.

Especifica la zona horaria del sistema de la base de datos origen. La zona horaria del sistema de una base de datos suele estar dada por la zona horaria predeterminada de su sistema operativo y también se puede sustituir definiendo la variable de entorno TZ cuando se inicia la base de datos. Debe especificar esta opción sólo si la base de datos origen y el proceso de extracción utilizan diferentes zonas horarias del sistema. Por ejemplo, en un despliegue de captura descendente donde la base de datos origen y el proceso Extract se ejecutan en diferentes servidores en diferentes zonas horarias.

Puede especificar el valor de esta opción en un nombre de región de zona horaria o en un formulario de desplazamiento UTC y debe utilizar el mismo formulario que utiliza la base de datos origen. Por ejemplo, si la base de datos origen utiliza un formato de nombre de región como America/New_York, debe especificar America/New_York, US/Eastern o EST5EDT. Como alternativa, si la base de datos origen utiliza un formato de desplazamiento UTC como -05:00, debe utilizar la sintaxis (GMT)[+|-]hh[:mm]. Por ejemplo, GMT-05:00 o -5.

SKIPUNKNOWNEVENT

Válido para MySQL.

Puede utilizar este parámetro en el archivo de parámetros Extract para permitir omitir cualquier evento no tratado o desconocido en el log binario MySQL. Si se especifica este parámetro, Oracle GoldenGate para MySQL Extract continúa el procesamiento sin ningún error al buscar un evento que no maneja el proceso de extracción actual.

STREAMINGOPTIONS

Válido para PostgreSQL.

Utilice este parámetro para proporcionar los parámetros necesarios durante el inicio de la replicación. Consulte también Registro de Extract para PostgreSQL en la documentación de microservicios de Oracle GoldenGate.

Por ejemplo:

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

SUPPRESSNOOOPUPDATES

Válido para Extract en Oracle AI Database.

Puede controlar si las actualizaciones sin operaciones se filtran o no en Integrated Extract. El valor predeterminado es sin supresión.

TRACKSCHEMACHANGES NOTRACKSCHEMACHANGES

Válido para Db2 z/OS y MySQL

Para Oracle GoldenGate para Db2 z/OS, este parámetro permite a Extract capturar sentencias de nivel de tabla DDL y conservar un historial de los cambios que se van a utilizar para procesar DML cuando los registros de log hacen referencia a una versión de tabla anterior a la versión actual de la tabla. Esto suele ser anterior a las imágenes de actualizaciones, pero podría ser posterior a las imágenes, inserciones o supresiones si Extract se está ejecutando en una situación de retraso desde el atraso del log. Cuando Extract encuentre las operaciones DDL adecuadas, observará el número de versión de DDL y actualizará la tabla de historial DDL con la nueva información. El Extract creará un nuevo registro de TDR relacionado con el cambio en la pista también. Cuando Extract encuentre versiones anteriores de la tabla en el log, hará referencia al historial DDL para poder interpretar correctamente DDL para la versión anterior de la tabla. El cambio de DDL no se está replicando realmente, y la sincronización de los cambios en la tabla de origen sigue siendo necesaria para que el usuario los ejecute manualmente en la base de datos de destino.

Al introducir este comando, permitirá que Extract realice un seguimiento de los cambios de nivel de tabla DDL y que los metadatos de pista se actualicen, según corresponda. Para utilizar TRACKSCHEMACHANGES correctamente, los metadatos de la tabla deben estar en un estado consistente conocido, lo que significa que todas las tablas que necesitan seguimiento de versiones se deben crear y nunca alterar ni reorganizar antes de utilizar TRACKSCHEMACHANGES para que no aparezcan versiones de tabla anteriores en el log de transacciones para las operaciones de actualización o supresión. Se ha proporcionado el script ddl_update.sh para ayudar a crear un juego inicial de registros de historial DDL para la base de datos.

Para utilizar el procesamiento DDL, la base de datos se debe configurar con una tabla de historial que capture los cambios DDL de las distintas versiones de todas las tablas del sistema de base de datos. También es necesario activar las tablas del sistema para los cambios de captura de datos. Para crear y mantener la tabla de historial, se proporcionan los siguientes scripts de shell de UNIX:

ddl_create.sh: este script se utiliza para crear la tabla de historial DDL. También activa los cambios de captura de datos para las siguientes tablas del sistema:
- SYSIBM.SYSTABLES
- SYSIBM.SYSCOLUMNS
- SYSIBM.SYSINDEXES
- SYSIBM.SYSKEYCOLUSE
Ejemplo:

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

En este ejemplo, el archivo resultante, crt_ddl_hist.sql, debe ser procesado por otro programa.

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

Esto llamará a un Db2 local para realizar una conexión remota a una base de datos de mainframe para crear inmediatamente la tabla de historial DDL.
ddl_remove.sh: este script se utiliza para eliminar la tabla de historial DDL. Sin embargo, las tablas del sistema no se modifican.
ddl_update.sh: este script se debe ejecutar para establecer un punto de inicio inicial para el seguimiento de la versión DDL mediante TRACKSCHEMACHANGES. Se debe ejecutar después de la creación de la tabla de historial DDL y no se debe volver a ejecutar, a menos que la extracción se deba cambiar de posición de forma que las versiones de la tabla no se puedan ejecutar en el log de transacciones. Si se vuelve a ejecutar ddl_update.sh, solo se agregará información para las tablas que aún no estén presentes en el historial DDL.
execsql.sh: este script no se debe ejecutar directamente, sino que debe estar disponible para los otros scripts que se van a obtener. Proporciona utilidades comunes para analizar la línea de comandos y ejecutar SQL o escribirla en un archivo.

Estos scripts se pueden utilizar para crear las tablas directamente mediante una conexión Db2 o se pueden utilizar para crear archivos SQL que se pueden ejecutar en el programa de procesamiento SQL que desee. Se ha comprobado que los archivos son compatibles con Db2 remoto y SPUFI.

A continuación, se muestra una descripción de las opciones aceptadas por estos scripts:

-h muestra la ayuda de esta sintaxis.
-d dsn especifica el DSN Db2 al que conectarse.
-u userid especifica el usuario ID con el que conectarse a la base de datos.
-p password especifica la contraseña con la que conectarse a la base de datos.
-s ggschema especifica el nombre del esquema en el que se debe almacenar la tabla de historial DDL. Este esquema debe ser el mismo que GGSCHEMA en GLOBALS.
-t ddltable especifica el nombre de la tabla de historial DDL. GGS_DDL_HIST es el valor por defecto.
-f outfile especifica el nombre de un archivo en el que escribir las sentencias SQL en lugar de ejecutarlas. Si se utiliza -d, -u, se debe especificar -p si se utiliza o -f. Actualmente no se debe utilizar -t. -f se debe utilizar si solo el comando db2cli está disponible en el host remoto, ya que db2cli no puede ejecutar las sentencias SQL que se generan.

Para Oracle GoldenGate para MySQL, la replicación de DDL está soportada con la captura y la entrega. Cuando la replicación DDL está activada, Extract detecta las operaciones DDL en la tabla de la base de datos de origen, procesa la sentencia DDL, refresca los metadatos de la tabla y escribe la sentencia DDL y los metadatos en el archivo de pista. Replicat aplica estas operaciones DDL en la base de datos de destino MySQL y también selecciona la nueva versión de los metadatos de la pista y procesa las operaciones DML posteriores. Todo este proceso es fluido y no implica tiempo de inactividad, pero esto solo es posible para el escenario similar, como (MySQL a MySQL).

El parámetro TRACKSCHEMACHANGES permite capturar los cambios de metadatos de tabla posteriores a la operación DDL en las tablas de origen para que la captura pueda procesar las operaciones DML posteriores sin ningún tiempo de inactividad. Cuando TRACKSCHEMACHANGES está activado, la captura escribe un nuevo registro de TDR en la pista que contiene los nuevos metadatos en cada operación DDL seguida de los datos correspondientes. Capture no procesa y escribe la sentencia DDL en el archivo de pista, por lo que los cambios de DDL no se replican realmente en la base de datos de destino. Es necesario ejecutar manualmente la sincronización de los cambios DDL correspondientes al origen en la base de datos de destino. La ventaja de utilizar esta función es que, a diferencia de la replicación DDL, TRACKSCHEMACHANGES se puede utilizar en escenarios de replicación entre bases de datos, por ejemplo, de MySQL a Db2 z/OS.

A continuación, se muestran las consideraciones al utilizar el comando TRANLOGOPTIONS TRACKSCHEMACHANGES:

Por defecto, el parámetro TRACKSCHEMACHANGES está activado a partir de Oracle GoldenGate 23.7. Por lo tanto, los metadatos modificados también se capturan por defecto.
DDL y TRACKSCHEMCHANGES no están en conflicto. Si DDL está activado, se captura y se procesa DDL.
Para capturar los cambios de esquema, el usuario debe activar explícitamente TRACKSCHEMACHANGES en el archivo de parámetros Extract.

Cuando binlog_row_metadata no es FULL en MariaDB y MySQL, TRACKSCHEMCHANGES se desactiva con el siguiente mensaje de advertencia que se muestra en el archivo de informe 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."

La opción de parámetro TRANLOGOPTIONS NOTRACKSCHEMACHANGES permite desactivar el seguimiento de esquemas. Sin embargo, se recomienda no desactivar el seguimiento del esquema. Si desactiva el seguimiento de esquemas, se emite un mensaje de advertencia en el informe Extract de la siguiente forma:

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.

Aunque TRACKSCHMEACHANGES está activado por defecto, cuando DDL y TRACKSCHMEACHANGES no están activados en el archivo de parámetros Extract y Extract encuentra CREATE TABLE AS SELECT, la operación DDL CREATE TABLE se ignora del procesamiento y Extract captura las operaciones DML (INSERT) asociadas.

Al procesar las DML para dicha tabla, el Replicat de destino finalizará de forma anormal, ya que la tabla DDL no se replica en el destino.

La tabla del destino se debe crear manualmente en estos casos emitiendo solo la operación CREATE TABLE y no la operación CREATE TABLE AS SELECT.
Si ni TRACKSCHEMACHANGES ni DDL están activados en el archivo de parámetros Extract y se emite una operación DDL en una tabla específica que forma parte de la lista Extract, Extract finalizará de forma anormal.
Si ni TRACKSCHEMACHANGES ni DDL están activados en el archivo de parámetros Extract y se emite una operación DDL en una tabla específica que no forma parte de la lista de captura, Extract no finalizará de forma anormal

TRANCOUNT

Válido para el servidor SQL.

Permite ajustar el número de transacciones procesadas por llamada mediante Extract para extraer datos de las tablas temporales de captura de datos de cambio del servidor SQL. En función de la carga de trabajo de las transacciones, el ajuste de este valor puede mejorar el rendimiento de la tasa de captura. El valor mínimo es 1, el máximo es 100 y el valor por defecto es 10.

Ejemplo:

TRANLOGOPTIONS TRANCOUNT 20

En este ejemplo, se indica a Extract que recupere 20 transacciones a la vez de las tablas activadas para la captura de datos de cambio.

[TSLOOKUPBEGINLRI TSLOOKUPENDLRI]

Válido para Db2 LUW v 10.1 y posterior.

Al especificar un rango de LRI con estos parámetros, Extract busca el registro de hora especificado en el comando ADD o ALTER EXTRACT dentro de este rango. Esto ayuda a Extract a optimizar el proceso de búsqueda para un registro de hora concreto en el log de transacciones de la base de datos. El parámetro TSLOOKUPBEGINLRI es obligatorio mientras que TSLOOKUPENDLRI es opcional. La especificación solo de TSLOOKUPENDLRI sin TSLOOKUPBEGINLRI no es válida, lo que hace que el Extract finalice de forma anormal. Por ejemplo:

TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197, TSLOOKUPENDLRI  75207.666216
TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197

Si el registro de hora proporcionado se encuentra entre los rangos de LRI indicados o el registro de hora proporcionado cae después del registro de hora de LRI TSLOOKUPBEGINLRI, Extract comienza desde un registro con el registro de hora igual o menor que el registro de hora proporcionado.

Si el registro de hora proporcionado es anterior al registro de hora de LRI TSLOOKUPBEGINLRI, Extract se inicia desde el LRI TSLOOKUPBEGINLRI especificado. Si el registro de hora proporcionado cae después del registro de hora TSLOOKUPENDLRI, Extract finaliza de forma anormal.

USENATIVEOBJSUPPORT NOUSENATIVEOBJSUPPORT

Válido para Extract en modo de captura integrado para Oracle.

Integrated Capture agrega captura basada en redo para los tipos de dato User Defined Type (UDT) y ANYDATA. Se activa por defecto y solo se puede activar si la versión de la base de datos de origen es 12.1.0.1 o superior y la compatibilidad de la base de datos de origen es 12.0.0.0.0 o superior. Se debe utilizar Replicat de Oracle GoldenGate versión 12.1.2.1.0. Para utilizar el soporte nativo, todas las instancias de Oracle AI Database y Oracle GoldenGate deben ser de la versión 12.1.0.1 o superior para ser compatibles.

Si la captura basada en redo está activada pero un valor definido por el usuario contiene un atributo no soportado, la captura integrada vuelve a intentar capturar el valor definido por el usuario mediante la recuperación. Para conocer las limitaciones del soporte para la captura, consulte XML Data Types. Si crea tablas de objetos mediante una sentencia CREATE TABLE AS SELECT (CTAS), la captura integrada se debe configurar para capturar DML de la operación CTAS con el fin de soportar completamente las tablas de objetos. Para CTAS, consulte Cómo gestiona Oracle GoldenGate los nombres de objetos derivados en la documentación de microservicios de Oracle GoldenGate

El valor por defecto es USENATIVEOBJSUPPORT si se admite.

Active el parámetro TRANLOGOPTIONS NOUSENATIVEOBJSUPPORT en el archivo de parámetros de Oracle Extract para capturar los datos UDT como datos XML en el archivo de pista. Estos datos se pueden aplicar a cualquier columna de destino que acepte datos XML, como CLOB/TEXT/CHAR/VARCHAR, etc.

USE_ROOT_CONTAINER_TIMEZONE

Válido solo para Oracle Integrated Extract.

Este parámetro es para un entorno de CDB. Cada PDB de una CDB puede utilizar una zona horaria de base de datos diferente. Si la zona horaria de la base de datos está disponible, Extract intenta obtener la zona horaria de una PDB desde el diccionario integrado. La extracción de zona horaria requiere un parche en la base de datos de minería. Si el parche no está disponible, Extract envía una consulta a la PDB para obtener la zona horaria. Si el parche de base de datos o una conexión a la PDB no está disponible y se especifica este parámetro, Extract asume que la zona horaria de la base de datos PDB es la misma que la zona horaria de la base de datos de contenedores raíz.

VERSIONCHECK DYNAMIC IMMEDIATE

Esto es válido para el servidor SQL.

Utilice esta opción cuando desee que Extract valide las versiones de objeto CDC de los procedimientos almacenados comunes, como OracleCDCExtract y OracleGGCreateProcs, al iniciar.

DYNAMIC (valor por defecto) identifica las versiones de objeto CDC de la tabla especificada en el archivo de parámetros una vez por tabla mientras se procesan los registros.

IMMEDIATE identifica las incidencias de versión del objeto CDC por adelantado, en lugar de mientras se procesan los registros. Las bases de datos con un gran número de tablas configuradas para la captura requieren una validación de inicio más larga.

WARNCREATEASSELECT

Esto es válido para Extract para MySQL.

La operación DDL CREATE TABLE AS SELECT no está soportada y Oracle GoldenGate Extract para MySQL finaliza de forma anormal cuando encuentra este DDL. Se produce un error similar al siguiente cuando Extract finaliza de forma anormal por primera vez:

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.

Al utilizar el valor TRANLOGOPTIONS WARNCREATEASSELECT en el archivo <parameter> de Extract, Extract continúa después de emitir el siguiente mensaje de advertencia en el archivo de informe de 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.