Preparar tablas para procesamiento

Debe realizar las siguientes tareas para preparar las tablas para su uso en un entorno de Oracle GoldenGate para Db2 LUW.

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 LUW Db2 de destino. 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.

Se emite una supresión para emp_src.
Aplica una supresión en cascada a salary_src.
Oracle GoldenGate envía ambas supresiones al destino.
La supresión principal llega primero y se aplica a emp_targ.
La supresión principal aplica en cascada una supresión a salary_targ.
La supresión en cascada de salary_src se aplica a salary_targ.
No se puede ubicar la fila porque ya se eliminó en el paso 5.

Garantía de la Unicidad de Filas para Tablas

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.

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:

Clave primaria
Primera clave única alfanuméricamente que no contiene un registro de hora ni una columna calculada no materializada.
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.
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. 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. Consulte TABLE \| MAP en Referencia de parámetros y funciones para Oracle GoldenGate.

Uso de KEYCOLS para especificar una clave personalizada

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.

Prevención de cambios clave

No agregue columnas a una clave después de que Oracle GoldenGate empiece a extraer datos de la tabla. Esta regla se aplica a una clave primaria, una clave única, una clave KEYCOLS o una clave de todas las columnas. Db2 LUW no proporciona una imagen anterior para las columnas que se agregan a una tabla. Si alguna de las columnas de una clave se actualiza en el origen, Oracle GoldenGate necesita una imagen anterior para compararla con los valores actuales de la tabla de destino cuando replica la actualización.

Mantenimiento de Tablas de Consultas Materializadas

Para mantener la paridad entre las tablas de consulta materializada (MQT) de origen y destino, replique las tablas base, pero no los MQT. La base de datos de destino mantiene los MQT en función de los cambios que aplica Replicat a las tablas base.

Las siguientes son las reglas para configurar estas tablas:

Incluya las tablas base en las sentencias TABLE y MAP.
No incluya MQT en las sentencias TABLE y MAP.
Los comodines se pueden utilizar en sentencias TABLE y MAP, aunque puedan resolver nombres MQT junto con nombres de tabla normales. Oracle GoldenGate excluye automáticamente los MQT de las listas de tablas con comodines. Sin embargo, cualquier MQT que se muestre explícitamente en una sentencia Extract TABLE por nombre hará que Extract finalice de forma anormal.

Creación de una Tabla Temporal

Una tabla temporal es una tabla que mantiene el historial de sus datos y el período de tiempo en que sus datos son válidos. Las tablas temporales se utilizan en Oracle GoldenGate para realizar un seguimiento de todas las filas antiguas que se suprimen o actualizan en la tabla. Las tablas temporales también se utilizan para mantener la validez de negocio de sus filas y datos. Por ejemplo, Oracle GoldenGate realiza un seguimiento del período de tiempo durante el cual una fila es válida. Hay tres tipos de tablas temporales, período de sistema, período de aplicación y tabla bitemporal.

Conversión a una tabla temporal

Puede convertir una tabla ya existente en una tabla temporal, lo que cambia la estructura de la tabla. En este apartado se describe cómo cambia la estructura de las tablas. La siguiente tabla existente de ejemplo se convierte en los tres tipos de tablas temporales en los ejemplos de esta sección:

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

Ejemplo 1 Conversión de una tabla existente en una tabla temporal de período del sistema

Para convertir la tabla existente de ejemplo en una tabla temporal de período del sistema, agregue columnas SYSTEM_PERIOD, transaction id y período SYSTEM_TIME como en lo siguiente:

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

A continuación, cree una tabla de historial para la nueva tabla temporal mediante uno de los dos métodos siguientes:

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;

CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

La cláusula RESTRICT ON DROP no permitirá que la tabla de historial se borre al borrar la tabla temporal de período del sistema. De lo contrario, la tabla de historial se borra de forma implícita al borrar la tabla temporal asociada. Puede crear una tabla de historial sin RESTRICT ON DROP. Una tabla de historial no se puede borrar explícitamente.

No debe utilizar la cláusula GENERATED ALWAYS al crear una tabla de historial. La clave primaria de la tabla temporal de período de sistema tampoco se aplica aquí, ya que puede haber muchas actualizaciones para una fila concreta en la tabla base, lo que dispara muchas inserciones en la tabla de historial para el mismo juego de claves primarias. Aparte de estos, la estructura de una tabla de historial debe ser exactamente la misma que la tabla temporal de período del sistema asociada. La tabla de historial debe tener el mismo número y orden de columnas que la tabla temporal de período del sistema. Las columnas de la tabla de historial no se pueden agregar, borrar ni cambiar explícitamente. Debe asociar una tabla temporal de período de sistema a su tabla de historial con la siguiente sentencia:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Las columnas GENERATED ALWAYS de la tabla son las que siempre rellena el gestor de base de datos para que no tenga ningún control sobre estas columnas. El gestor de base de datos rellena estas columnas en función de la hora del sistema.

Las columnas SYSTEM_PERIOD y transaction id agregadas adicionales tendrán valores por defecto para las filas ya existentes, como se muestra a continuación:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

La tabla de historial asociada se rellena con las imágenes anteriores una vez que empiece a actualizar la tabla temporal.

Ejemplo 2 Conversión de una tabla existente en una tabla temporal de período de aplicación

Puede convertir la tabla existente de ejemplo en una tabla temporal de período de aplicación agregando columnas de tiempo y un período BUSINESS_TIME como en lo siguiente:

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Al agregar columnas de tiempo, debe asegurarse de que al introducir valores de tiempo de validez de negocio de las columnas de tiempo existentes, la columna bus_start siempre tiene un valor menor que bus_end porque estas columnas especifican la validez de negocio de las filas.

La nueva tabla temporal de período de aplicación tendrá un aspecto similar a:

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002

Ejemplo 3 Conversión de una tabla existente en una tabla bitemporal

Puede convertir la tabla existente de ejemplo en tabla bitemporal agregando columnas de tiempo SYSTEM_PERIOD junto con el período SYSTEM_TIME y BUSINESS_TIME como en lo siguiente:

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Al agregar las columnas de tiempo, debe asegurarse de que al introducir los valores de tiempo de validez de negocio de las columnas de tiempo ya existentes, la columna bus_start siempre tiene un valor menor que bus_end porque estas columnas especifican la validez de negocio de las filas.

A continuación, cree una tabla de historial para la nueva tabla temporal mediante uno de los dos métodos siguientes:

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

La cláusula RESTRICT ON DROP no permitirá que la tabla de historial se borre al borrar la tabla temporal de período del sistema. De lo contrario, la tabla de historial se borra de forma implícita al borrar la tabla temporal asociada. Puede crear una tabla de historial sin RESTRICT ON DROP. Una tabla de historial no se puede borrar explícitamente.

No debe utilizar la cláusula GENERATED ALWAYS al crear una tabla de historial. La clave primaria de la tabla temporal de período de sistema tampoco se aplica aquí, ya que puede haber muchas actualizaciones para una fila concreta en la tabla base, lo que dispara muchas inserciones en la tabla de historial para el mismo juego de claves primarias. Además, la estructura de una tabla de historial debe ser exactamente la misma que la tabla temporal de período del sistema asociada. La tabla de historial debe tener el mismo número y orden de columnas que la tabla temporal de período del sistema. Las columnas de la tabla de historial no se pueden agregar, borrar ni cambiar explícitamente. Debe asociar una tabla temporal de período de sistema a su tabla de historial con la siguiente sentencia:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Las columnas SYSTEM_PERIOD y transaction id agregadas adicionales tendrán valores por defecto para las filas ya existentes, como se muestra a continuación:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

La tabla de historial asociada se rellena con las imágenes anteriores una vez que comience a actualizar la tabla temporal.

Las columnas de tiempo, ID de transacción y período SYSTEM_TIME adicionales tendrán valores por defecto para las filas ya existentes, como se muestra a continuación:

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

La tabla de historial se rellena con las imágenes anteriores una vez que el usuario comienza a actualizar la tabla temporal.

Ejemplo 4 Replicación en un entorno heterogéneo.

En una configuración heterogénea en la que no tiene tablas temporales en el lado de aplicación, solo puede replicar las tablas de período del sistema y bitemporal, aunque no las tablas de historial asociadas. Al realizar la replicación en esta situación, debe encargarse del valor de las columnas de ID de transacción y SYSTEM_PERIOD. Estas columnas tendrán algunos valores que puede que la base de datos destino no soporte. En primer lugar, debe utilizar las funciones de conversión de mapas para convertir estos valores en el formato que soporta la base de datos de destino y, a continuación, asignar las columnas según corresponda.

Por ejemplo, MySQL tiene un rango DATETIME de 1000-01-01 00:00:00.000000 a 9999-12-31 23:59:59.999999. No puede replicar un valor de registro de hora de 0001-01-01-00.00.00.000000000000 en MySQL. Para replicar estos valores, debe convertir este valor en el valor MySQL DATETIME 1000-01-01 00:00:00.000000 y, a continuación, asignar las columnas. Si tiene la siguiente fila en la tabla de períodos del sistema policy_info:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Para replicar la fila en MySQL, debe utilizar la función colmap():

map *source_schema*.policy_info, target *target_schema*.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

Replicación con Tablas Temporales

Puede elegir uno de los siguientes métodos para replicar un período del sistema o una tabla temporal bitemporal de la siguiente manera:

Sólo puede replicar una tabla temporal en otra tabla temporal; este es el comportamiento por defecto. Oracle GoldenGate no replicará las columnas de ID de transacción y período SYSTEM_TIME porque estas se generan automáticamente en el lado de aplicación. El gestor de base de datos rellena las columnas de la tabla temporal de destino mediante la hora del reloj del sistema y con los valores por defecto. Puede conservar los valores originales de estas columnas y, a continuación, utilizar cualquiera de las siguientes opciones:
- Agregue columnas de registro de hora adicionales en la tabla temporal de destino y asigne las columnas según corresponda. Las columnas adicionales se agregan automáticamente a la tabla de historial asociada.
- Utilice una tabla no temporal en el lado de aplicación y asigne las columnas correctamente. En este caso, no podrá mantener la tabla de historial.
- En una configuración heterogénea en la que el origen es Db2 LUW y el destino es una base de datos diferente, puede ignorar las columnas generadas automáticamente o utilizar una función de conversión de columna adecuada para convertir el valor de las columnas en el formato que soporta la base de datos de destino y asignarlas a las columnas de destino según corresponda.
O bien
Puede replicar una tabla temporal, con la tabla de historial asociada, en una tabla temporal y una tabla de historial, respectivamente. A continuación, debe especificar el parámetro de replicación, DBOPTIONS SUPPRESSTEMPORALUPDATES. Debe especificar tanto la tabla temporal como la tabla de historial que se va a capturar en el archivo de parámetros de Extract. Oracle GoldenGate replica el valor de columnas de identificador de transacciones y período SYSTEM_TIME. Debe asegurarse de que la instancia de base de datos tiene el permiso de ejecución para ejecutar el procedimiento almacenado en el lado de aplicación.

Oracle GoldenGate no puede detectar ni resolver conflictos al utilizar la replicación por defecto como período SYSTEM_TIME y las columnas transactionstart id permanecen generadas automáticamente. Estas columnas no se pueden especificar en las cláusulas set y where. Si utiliza el parámetro SUPPRESSTEMPORALUPDATES, Oracle GoldenGate soporta CDR.