Inicio > Tech - Data Management > Exprimiendo a GoldenGate: SPECIALRUN y REMOTETASK

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)

Extract File

Así sería el fichero de configuración de un extract (srs.prm) en origen que generaría un fichero en el host remoto para su posterior aplicación.

SETENV (ORACLE_HOME = “/opt/ogg/product/11.1.0”)

SETENV (NLS_LANG = “AMERICAN_AMERICA.WE8ISO8859P15”)

SOURCEISTABLE

USERID ggowner@SOURCE_DB, PASSWORD ******** AES128, ENCRYPTKEY claveAES

RMTHOST 192.168.100.111, MGRPORT 8809

RMTFILE ./dirdat/REINSTANCIAR.DAT, PURGE

TABLE GGTEST.T_*;

TABLEEXCLUDE GGTEST.T_TRANSACCIONES;

TABLEEXCLUDE GGTEST.T_TRANSACCIONES_HIST;

En él, tras las variables de entorno, SOURCEISTABLE, indicará al extract que en lugar de explotar los archivados, extraiga los datos de las tablas (es decir, su estado actual, con todos los registros, no sólo los nuevos o actualizados). Tras los datos de conexión y el host remoto, indicaremos que se deben extraer TODAS (*) las tablas del esquema, exceptuando (tantas como haya en el esquema) las tablas de transacciones, con gran volumen de datos, y que sincronizamos de manera específica por otra vía.

En la instancia GG destino configuraremos un replicat (srt.prm) de la siguiente manera.

SETENV (ORACLE_HOME=”/u01/app/orapre/product/11.2.0.4/dbhome_1″)

SETENV (ORACLE_SID=TARGET_DB)

SETENV (NLS_LANG=”AMERICAN_AMERICA.WE8ISO8859P15″)

SPECIALRUN

END RUNTIME

USERID ggowner, PASSWORD ******** AES128, ENCRYPTKEY claveAES SYSDBA

ASSUMETARGETDEFS

EXTFILE ./dirdat/REINSTANCIAR.DAT

–EXTFILE ./dirdat/MAESTROS.DAT — ¿Hemos generado varios ficheros?

MAP GGTEST.*, TARGET GGTEST.*;

Tras las variables de entorno que configuran la conexión, indicaremos que se trata de un proceso SPECIALRUN, que no utiliza checkpoints. END RUNTIME por su parte, indica que debe finalizar una vez procesados los datos en el fichero apuntado en EXTFILE (o ficheros, si en origen hemos generado varios, para que los procese todos). En el mapeo, indicaremos * (todas las tablas que lleguen).

Bien, el comentario sobre  SPECIALRUN  y END RUNTIME ha sido muy resumido, pero depende del uso que planteemos, habrá que reflexionar bien sobre las implicaciones que pueden tener sobre el comportamiento del replicat en combinación con la configuración del extract (no se diera el caso que terminara el replicat y luego el extract enviara más datos a posteriori).

Una vez configurados extract y replicat, sólo falta ejecutarlos.

En origen:

./extract paramfile dirprm/sr.prm reportfile dirrpt/srs.rpt

El proceso de extract puede tardar unos minutos (podemos lanzar el proceso en background e ir monitorizando en el fichero de log dirrpt/srs.rpt su avance). Cuando el extract finalice, no habremos replicado las tablas todavía en destino; pero tendremos en el host remoto un fichero de trail con todas las tablas tal y como están en origen.

En el host remoto, lanzaremos el replicat de la siguiente manera (si hemos partido la generación en varios ficheros, podremos empezar a procesar la carga en destino antes, al completarse el primer fichero de trail).

./replicat paramfile dirprm/srr.prm reportfile dirrpt/srt.rpt

Espero que sea útil, en mi caso tardé más o menos lo mismo en deshabilitar la IR, truncar las tablas y volver a habilitarla que en replicar las tablas maestras.

No olvidéis borrar el fichero en destino (./dirdat/REINSTANCIAR.DAT) al acabar ya que el manager no se ocupará de él.

Direct load

La segunda opción es una copia de datos directa, tabla (en BD origen) a tabla (en BD remota), sin generar ficheros de trail intermedios. Para ello, pero, será necesario registrar procesos de extract y replicat en los manager tanto en la instancia GG origen como en destino.

El fichero de parámetros del extract (srrt.prm) sería por ejemplo:

SETENV (ORACLE_HOME = “/opt/ogg/product/11.1.0”)

SETENV (NLS_LANG = “AMERICAN_AMERICA.WE8ISO8859P15”)

EXTRACT srrt

USERID ggowner@SOURCE_DB, PASSWORD ******** AES128, ENCRYPTKEY claveAES

RMTHOST 192.168.100.111, MGRPORT 8809

RMTTASK REPLICAT, GROUP initrep

TABLE GG_TEST.*;

Del que cabe comentar que deberemos dar nombre al proceso extract (srrt), y que con RMTTASK indicaremos que el replicat en destino se levantará automáticamente cuando el extract empiece a enviarle datos, por lo que NO DEBE SER LEVANTADO en el manager de la instancia remota. Una vez procesados los datos, el proceso replicat remoto finalizará, liberando recursos.

A continuación, el fichero de parámetros del replicat (initrep.prm), donde el único detalle a destacar es que el nombre del replicat debe coincidir con el indicado por el parámetro GROUP del extract.

REPLICAT initrep

SETENV (ORACLE_HOME=”/u01/app/orapre/product/11.2.0.3/dbhome_1″)

SETENV (ORACLE_SID=SIFDWHT1)

SETENV (NLS_LANG=”AMERICAN_AMERICA.WE8ISO8859P15″)

USERID ggowner, PASSWORD ******** AES128, ENCRYPTKEY claveAES SYSDBA

ASSUMETARGETDEFS

MAP GG_TEST.*, TARGET GG_TEST.*;

Este tipo de ejecución, requiere que las tablas destino estén vacías o acabará con un abend del replicat.

Conclusiones

Como conclusión, creo que podemos afirmar que GoldenGate no es únicamente una herramienta de replicación de datos, sinó más bien una herramienta para compartir datos. Las opciones que hemos visto en este post abren la puerta a otros posibles usos y demuestran que es una herramienta ágil y potente.

Comparando los dos métodos demostrados, podríamos decir que Direct Load, es una opción más “limpia” porqué no utiliza ficheros de trail intermedios, aunque como contrapartida, requiere registrar los extract y replicat en los manager respectivo. Mientras que el método de Extract File no requiere modificaciones en los manager, y sería especialmente útil para una sincronización en diferido, varias veces, o en varias instancias, ya que el replicat lo iniciaremos en el momento que decidamos, tantas veces como haga falta, y no necesariamente de manera inmediata.

  1. Aún no hay comentarios.
  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 )

Google+ photo

Estás comentando usando tu cuenta de Google+. 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 )

w

Conectando a %s

A %d blogueros les gusta esto: