Inicio > GoldenGate > Traspaso inicial de datos con Oracle GoldenGate

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”.

  1. Ramón ROBLES
    octubre 20, 2014 en 13:02

    Hola Rafael,

    En el hipotético caso de que se necesite parar GOLDEN GATE, cuando se vuelva a reiniciar … que es lo que hace realmente? Vuelve a validar toda la estructura de una Instancia replicada o tiene algún mecanismo de ejecución INCREMEMNTAL?

    Y, si por desgracia, la base de datos destino queda parada. Que hace Goldem Gate? Genera ficheros que luego son los que sólo trata para realizar la sincronización?

    Gracias de antemano.

    Un Saludo

    • Rafael Planella
      octubre 20, 2014 en 21:24

      Hola Ramon,

      GoldenGate mantiene registro del ultimo cambio capturado o aplicado, en caso de ser un proceso de captura al iniciarse de nuevo continuará capturando cambios justo donde lo dejo al pararse en caso de ser un proceso de replica lo mismo, continua donde lo dejo, ni se pierden ni se dejan por el camino transacciones.

      El proceso de “extracción” de GoldenGate captura las transacciones confirmadas y las almacena en unos ficheros llamados ficheros de trail. Estos mismos ficheros pueden ser enviados total o parcialmente (dependiendo de si nos interesa replicar todas o una parte de las transacciones) a los sistemas destino y finalmente en estos sistemas destino otros procesos GoldenGate los aplican a las BBDD destino. En caso de parada en la BBDD destino estos cambios se acumulan en estos ficheros a la espera que la BBDD vuelva a estar disponible.

      Un saludo

      Rafael

  2. Idrix Villarreal Marin
    julio 12, 2016 en 15:21

    hola, si se presenta un fallo en la copia de datos? es decir se identifica tiempo después que algunos datos no pasaron y son faltantes en la replica, al igual hay tablas con diferencias significativas en cantidad de registros, en ese caso porque puede suceder? cual es la alternativa de solución
    gracias por tu comentario

    • Rafael Planella
      julio 13, 2016 en 08:57

      Hola Idrix,

      En primer lugar si tenemos claras las tablas afectadas las excluiría de la replica (con el parámetro TABLEEXCLUDE ), esto permitirá que el resto de tablas sigan replicando y nos evitará que toda la replica quede fuera de sincronización.

      Las tablas afectadas se tendrán que cargar de nuevo desde origen y reanudar posteriormente la replica para ellas. En la siguiente entrada del blog tienes el detalle de un posible procedimiento para esta tarea:

      https://blog.avanttic.com/2012/10/02/volver-a-sincronizar-esquemas-o-tablas-en-oracle-goldengate/

      Finalmente te recomendaría probar el procedimiento de sincronización parcial en algún entorno de pruebas o laboratorio antes de hacerlo en producción. Los parámetros usados para esta tarea (tokens, CSN) varían en función de la versión de Goldengate y de esta manera podrás verificar los parámetros/configuración exacta es necesaria en la versión de que dispongáis.

      Saludos,

      Rafael

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: