Archivo

Posts Tagged ‘replicat’

Exprimiendo a GoldenGate: SPECIALRUN y REMOTETASK

La semana pasada tuve que afrontar finalmente la reinstanciación de una BD del entorno PREproductivo, replicada con GoldenGate, que llevaba meses con el replicat Abended… y por lo tanto, totalmente desincronizada. Me daba mucha pereza, así que dediqué un rato a buscar la manera de hacerlo lo más rápidamente posible y con el mínimo esfuerzo.

A grandes rasgos, se trata de un esquema con 6 o 7 grandes tablas con millones de registros, y una cincuentena de tablas “maestras” con, comparativamente, pocos registros. La situación invitaba a plantear dos estrategias diferentes: una “personalizada” para la carga de cada una de las tablas grandes y otra para que permitiera transferir el mayor número posible de tablas con el menor esfuerzo de preparación y configuración.

Con este segundo objetivo en mente, recordé -y revisé- las características de GG para las cargas de datos iniciales que, a pesar de no ser una novedad (Rafael Planella ya las describió hace tiempo) , creo que no son muy conocidas, por lo que veremos con más detalles un par de ellas en este post (bajo un título un poco más marketiniano que “cargas iniciales”).

El siguiente esquema ilustra las diferencias entre la ejecución online (sin pump, por simplicidad), en gris, y procesos de integración de datos utilizando special run, sourceistable y remotetask, en verde.

GG_SR_Schema_1v0

Se trata de procesos ad-hoc que disponen básicamente de la misma funcionalidad que los extract y replicat normales (online), pero que se pueden levantar, ejecutar su tarea, y terminar, desapareciendo sin prácticamente dejar rastro en la configuración global de la instancia de GG, y sin consumir recursos del sistema mientras no está en uso. Por eso lo he considerado una posibilidad interesante para su uso en otras tareas de integración de datos más allá de la cargas iniciales, y me ha parecido interesante compartirlo.

Veamos a continuación un ejemplo de los dos posibles métodos para sincronizar tablas directamente, con sólo los recursos propios de GoldenGate (sin utilidades adicionales):

  • Extract File (Extract-Collector-Replicat)
  • Direct Load (Extract-Replicat, sin ficheros)

Leer más…

Generar comandos SQL a partir de los ficheros de trail de Oracle GoldenGate

Como ya hemos comentado en otras entradasGoldenGate es una herramienta que “permite capturar, enrutar, transformar y enviar datos transaccionales entre entornos heterogéneos en tiempo real”. Los datos (las transacciones) una vez capturados se almacenan en unos ficheros con formato propietario (independientes de la plataforma) llamados ficheros de “trail”. Vamos a revertir este proceso y obtener, de estos ficheros de trail, las sentencias SQL equivalentes a las transacciones almacenadas en ellos.

En esta entrada considero que el lector ya tiene un mínimo conocimiento de Goldengate, por lo que en caso contrario os recomiendo que reviséis la presentación que acompaña al post indicado anteriormente (ya que os estáis perdiendo un producto muy muy interesante).

Los datos capturados por GoldenGate se pueden almacenar en forma de ficheros de trail en diferentes puntos (dependiendo de la arquitectura escogida) y estos ficheros tendrán mas o menos información dependiendo de si ésta ha estado filtrada en la ruta hasta ese fichero concreto.

oracle_config

Pueden existir casos en que sea interesante disponer de las sentencias “SQL” que equivalen a los datos almacenados en estos ficheros de trail, o lo que es lo mismo, obtener las sentencias que GoldenGate ejecutaría en la BBDD destino al aplicar en ella esos ficheros de trail.

Existe una herramienta propia de GoldenGate llamada logdump que nos permite abrir estos ficheros, movernos entre las diferentes transacciones y sentencias, filtrar, buscar transacciones determinadas e incluso modificar el contenido de los ficheros.

El “aspecto” que tienen las transacciones mostradas mediante logdump dista mucho de lo que podríamos esperar si estamos acostumbrados a trabajar con sentencias SQL en herramientas tipo SQL*Plus o SQL*Developer:

logdumprecord_wseqinfoNo obstante podemos pasar estas sentencias SQL a formato “texto”, lo que nos permitirá trabajar con ellas (modificarlas/auditarlas/contabilizarlas) mas fácilmente.

La manera de conseguir esto consiste en crear un proceso de replica replicat, que leerá de los ficheros de trail y escribirá en un fichero de texto las sentencias (en lugar de aplicarlas a una BBDD).

Leer más…