Preparar logs de transacciones de z/OS Db2 para Oracle GoldenGate

Descubra cómo configurar el registro de transacciones Db2 para soportar la captura de datos por parte de Oracle GoldenGate Extract.

Oracle GoldenGate puede capturar datos de transacción Db2 de los logs activos y archivados. Siga estas directrices para configurar los logs para que Extract pueda capturar datos.

Para activar la captura de cambios para Oracle GoldenGate para Db2 z/OS, consulte Activación de TRANDATA para bases de datos que no sean de Oracle

Activar acceso a registros de log

Active la clase de rastreo 1 de supervisión Db2 ("TRACE(MONITOR) CLASS(1)") para que Db2 permita que Extract lea el log activo. El destino por defecto de OPX es suficiente, porque Oracle GoldenGate no utiliza un destino.

Para iniciar el rastreo manualmente

Conéctese a Db2 como usuario Db2 con el privilegio TRACE o al menos con la autoridad SYSOPR.
Ejecute el siguiente comando:

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

Para iniciar el rastreo automáticamente cuando se inicia Db2

Realice una de las acciones siguientes:

Defina MONITOR TRACE en "YES" en el panel de rastreo de instalación DSNTIPN.
Defina 'DSN6SYSP MON=YES ' en el trabajo de instalación DSNTIJUZ, como se describe en la Guía de instalación de UDB Db2.

Nota: El ID de autorización principal, o uno de los ID de autorización secundarios, del ejecutor del plan ODBC también debe tener el privilegio MONITOR2.

Tamaño y retención de logs

Se registran más datos cuando las tablas se definen con DATA CAPTURE CHANGES que cuando se definen con DATA CAPTURE NONE. Si se cumple alguna de las siguientes condiciones, es posible que deba aumentar el número y el tamaño de los logs activos y archivados.

Sus aplicaciones generan grandes cantidades de datos Db2.
Las aplicaciones tienen confirmaciones poco frecuentes.
Espera detener el Extract durante largos períodos.
Su red es poco fiable o lenta.

Utilice el parámetro del sistema DSN6LOGP MAXARCH en el trabajo de instalación DSNTIJUZ para controlar la retención de logs.

Conserve suficientes datos de log para que Extract pueda volver a empezar desde sus puntos de control después de detenerlos o después de una interrupción no planificada. Extract debe tener acceso al log que contiene el inicio de la unidad de trabajo sin confirmar más antigua y todos los logs después de eso.

Si los datos que necesita Extract durante el procesamiento no se han retenido, ya sea en línea o en archive logs, puede que se necesite una de las siguientes acciones correctivas:

Modifique Extract para capturar desde un momento posterior para el que los datos de log estén disponibles (y acepte la posible pérdida de datos en el destino).
Resincronice las tablas de origen y destino y, a continuación, vuelva a iniciar el entorno de Oracle GoldenGate. Nota: La documentación de IBM ofrece recomendaciones para mejorar el rendimiento de las lecturas de log. En particular, puede utilizar buffers de salida de log grandes, logs activos grandes y realizar archivos en el disco.

Uso de archive logs en cinta

Oracle GoldenGate puede leer archive logs Db2 en cinta, lo que degrada el rendimiento. Por ejemplo, Db2 reserva archivos de cinta para una única tarea de recuperación, lo que hace que Extract no pueda leer una cinta de archivo que se esté utilizando para recuperar una tabla hasta que finalice la recuperación. Puede utilizar DFHSM o una herramienta equivalente para mover los archive logs sin problemas entre el almacenamiento DASD en línea y la cinta, pero Extract tendrá que esperar hasta que finalice la transferencia. Los retrasos en el procesamiento de extracciones aumentan la latencia entre los datos de origen y destino.

Si Oracle GoldenGate Extract puede o va a leer en cinta, ya sea física o virtual, se recomienda asegurarse de que se tengan en cuenta los siguientes ZPARMs:

DESALTAR

El parámetro del subsistema DEALLCT determina el tiempo durante el cual se debe permitir que una unidad de cinta de lectura de archivo permanezca sin usar antes de que se desasigne.

Actualización: opción 43 en el panel DSNTIPB

DSNZPxxx: DSN6LOGP DEALLCT

Oracle recomienda que DEALLCT se defina en 0, 1 (1 segundo retraso de desasignación). El valor por defecto es anular la asignación inmediatamente. Esto evitará que Db2 reasigne inmediatamente una cinta entre las lecturas de Extract.

MÁXIMA

El parámetro del subsistema MAXRTU especifica el número máximo de unidades de cinta dedicadas que se pueden asignar a volúmenes de cinta archive log de lectura simultánea.

Actualización: opción 43 en el panel DSNTIPB

DSNZPxxx: DSN6LOGP MAXRTU

El valor predeterminado es 2 unidades de cinta, pero se debe establecer en el número de procesos esperados que se pueden leer simultáneamente desde la cinta + 1. Por ejemplo, si hay 4 extracciones y otras 2 aplicaciones que pueden leer de cintas, MAXRTU debe ser al menos 7 (4 + 2 + 1).

Para obtener el mejor rendimiento y menos retrasos al leer en cinta, Oracle GoldenGate Extract debe utilizar:

TRANLOGOPTIONS BUFSIZE 33554432

Esta será una indicación de que Extract lea hasta 32 MB a la vez desde el log de transacciones, en lugar del valor por defecto de 1 MB por lectura. Este valor no aumentará las asignaciones de memoria que Oracle GoldenGate utiliza en z/OS, ya sea ECSA (64 bytes) o memoria compartida de 64 bits (1 MB). Las asignaciones de memoria transitoria Db2 pueden aumentar mientras que Extract lee los buffers grandes.

Además, en el archivo de parámetros Extract, antes del parámetro DBLOGIN, también se puede utilizar lo siguiente para proporcionar la capacidad de ajustar aún más el buffer de comunicación TCP del controlador Db2. Por ejemplo:

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

Esto informaría al controlador Db2 para que utilice 512 KB para los buffers de envío y receptor. Se pueden utilizar otros valores y se pueden ajustar para cada instalación.

Vaciados de log de control

Al leer el registro de transacciones, Extract no procesa una transacción hasta que captura el registro de confirmación. Si el registro de confirmación está en un bloque de datos que no está lleno, no se puede capturar hasta que se genere más actividad de log para completar el bloque. La API que Extract utiliza para leer los logs solo recupera bloques de datos físicos completos.

Un retraso en la recepción de bloques que contienen confirmaciones puede provocar latencia entre los datos de origen y de destino. Si las aplicaciones no están generando suficientes registros de log para rellenar un bloque, Extract genera registros de log emitiendo sentencias SAVEPOINT y COMMIT hasta que el bloque se llena de una forma u otra y se libera.

En un grupo de uso compartido de datos, cada llamada de API hace que Db2 vacíe los bloques de datos de todos los miembros activos, lo que elimina la necesidad de que Extract realice vaciados.

Para evitar que Extract realice vaciados, utilice el parámetro Extract TRANLOGOPTIONS con la opción NOFLUSH.