Preparar tablas para procesamiento

En este apartado se describe el modo de preparar las tablas para su proceso. La preparación de la tabla requiere las siguientes tareas.

Garantizar la unicidad de filas para las tablas

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

A menos que se utilice una cláusula KEYCOLS en la sentencia TABLE o MAP, Oracle GoldenGate selecciona un identificador de fila para utilizarlo en el siguiente orden de prioridad:

  1. Clave primaria

  2. Primera clave única alfanuméricamente que no contiene un registro de hora ni una columna calculada no materializada.

  3. Si no existe ninguno de los tipos de clave anteriores (aunque puede haber otros tipos de claves definidos en la tabla) Oracle GoldenGate construye una pseudoclave de todas las columnas que la base de datos permite utilizar en una clave única, excluidas las que no soporta Oracle GoldenGate en una clave o las que están excluidas de la configuración de Oracle GoldenGate.

Nota: Si hay otras claves no utilizables en una tabla o si no hay ninguna clave en la tabla, Oracle GoldenGate registra un mensaje adecuado en el archivo de informe. La creación de una clave a partir de todas las columnas impide el rendimiento de Oracle GoldenGate en el sistema de origen. En el destino, esta clave hace que Replicat utilice una cláusula WHERE más grande y menos eficaz.

  1. Si una tabla no tiene una clave adecuada o si prefiere que no se utilicen las claves existentes, puede definir una clave sustituta si la tabla tiene columnas que siempre contienen valores únicos. Esta clave de sustitución se define mediante la inclusión de una cláusula KEYCOLS en el parámetro Extract TABLE y el parámetro Replicat MAP. La clave especificada sustituirá cualquier clave primaria o única existente que encuentre Oracle GoldenGate. Consulte TABLE | MAP en Reference for Oracle GoldenGate.

Tablas con una clave primaria derivada de un índice único

Si no hay una clave primaria en una tabla, MySQL promocionará un índice único a la clave primaria si la columna indexada es NOT NULL. Si hay más de uno de estos índices no nulos, el primero que se ha creado se convierte en la clave primaria. Para evitar errores de Replicat, cree estos índices en el mismo orden en las tablas de origen y destino.

Por ejemplo, supongamos que las tablas de origen y destino denominadas ggvam.emp tienen columnas denominadas primero, medio y último, y todas están definidas como NOT NULL. Si crea índices únicos en el siguiente orden, Oracle GoldenGate finalizará de forma anormal en el destino porque las definiciones de tabla no coinciden.

Origen:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

Destino:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

El resultado de esta secuencia es que MySQL promueve el índice en la columna de origen "first" a la clave primaria y promueve el índice en la columna de destino "last" a la clave primaria. Oracle GoldenGate seleccionará las claves primarias como identificadores cuando cree su registro de metadatos y los metadatos no coincidirán. Para evitar este error, decida qué columna desea ascender a la clave primaria y cree ese índice en primer lugar en el origen y el destino.

Especificación de su propia clave para que Oracle GoldenGate la utilice

Si una tabla no tiene uno de los tipos anteriores de identificadores de fila, o si prefiere que no se utilicen esos identificadores, puede definir una clave de sustitución si la tabla tiene columnas que siempre contienen valores únicos. Para definir esta clave de sustitución, incluya una cláusula KEYCOLS en el parámetro Extract TABLE y el parámetro Replicat MAP. La clave especificada sustituirá cualquier clave primaria o única existente que encuentre Oracle GoldenGate.

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

Si una tabla de destino no tiene una clave primaria o una clave única, pueden existir filas duplicadas. En este caso, Oracle GoldenGate puede actualizar o suprimir demasiadas filas de destino, lo que provoca que los datos de origen y destino no estén sincronizados sin que los mensajes de error 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.

Consideraciones sobre Disparadores y Restricciones en Cascada

Disparadores

Desactive los disparadores en las tablas de destino o modifíquelos para ignorar los cambios realizados por el usuario de la base de datos de Oracle GoldenGate. Oracle GoldenGate replica el DML que resulta de un disparador. Si se activa el mismo disparador en la tabla de destino, se convierte en redundante debido a la versión replicada y la base de datos devuelve un error.

Consideraciones sobre las Restricciones en Cascada

Las actualizaciones y supresiones en cascada capturadas por Oracle GoldenGate no se registran en el log binario, por lo que no se capturan. Esto es válido para MySQL y MariaDB. Por ejemplo, al ejecutar la sentencia delete en la tabla principal con una relación principal-secundaria entre tablas, las supresiones en cascada (si las hay) se producen para la tabla secundaria, pero no se registran en el log binario. Solo el registro de supresión o actualización de la tabla principal se registra en el log binario y lo captura Oracle GoldenGate.

Consulte https://mariadb.com/kb/en/replication-and-foreign-keys/ y https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html para obtener más información.

Para manejar correctamente la replicación de operaciones en cascada, se recomienda desactivar las supresiones y actualizaciones en cascada en el origen y el código de la aplicación para suprimir o actualizar explícitamente los registros secundarios antes de modificar el registro principal. Como alternativa, debe asegurarse de que la tabla principal de destino tenga las mismas restricciones en cascada configuradas que la tabla principal de origen, pero esto podría provocar una condición de no sincronización entre el origen y el destino, especialmente en casos de replicación bidireccional.