Preparación de Tablas para el Proceso

Los siguientes atributos de tabla se deben abordar en un entorno de Oracle GoldenGate.

Desactivación de Disparadores y Restricciones en Cascada

Desactive los disparadores, las restricciones de supresión en cascada y las restricciones de actualización en cascada en las tablas Sybase de destino o modifíquelas para ignorar los cambios realizados por el usuario de la base de datos Oracle GoldenGate. Oracle GoldenGate replica el DML que resulta de un disparador o restricción en cascada. Si se activa el mismo disparador o restricción en la tabla de destino, se vuelve redundante debido a la versión replicada y la base de datos devuelve un error. Tenga en cuenta el siguiente ejemplo, donde las tablas de origen son emp_src y salary_src y las tablas de destino son emp_targ y salary_targ.

  1. Se emite una supresión para emp_src.

  2. Aplica una supresión en cascada a salary_src.

  3. Oracle GoldenGate envía ambas supresiones al destino.

  4. La supresión principal llega primero y se aplica a emp_targ.

  5. La supresión principal aplica en cascada una supresión a salary_targ.

  6. La supresión en cascada de salary_src se aplica a salary_targ.

  7. No se puede ubicar la fila porque ya se eliminó en el paso 5.

Para configurar Replicat para desactivar los disparadores de destino al inicio de su sesión de base de datos, realice los siguientes pasos:

  1. Asigne al usuario de Replicat el rol de replicación.

  2. Agregue la siguiente sentencia de parámetro al nivel raíz del archivo de parámetros Replicat.

SQLEXEC "set triggers off"

Asignación de identificadores de fila

Oracle GoldenGate necesita algún tipo de identificador de fila único en las tablas de origen y destino para localizar las filas de destino correctas para las actualizaciones y supresiones replicadas.

Limitación de Cambios de Fila en Tablas que No Tienen una Clave

Si una tabla de destino no tiene ninguna clave primaria o única, pueden existir filas duplicadas. Es posible que Oracle GoldenGate actualice o suprima demasiadas filas en la tabla de destino, lo que provoca que los datos de origen y destino no estén sincronizados sin mensajes de error que le avisen. Para limitar el número de filas que se actualizan, utilice el parámetro DBOPTIONS con la opción LIMITROWS en el archivo de parámetros Replicat. LIMITROWS puede aumentar el rendimiento de Oracle GoldenGate en el sistema de destino porque solo se procesa una fila.

Replicación de Datos Cifrados

Oracle GoldenGate soporta columnas que están cifradas con una contraseña cifrada por el sistema, pero no columnas cifradas con una contraseña definida por el usuario. Compruebe las tablas desde las que desea capturar datos con las siguientes limitaciones de Oracle GoldenGate:

Las columnas cifradas se cifran en los archivos de datos y en el log, por lo que Extract se debe configurar para recuperar los valores de texto no cifrado de la base de datos. Para disparar esta recuperación, utilice las opciones FETCHCOLS y FETCHMODCOLS[EXCEPT] del parámetro Extract TABLE. FETCHCOLS fuerza una recuperación de valores que no están en el log, y FETCHMODCOLS o FETCHMODCOLS[EXCEPT] fuerza una recuperación de valores que están en los logs. Estos parámetros se utilizan juntos para garantizar que las columnas cifradas siempre se recuperen de la base de datos.

A continuación, se muestra un ejemplo de cómo configurar Extract para que admita el cifrado. En este ejemplo, la columna cifrada es cardnum.

TABLE ab.payments, FETCHCOLS (cardnum), FETCHMODCOLS (cardnum);

Preparación de los logs de transacciones

Para capturar operaciones DML, Oracle GoldenGate lee los logs en línea. Para garantizar la continuidad y la integridad del procesamiento de Oracle GoldenGate, los logs se deben configurar como se indica en las siguientes secciones:

Inicialización del punto de truncamiento secundario

Establezca un punto de truncamiento de log secundario en el sistema de origen antes de ejecutar el proceso de extracción de Oracle GoldenGate. Extract utiliza el punto de truncamiento secundario para identificar los datos que quedan por procesar.

Para inicializar el punto de truncamiento secundario, conéctese a la base de datos como usuario con privilegios sa_role y, a continuación, ejecute el siguiente comando:

dbcc settrunc( 'ltm', valid )

Por defecto, Extract gestionará el punto de truncamiento secundario una vez que se haya establecido. No permita que Extract se pare más tiempo del necesario; de lo contrario, el log podría llenarse y la base de datos se detendrá. La única forma de resolver este problema es desactivar el punto de truncamiento secundario y gestionarlo fuera de Oracle GoldenGate y, a continuación, depurar el log de transacciones. Los datos que Extract no haya procesado aún se perderán y tendrá que volver a sincronizar los datos de origen y destino.

Para controlar cómo se gestiona el punto de truncamiento secundario, utilice el parámetro TRANLOGOPTIONS. Para obtener más información, consulte Reference for Oracle GoldenGate for Windows and UNIX.

Ajuste de tamaño y retención de logs

Mantenga suficientes datos de log en el sistema de origen para que Extract pueda volver a empezar desde sus puntos de control después de detenerlo o de que se produzca 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 posteriores. Para determinar dónde están los puntos de control de Extract, utilice el comando INFO EXTRACT. Para obtener más información sobre INFO EXTRACT, consulte Reference for Oracle GoldenGate for Windows and UNIX.

Si los datos que necesita Extract durante el procesamiento no se conservan, ya sea en logs en línea o de copia de seguridad, puede ser necesaria una de las siguientes acciones correctivas:

Asegúrese de no utilizar opciones de copia de seguridad o archivo que hagan que los archivos de almacenamiento antiguos se sobrescriban mediante nuevas copias de seguridad en el sistema de origen. Las nuevas copias de seguridad deben ser archivos independientes con nombres diferentes de los anteriores. Esto garantiza que si Extract busca un log concreto, siga existiendo y también garantiza que los datos estén disponibles en caso de que sea necesario para un caso de soporte.

Activación del registro de transacciones

Utilice el comando ADD TRANDATA para marcar cada tabla de origen para la replicación. Este comando utiliza los procedimientos del sistema Sybase sp_setreptable y sp_setrepcol. ADD TRANDATA es la forma recomendada de marcar las tablas, en lugar de utilizar esos procedimientos a través de la interfaz de la base de datos, pero el propietario o el administrador del sistema pueden utilizarlas si es necesario. Para obtener más información, consulte la documentación de Sybase.

Para marcar tablas para replicación con ADD TRANDATA:

Ejecute el comando ADD TRANDATA para cada tabla que se va a marcar. La sintaxis del comando ADD TRANDATA es:

ADD TRANDATA SCHEMA.TABLE LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED

LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED controla si los datos LOB nunca se propagan, solo se propagan si se cambian (valor por defecto) o siempre se propagan. LOBSIFCHANGED es el valor por defecto si no se especifica ninguna opción de LOB. El comando ADD TRANDATA sobrescribirá la configuración de replicación de LOB que está definida actualmente para la tabla.

Nota: Algunas opciones de ADD TRANDATA activan la opción ALWAYS_REPLICATE de sp_setrepcol. Si una columna LOB contiene un valor NULL y, a continuación, otra columna de la tabla se actualiza (pero no LOB), no se capturará LOB aunque ALWAYS_REPLICATE esté activado.