Traspaso inicial de datos con Oracle GoldenGate

Oracle GoldenGate es una herramienta de replicación de datos entre entornos heterogéneos. Permite configurar soluciones de alta disponibilidad, de integración de datos o de réplica en tiempo real.

Para los que desconozcáis este producto, os recomiendo visitar esta entrada del blog y, en especial, ver la presentación que lo acompaña.

En la entrada de hoy comentaré una parte de la configuración de GoldenGate que no aparece en la mayoría de ejemplos existentes en la Web: el traspaso inicial de datos.

Al configurar una réplica con GoldenGate lo más común es que en el entorno de destino no dispongamos de datos, por lo que como paso previo a la réplica deberemos traspasar los datos para posteriormente poder empezar a traspasar únicamente los cambios. A este proceso lo llamamos la “carga inicial”.

Las cargas iniciales normalmente tienen como hándicap que el origen de datos se mantiene activo, esto es, se siguen generando cambios durante el proceso de carga inicial de datos.

Tenemos varias opciones para realizar esta tarea:

  • Carga de datos en formato nativos con utilidades de la BBDD

En este caso replicaríamos la BBDD mediante las herramientas nativas de las que se disponga. En caso de Oracle podría ser desde una recuperación mediante RMAN (completa o Tablespace Point In Time Recovery) o mediante expdp/impdp.

Deberemos tener arrancado un proceso de EXTRACT/REPLICAT que controlará los cambios realizados durante el tiempo que dure la carga inicial y que posteriormente los aplicará en destino.

  • Carga de datos desde fichero con EXTRACT y REPLICAT

En este caso el proceso GoldenGate EXTRACT extrae los datos y los almacena en ficheros, que posteriormente serán leídos por el proceso REPLICAT y aplicados en destino. Este método es muy similar al usado durante la sincronización normal (el traspaso de cambios). Al igual que en el caso anterior tendremos el proceso de replica normal arrancado durante la carga inicial para capturar los cambios realizados durante el tiempo que dure esta. El proceso EXTRACT de carga inicial lee los datos directamente de las tablas de la BBDD origen y no de los ficheros de log.

  • Carga de datos desde un fichero a utilidades de BBDD

En este caso el proceso de EXTRACT dejará los datos en un formato “entendible” por parte de las herramientas de carga de la BBDD (dependiendo de que BBDD serán unas o otras) y también generará los ficheros de control y ejecución necesarios para esas herramientas. Al igual que en el ejemplo anterior, al ser una carga inicial se leen los datos de las tablas y no de los ficheros de log.

Los cambios realizados durante toda la duración de este proceso  se capturarán, al igual que en el resto de puntos, y se aplicarán posteriormente mediante la tarea EXTRACT/REPLICAT genérica que habremos arrancado previamente.

  • Carga de datos con “direct load” de GoldenGate

Este sistema es muy similar a la carga de datos con EXTRACT/REPLICAT, con la diferencia que no se almacenan los cambios en un TRAIL de disco. En este caso los cambios se envían directamente de la zona de memoria en que los almacena el EXTRACT a la zona de memoria usada por el REPLICAT en destino.

A grandes trazos consiste en crear un proceso EXTRACT de ejecución puntual que enviará los cambios directamente a un REPLICAT de ejecución puntual en destino. Al arrancar la tarea de EXTRACT automáticamente se conectará a destino y dará orden de arranque al REPLICAT, parando ambos una vez se finalice la carga. Como en el resto de casos EXTRACT leerá los datos directamente de las tablas y no de los logs .

Los cambios realizados durante toda la duración de este proceso se capturarán, al igual que en el resto de puntos, mediante una segunda tarea EXTRACT/REPLICAT, esta vez genérica que habremos arrancado previamente.

  • Carga directa contra SQL*Loader

Este sistema es parecido al anterior, pero con la salvedad de que el EXTRACT se comunica en el site remoto con un REPLICAT arrancado automáticamente que envía los datos a la API del SQL*Loader, siendo este quien cargue los datos en el gestor.

Es una opción específica para destinos de tipo Oracle y no soporta los tipos de datos LOB o LONG. Cabe notar que es el sistema más rápido para cargar datos en gestores Oracle.

Los cambios realizados durante toda la duración de este proceso se capturarán, al igual que en el resto de puntos, mediante la tarea EXTRACT/REPLICAT genérica que habremos arrancado previamente.

  • Carga mediante utilidades de Teradata

Este caso es similar al de Carga de datos desde un fichero a utilidades de BBDD, siendo estas utilidades las especificas de Teradata.

En resumen:

En todos los casos explicados, básicamente traspasamos los contenidos de la base de datos o de parte de ella mientras otros procesos de tipo EXTRAC/REPLICAT se encarga de registrar los cambios sucedidos durante el tiempo que dura el traspaso.

Es importante saber que el proceso de REPLICAT del conjunto EXTRACT/REPLICAT se deberá poner en marcha en todos los casos una vez finalizada la carga de datos y con el parámetro “HANDLECOLLISIONS”, de manera que en caso que intente volver a aplicar cambios ya aplicados en destino no se produzcan errores. Una vez empecemos a traspasar cambios realizados con posterioridad a la tarea de carga inicial deberemos eliminar este parámetro de la configuración.

En próximos posts realizaremos un ejemplo de carga inicial. Este proceso lo realizaremos controlando el SCN en que se capturan los datos en origen, de manera que podamos iniciar el traspaso sin la necesidad del parámetro “HANDLECOLLISIONS”.

Evolución, innovación y transformación
37 especializaciones avaladas por Oracle
Oportunidades ilimitadas
El equipo marca la diferencia
Posts 100% Oracle
Sigue nuestro día a día