Oracle GoldenGate 12c - DB2 i 7.1 & Oracle Database 12c

Por Francisco Riccio Oracle ACE
Publicado en Enero 2017

Introducción

El siguiente documento detalla el procedimiento que puede optarse al querer migrar una base de datos DB2 en plataforma IBM i 7.1 a Oracle DB 12c sobre plataforma AIX 7.1 sin generar un corte de servicio utilizando la herramienta Oracle GoldenGate 12c.

La estrategia consiste en ir replicando los datos de la base de datos origen al destino hasta que ambos repositorios cuenten con los mismos datos, una vez llegado ese momento, se procede a modificar la cadena de conexión de las aplicaciones para que puedan conectarse a la base de datos destino como se detalla en el siguiente diagrama:

Diseño de Estrategia de Migración

Este documento también será útil para quienes requieran únicamente replicar datos de una base de datos a otra y no necesariamente tengan un proyecto de migración.

Es importante aclarar que este documento no está enfocado a explicar los conceptos básicos de Oracle GoldenGate.

Implementación

I. Instalación

Primero se procederá a instalar Oracle GoldenGate 12c tanto en el servidor IBM i 7.1 como en el servidor AIX 7.1.

Los instaladores para ambas plataformas se encuentran en el siguiente url:
http://www.oracle.com/technetwork/middleware/goldengate/downloads/index.html

Es recomendable instalar el último parche disponible de Oracle GoldenGate 12c antes de iniciar el despliegue de la configuración.
Para esta implementación se ha tenido en cuenta el siguiente parche, el cual es el más reciente al momento de ser escrito este documento.

Patch 24764985: ORACLE GOLDENGATE V12.2.0.1.161018 FOR DB2 (IBM I)

Otro punto importante a tener en cuenta, es la revisión de los requisitos que debe cumplir el Sistema Operativo de IBM i junto con las restricciones que tiene el producto para la base de DB2 ejecutándose en dicha plataforma.
Estas consideraciones se encuentran en el siguiente documento:
https://docs.oracle.com/goldengate/1212/gg-winux/GIDBI/system_requirements.htm#GIDBI128

Nota: Una de las principales restricciones que tiene el producto, sobre la base de datos DB2, es no poder replicar operaciones DDL o DCL únicamente DML.

Oracle ofrece una matriz de compatibilidad que nos ayudará a validar nuestra arquitectura antes de iniciar las implementaciones de Oracle GoldenGate.
Esta matriz se encuentra en el siguiente url:
http://www.oracle.com/technetwork/middleware/fusion-middleware/documentation/fmw-1212certmatrix-1970069.xls

Servidor DB2 i 7.1

Pasos para realizar la instalación del Producto:

  • Se debe crear un usuario de Sistema Operativo. En este caso, se creará el usuario GG para realizar la instalación. Se recomienda asignarle el perfil *SECOFR para evitar problemas de acceso a las futuras librerías que luego se crearán en el Sistema Operativo y que dicho usuario deberá tener acceso.

A continuación se detalla las propiedades que el usuario GG tiene para la implementación que se detallará más adelante.

  • Conectado con el usuario nuevo, se deberá crear un directorio para posteriormente descomprimir el instalador de Oracle GoldenGate para DB2 i en dicha carpeta.
MKDIR DIR('/GoldenGate')


  • Se procede a crear una Librería de IBM i para almacenar la instalación de Oracle GoldenGate 12c.
CRTLIB LIB(goldengate) TEXT('Oracle GoldenGate Product Library') ASP(1)


  • Copiamos el instalador de Oracle GoldenGate a través de FTP a la carpeta /GoldenGate y cambiamos nuestra sesión a la actual librería.
CHGCURLIB goldengate


Nota: Se recomienda que el usuario tenga cargado automáticamente la librería por defecto al iniciar una nueva sesión.

  • Abrimos un terminal QP2TERM.
CALL QP2TERM


  • Descomprimimos el instalador de Oracle GoldenGate 12c con el comando: tar –xf.
  • Ejecutamos la instalación con el comando: ggos400install

Posteriormente deberíamos obtener el mensaje: Installation complete como se presenta a continuación:

Nota: Se recomienda configurar la sesión del usuario en idioma Inglés para evitar algún error. Con el idioma Español la instalación falla con el siguiente mensaje:

Servidor Oracle Database 12c en AIX 7.1

Para instalar Oracle GoldenGate 12c para Oracle Database sobre la plataforma AIX 7.1, se debe descargar y descomprimir el instalador en una carpeta, posteriormente se debe ejecutar el comando runInstaller y seguir los pasos de la instalación, como se presenta a continuación:

Posterior a la instalación debemos configurar el parámetro ENABLE_GOLDENGATE_REPLICATION de la base de datos destino con el valor a TRUE.

II. Configuración

Ambas instancias de Oracle GoldenGate (IBM i & AIX) requieren tener un proceso llamado Manager el cual será el responsable de la gestión de los procesos: extractores y replicadores que más adelante se configurará.

Paso 1.- Configuración del Manager en ambas Instancias

Debe crearse un archivo llamado MGR.PRM dentro del directorio DIRPRM que se encuentra en la carpeta de instalación de Oracle GoldenGate 12c.

Archivo de Configuración:

PORT #PUERTO

Ejemplo:

PORT 7910


Luego se procede a iniciar el servicio a través del comando start mgr.
Se muestra su ejecución.

El inicio del proceso Manager debe ser realizado en ambos servidores.

A continuación se presenta la siguiente escala de tiempo que servirá para entender el esquema de migración que se realizará a continuación

 

TIEMPO

ACTIVIDADES

 

T1

Inicia un extractor que se encargue de ir almacenando la información de las nuevas transacciones.
En nuestro ejemplo se llamará EXT2.

 

T2

Deberá iniciar la etapa de Initial Load, cuyo objetivo es copiar los datos actuales hacia las tablas destino, para ello se deberá iniciar un nuevo extractor.
En nuestro ejemplo se llamará EXT1.

 

T2’

Debemos iniciar un replicador que se encargará de copiar los datos enviados por el extractor asignado al Initial Load.
En nuestro ejemplo se llamará REP1.

 

T1’

Terminado el tiempo T2’, iniciamos un replicador que se encargará de copiar los datos enviados por el extractor inicial.
Es importante que este replicador esté configurado con la opción HANDLECOLLISIONS para que pueda gestionar los datos duplicados que existirán entre el tiempo T1 y T2.
En nuestro ejemplo se llamará REP2.

 

T1’’

Una vez que se encuentre replicada ambas base de datos, debemos detener el segundo replicador y le retiramos la opción HANDLECOLLISIONS. Luego procedemos a iniciarlo para que continúe la réplica.

A continuación se presenta la configuración de cada uno de los componentes previamente explicados.

Paso 2.- Creamos el Archivo de Definiciones

Creamos el archivo de definición donde estará definida la metadata de las tablas a replicar. Este paso se realiza cuando el origen y el destino tienen diferente estructura o son de distintas tecnologías.

Archivo de Configuración:

defsfile dirdef/<Archivo_Definición>
sourcedb <NombreBD> userid <Usuario_SO_BD>, password <Password>
table <ESQUEMA.TABLA1>;
table <ESQUEMA.TABLA2>;
table <ESQUEMA.TABLA3>;

Ejemplo:

defsfile dirdef/db2.def
sourcedb IASP userid GG, password gg
table EMP.ENTIDADPRB;


Ejecutamos el programa DEFGEN para crear el archivo de definiciones.

defgen paramfile dirprm/<Archivo_Definición>

Ejemplo:

El archivo generado procedemos a copiarlo en el servidor destino en la carpeta DEFGEN.
La carpeta DEFGEN es una sub-carpeta donde se encuentra instalado Oracle GoldenGate 12c.

Paso 3.- Creamos el Extractor EXT2

Antes de configurar algún extractor en el ambiente de IBM i, debemos realizar algunas configuraciones previas en los Journals.

Todos los Journals asociados a las tablas que se esperan replicar deberán contar con las siguientes características:

  • Manage Receivers (MNGRCV): *SYSTEM
  • Delete Receivers (DLTRCV): *NO
  • Receiver Size Option (RCVSIZOPT): *MAXOPT2 (recomendado: *MAXOPT3)
  • Journal State (JRNSTATE): *ACTIVE
  • Minimize Entry Specific Data (MINENTDTA): *NONE
  • Fixed Length Data (FIXLENDTA): *USR *SYSSEQ

 

Los cambios se pueden realizar ejecutando el siguiente comando:
CHGJRN JRN(<Nombre_Libreria>/<Nombre_Journal>) MNGRCV(*SYSTEM) DLTRCV(*NO) RCVSIZOPT(*MAXOPT2) JRNSTATE(*ACTIVE) MINENTDTA(*NONE) FIXLENDTA(*USR *SYSSEQ)

Se muestra la configuración del JOURNAL que tiene asociado las tablas que posteriormente se replicarán.

Se recomienda una rotación de secuencia del journal después de realizar la configuración.

Finalmente, por cada tabla que deseemos replicar, debemos ejecutar el siguiente comando:

GGSCI> add trandata <nombre_esquema>.<nombre_tabla> 

Archivo de Configuración:

extract <Extractor>
sourcedb <NombreBD> userid <Usuario_SO_BD>, password <Password>
exttrail dirdat/<trail_file>
table <ESQUEMA.TABLA1>;
table <ESQUEMA.TABLA2>;
table <ESQUEMA.TABLA3>;

Ejemplo:

extract EXT2
sourcedb IASP userid GG, password gg
exttrail dirdat/eb
rmtfile ./dirdat/ea
table EMP.ENTIDADPRB;

Procedemos a registrarlo:

alter extract <Extractor> JOURNAL <Librería>/<ContenedorJournal> begin now
add exttrail dirdat/eb, extract <Extractor>,megabytes <Tamaño>
start extract <Extractor>

Ejemplo:

alter extract EXT2 journal LIBEDI/JRN begin now
add exttrail dirdat/eb, extract EXT2
start extract EXT2

Una vez iniciando el extractor EXT2, debemos asegurarnos que posteriormente se encuentra en estado RUNNING.

Paso 4.- Creamos el Datapump DP1

Procedemos a crear el proceso DATAPUMP que se encargará de copiar los archivos TRAIL FILES generados por el extractor EXT2 hacia el servidor destino.

extract <Datapump>
rmthost <SERV_DESTINO>, mgrport <PUERTO_MANAGER_SERV_DESTINO>
rmttrail ./dirdat/<trail_file>
table <ESQUEMA.TABLA1>;
table <ESQUEMA.TABLA2>;
table <ESQUEMA.TABLA3>;

Ejemplo:

extract DP2
rmthost 10.2.1.50, mgrport 7809
rmttrail dirdat/eb
table EMP.ENTIDADPRB;

Procedemos a registrarlo:

add extract <Datapump>, exttrailsource dirdat/eb
add rmttrail dirdat/eb, extract <Datapump>

Ejemplo:

add extract DP2, exttrailsource dirdat/eb
add rmttrail dirdat/eb, extract DP2

Posterior a estos pasos, debemos revisar si el servidor destino se encuentran los archivos trail files con la secuencia eb00000*. Estos archivos deben encontrarse en la carpeta dirdat ubicada como un sub-directorio de la instalación de Oracle GoldenGate 12c.

Se debería contar con un escenario similar como a continuación se presenta:

Tanto los procesos EXT2 y DP2 deberían encontrarse ejecutándose como a continuación se presenta:


Paso 5.- Creamos el Extractor EXT1 (Initial Load)

Archivo de Configuración:

extract <Extractor>
sourcedb <NombreBD> userid <Usuario_SO_BD>, password <Password>
rmthost <SERV_DESTINO>, mgrport <PUERTO_MANAGER_SERV_DESTINO>
rmtfile ./dirdat/<trail_file>
table <ESQUEMA.TABLA1>;
table <ESQUEMA.TABLA2>;
table <ESQUEMA.TABLA3>;

Ejemplo:

extract EXT1
sourcedb IASP userid GG, password gg
rmthost 10.2.1.50, mgrport 7809
rmtfile ./dirdat/ea
table EMP.ENTIDADPRB;

Procedemos a registrarlo:

add extract <Extractor>, sourceistable
start extract <Extractor>

Ejemplo:

Posterior debemos revisar si en el servidor destino se encuentran los archivos trail files con la secuencia ea00000*. Estos archivos deben encontrarse en la carpeta dirdat ubicada como un sub-directorio de la instalación de Oracle GoldenGate 12c.

Se debería contar con un escenario similar como a continuación se presenta:

Nota: El extractor EXT1 se detendrá automáticamente cuando termine de copiar todos los datos actuales en los trail files.

Paso 6.- Creamos el Replicador REP1 (Initial Load)

Nota: Antes de iniciar la replicación del Initial Load, los Constraints de tipo: Check, Foreign, Unique y NOT NULL deben ser desactivados en las tablas destino.

Archivo de Configuración:

replicat <Replicador>
PRESERVETARGETTIMEZONE
userid <Usuario_SO_BD>, password <Password>
sourcedefs dirdef/<Archivo_Definiciones>.def
discardfile dirrpt/<Archivo_Discard>.dsc, purge
end runtime
map <ESQUEMA_ORIGEN.TABLA1>, target <ESQUEMA_DESTINO.TABLA1>;
map <ESQUEMA_ORIGEN.TABLA2>, target <ESQUEMA_DESTINO.TABLA2>;
map <ESQUEMA_ORIGEN.TABLA3>, target <ESQUEMA_DESTINO.TABLA3>;

Ejemplo:

replicat rep2
PRESERVETARGETTIMEZONE
userid gg, password gg
sourcedefs dirdef/db2.def
discardfile dirrpt/rep2.dsc, purge
end runtime
map EDI.ENTIDADPRB, target EDI.ENTIDADPRB;

Procedemos a registrarlo:

add replicat <Replicador>, exttrail dirdat/<trail_file>, nodbcheckpoint
start replicat <Replicador>,

Ejemplo:

add replicat rep1, exttrail dirdat/ea, nodbcheckpoint
start replicat rep1

Nota: El replicador REP1 se detendrá automáticamente cuando termine de poblar todos los datos que el extractor EXT1 ha copiado.

Paso 7.- Creamos el Replicador REP2

Archivo de Configuración:

replicat <Replicador>
PRESERVETARGETTIMEZONE
HANDLECOLLISIONS
userid <Usuario_SO_BD>, password <Password>
sourcedefs dirdef/<Archivo_Definiciones>.def
discardfile dirrpt/<Archivo_Discard>.dsc, purge
map <ESQUEMA_ORIGEN.TABLA1>, target <ESQUEMA_DESTINO.TABLA1>;
map <ESQUEMA_ORIGEN.TABLA2>, target <ESQUEMA_DESTINO.TABLA2>;
map <ESQUEMA_ORIGEN.TABLA3>, target <ESQUEMA_DESTINO.TABLA3>;

Ejemplo:

replicat rep2
PRESERVETARGETTIMEZONE
HANDLECOLLISIONS
userid gg, password gg
sourcedefs dirdef/db2.def
discardfile dirrpt/rep2.dsc, purge
map EDI.ENTIDADPRB, target EDI.ENTIDADPRB;

Nota: El parámetro PRESERVETARGETTIMEZONE permite configurar el TIME ZONE del replicador a la establecida en la base de datos destino.

Procedemos a registrarlo:

userid <Usuario_SO_BD>, password <Password>
add replicat <Replicador>, exttrail dirdat/<trail_file>
add checkpointtable <Esquema>.<Nombre_Tabla_CheckPoint>
start replicat <Replicador>,

Ejemplo:

userid gg, password gg
add replicat rep2, exttrail dirdat/eb
add checkpointtable GG.CKPT
start replicat rep2


Nota: La creación de la tabla CHECKPOINT tiene como finalidad registrar el último dato que fue replicado en las tablas destino por el replicador.

Si deseamos validar si el replicador aún tiene datos por procesar, podemos ejecutar el comando LAG, como a continuación se presenta:

En este caso (At EOF, no more records to process), indica que no tiene más registros que procesar actualmente.

Asimismo, podemos obtener estadísticas de las operaciones DML que el replicador ha procesado.

 

Conclusión

Oracle GoldenGate 12c es una herramienta que nos permite replicar y migrar datos entre base de datos y plataformas distintas de una manera robusta e integral.

Antes de realizar la migración, es importante que se tenga identificado todos los requisitos y restricciones del producto para asegurar el éxito del proyecto.


Publicado por Ing. Francisco Riccio. Es un Cloud Architect en IBM Perú e instructor de cursos oficiales de certificación Oracle. Está reconocido por Oracle como un Oracle ACE y certificado en productos de Oracle Application & Base de Datos.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.