Comparto con ustedes un documento de ejemplo que hice para un cliente que explica como desarrollar una replicación de golden gate básica, pero que sirve para entender como funciona Golden Gate desde el punto de vista más fácil de digerir. Además en esta guia explico una situación que se puede producir frente a un problema de Abended en un Replicador/Extractor ante por ejemplo una pérdida de los trail dat.
Espero les sea útil :)
Configuración básica de GG y Prueba de falla
Para esta prueba se simulará un escenario similar al de la purga, dónde existen dos instancias de bases de datos sobre un mismo servidor. Una instancia será el origen de los datos y otra tendrá la funcionalidad de recibir los datos a través de la replicación de Golden Gate. Se creará una prueba de falla y su respectiva solución evitando hacer una carga inicial desde 0.
En este contexto cabe destacar que siempre que existan problemas de Golden Gate se debe escalar el problema vía el soporte del producto (SR). Para este caso se siguió como ejemplo la guía de Oracle support: Main Note - Oracle GoldenGate - Troubleshooting (Doc ID 1306476.1)
Dicha anterior nota menciona otras sub-documentos adicionales como por ejemplo:
Configuración de Golden Gate
Información básica de los ambientes utilizados en esta prueba
Para este caso tenemos dos instancias de base de datos: la instancia en versión 11g (origen o “source” como se llamará de aquí en adelante) y la instancia en 12c ( destino o “target” como será referida posteriormente). Ambas instancias con sus respectivos archivos de base de datos sobre ASM. El sistema operativo es un Oracle Linux 6.9.
En la imagen anterior se puede apreciar la Instancia ora11g y ora12c (cada una respectivamente en versión 11g y 12c valga la redundancia)
La instalación de Golden gate la tenemos bajo el path siguiente:
[oracle@oraclelab 12.2.0.1]$ pwd
/gg/12.2.0.1
Configuración Inicial de las bases de datos para Golden gate
Los siguientes pasos los llevaremos a cabo usando la herramienta sqlplus “/as sysdba”
Sobre el motor de base de datos de origen (ora11g) ejecutaremos los siguientes comandos:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE FORCE LOGGING;
ALTER SYSTEM SWITCH all LOGFILE;
Posteriormente ejecutaremos el siguiente comando que nos debe devolver como resultado: YES
SELECT supplemental_log_data_min, force_logging FROM v$database;
Ejecución de los siguientes comandos a través de sqlplus “/as sysdba” (se debe ejecutar lo siguiente tanto para la base de datos de origen como la de destino):
CREATE TABLESPACE ogg_data LOGGING
DATAFILE
SIZE 1024M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED;
--Creacion del usuario de Golden gate
CREATE USER ogg_user IDENTIFIED BY oracle
DEFAULT TABLESPACE ogg_data
TEMPORARY TABLESPACE temp;
--Asignacion de privilegios para la cuenta antiormente creada
GRANT CONNECT, RESOURCE TO ogg_user;
GRANT SELECT ANY DICTIONARY, SELECT ANY TABLE TO ogg_user;
GRANT CREATE TABLE TO ogg_user;
GRANT FLASHBACK ANY TABLE TO ogg_user;
GRANT EXECUTE ON dbms_flashback TO ogg_user;
GRANT EXECUTE ON utl_file TO ogg_user;
GRANT CREATE ANY TABLE TO ogg_user;
GRANT INSERT ANY TABLE TO ogg_user;
GRANT UPDATE ANY TABLE TO ogg_user;
GRANT DELETE ANY TABLE TO ogg_user;
GRANT DROP ANY TABLE TO ogg_user;
GRANT ALTER ANY TABLE TO ogg_user;
GRANT ALTER SYSTEM TO ogg_user;
GRANT LOCK ANY TABLE TO ogg_user;
GRANT SELECT ANY TRANSACTION to ogg_user;
ALTER USER ogg_user QUOTA UNLIMITED ON ogg_data;
--Finalmente ejecutar lo siguiente:
exec DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('ogg_user');
ALTER SYSTEM SET enable_goldengate_replication=TRUE scope=both sid='*';
Posteriormente ejecutaremos los siguientes comandos también vía sqlplus “/as sysdba” con la salvedad que nos debemos encontrar en el directorio dónde se instaló goldengate, pues allí se encuentran los scripts. Estos scripts deben ser ejecutados tanto en la base de datos ORIGEN como DESTINO. Adicionalmente cada uno de scripts solicitará el nombre del esquema de Golden creado anteriormente:
cd /gg/12.2.0.1
sqlplus “/as sysdba” @marker_setup.sql
sqlplus “/as sysdba” @ddl_setup.sql
sqlplus “/as sysdba” @role_setup.sql
--Este commando es para asignar un rol fundamental
--al usuario de golden gate que no puede faltar
GRANT GGS_GGSUSER_ROLE TO ogg_user;
sqlplus “/as sysdba” @ddl_enable.sql
sqlplus “/as sysdba” @ddl_pin ogg_user
Configuración inicial del producto golden gate
Ahora se procederá a configurar el producto de GOLDEN GATE. Se deberá cargar las variables de ambiente apuntando al directorio de instalación de Golden gate para usar el utilitario de GG: ggsci
Una vez al interior de la herramienta ggsci ejecutaremos el comando create subdirs para crear todos los subdirectorios importantes:
Si al ejecutar la herramienta ggsci ven algún error como este:
./ggsci
./ggsci: error while loading shared libraries: libnnz12.so: cannot open shared object file: No such file or directory
falta que seteen la variable:
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
Editaremos el parámetro GLOBAL usando la herramienta ggsci, para agregar entre otras cosas el owner de base de datos para el esquema GOLDEN GATE:
edit params ./GLOBAL
--Agregar lo siguiente al archivo de parámetro GLOBAL y guardarlo
GGSCHEMA ogg_user
Editaremos el parámetro del manager usando la herramienta ggsci:
edit param mgr
--Añadiremos lo siguiente
PORT 7809
dynamicportlist 7900-7950
lagreportminutes 5
laginfominutes 1
lagcriticalminutes 2
purgeoldextracts ./dirdat/t*, minkeepdays 2, usecheckpoints
AUTORESTART EXTRACT *, RETRIES 10, WAITMINUTES 5, RESETMINUTES 60
AUTORESTART REPLICAT *, RETRIES 10, WAITMINUTES 5, RESETMINUTES 60
Levantaremos el manager y visualizaremos su estado con los comandos:
start mgr
info all
Ejecución de Initial Load y configuración de extractor
Ingresaremos a la herramienta GoldenGate ggsci y nos conectaremos a la instancia de origen. En este ejemplo activaremos un EXT/REP para una de las tablas de ejemplo del esquema SCOTT (Tabla DEPT)
NOTA: para los ORACLE_HOME de la instancia 11g y 12c se debe tener registrados los siguientes ALIAS en los archivos tnsnames.ora :
ORA11G =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraclelab)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ora11g)
)
)
ORA12C =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraclelab)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ora12c)
)
)
ASM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraclelab)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = +ASM)
)
)
Adicionalmente nuestro listener se encuentra escuchando para estos 3 servicios anteriormente señalados:
Dicho lo anterior procederemos:
Usando la herramienta ggsci habilitaremos el trandata para nuestra tabla de ejemplo:
dblogin userid ogg_user@ora11g, password oracle
add trandata scott.dept
Procederemos a crear nuestro database link para que nuestra carga inicial pase por red sin necesidad de escribir un archivo DMP en disco, para esto nos conectaremos a la instancia ora12c (el destino o target ) y creamos el database link siguiente:
--El database link lo crearemos dentro del mismo esquema
--con el cual realizaremos el impdp para la carga inicial
conn system/oracle
create database link ora11g connect to system identified by oracle using 'ora11g';
Ejecutamos nuestra carga inicial:
impdp system/oracle directory=data_pump_dir logfile=scott.log network_link=ora11g schemas=scott
Procederemos a crear nuestro extractor (todo esto dentro de nuestro utilitario ggsci )
NOTA: Se requiere el usuario y contraseña para acceder a la instancia ASM
dblogin userid ogg_user@ora11g, password oracle
edit params EXT1
--Procedemos a agregar lo siguiente a nuestro Nuevo extractor
extract EXT1
setenv (ORACLE_SID="ora11g")
setenv (ORACLE_HOME="/u01/app/oracle/product/11.2.0/dbhome_1")
userid ogg_user@ora11g, password oracle
TRANLOGOPTIONS ASMUSER sys@asm, ASMPASSWORD oracle
rmthost oraclelab, mgrport 7809
exttrail ./dirdat/aa
ddl include all
ddloptions addtrandata
--IGNORETRUNCATES
--IGNOREDELETES
table scott.dept ;
Agregamos nuestro extractor y lo enlazamos el TRAIL:
add extract EXT1 tranlog begin now
ADD EXTTRAIL ./dirdat/aa, EXTRACT EXT1
Subimos el extractor y verificamos con el commando info all que todo se encuentre bien:
start EXT1
info all
Configuración y activación del Replicador
Crearemos el replicador con su respectiva tabla de checkpoint usando los siguientes comandos (debemos conectarnos a la instancia 12c)
dblogin userid ogg_user@ora12c, password oracle
add checkpointtable ogg_user.ckptbl_scott_dept
add replicat rep1, exttrail ./dirdat/aa, CHECKPOINTTABLE ogg_user.ckptbl_scott_dept
Crearemos el replicador:
edit params REP1
--Agregar lo siguiente:
REPLICAT REP1
SETENV (ORACLE_SID="ora12c")
SETENV (ORACLE_HOME="/u01/app/oracle/product/12.1.0/dbhome_1")
userid ogg_user@ora12c, password oracle
DISCARDFILE ./dirrpt/REP1_discard.dsc, APPEND, MEGABYTES 4096
ASSUMETARGETDEFS
ddl include all
DDLERROR DEFAULT IGNORE RETRYOP
APPLYNOOPUPDATES
REPERROR DEFAULT ABEND
REPERROR 1403 IGNORE
REPERROR 1722 IGNORE
BATCHSQL BATCHESPERQUEUE 300, OPSPERBATCH 9000
INSERTAPPEND
MAP scott.DEPT, TARGET scott.DEPT;
Posteriormente levantaremos nuestro replicador con el comando start rep1 y posteriormente verificamos con info all que todo este OK:
Testing de la replicación de datos
En el ambiente de origen (sobre base de datos ora11g) realizamos una inserción de ejemplo:
insert into SCOTT.dept values (dbms_random.value(41,99), dbms_random.string('L',3) , dbms_random.string('L',3));
commit;
Posteriormente visualizaremos el estado de nuestra inserción usando los comandos desde ggsci. Estos stats nos deben mostrar que el insert realizado en el origen fue replicado con éxito hacia el destino:
Stats ext1
Stats rep1
Prueba de falla de Golden gate
Simulación de una falla
Como ejemplo de una posible falla de Golden Gate, durante una ventana de trabajo (suponiendo alguna mantención que implique una bajada de la base de datos) se baja el replicador y accidentalmente se eliminan archivos de ./dirdat/* o corrupción de algunos trails, perdiendo con ello como es de esperar las transacciones actuales, y con ello generando un GAP de transacciones entre el origen y el destino.
La secuencia de pasos seria la siguiente
Detención del replicador:
GGSCI (oraclelab) 1> stop rep1
Sending STOP request to REPLICAT REP1 ...
Request processed.
Se eliminan los archivos de trail de manera accidental para simular la falla
rm –f ./dirdat/*
Se sube replicador una vez terminada la actividad sobre la base de datos y este quedará con error:
GGSCI (oraclelab) 3> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT STOPPED EXT1 00:00:00 00:00:02
REPLICAT ABENDED REP1 00:00:00 00:04:01
Corrección de la falla
Mientras el replicador sigue en abended, en la base de datos de origen se siguen ingresando nuevas transacciones (en este ejemplo sobre la tabla Scott.dept)
Procedemos a detener el extractor EXT1 desde la herramienta de ggsci
Stop ext1
En la base de datos de origen ingresamos algunos registros adicionales (estos registros no serán aplicados en la base de datos de destino ya que el replicador ha quedado en abended). Esto será lo utilizado para efectos de generar y simular el GAP.
SQL> insert into SCOTT.dept values (dbms_random.value(41,99), dbms_random.string('L',3) , dbms_random.string('L',3));
1 row created.
SQL> commit ;
Commit complete.
SQL> insert into SCOTT.dept values (dbms_random.value(41,99), dbms_random.string('L',3) , dbms_random.string('L',3));
1 row created.
SQL> commit ;
Commit complete.
SQL>
El GAP serian los últimos dos registros de la siguiente imagen:
Como ya tenemos detectado el problema para resolverlo procederemos a activar nuevamente el extractor pero para que comience a extraer la información minutos antes de la falla. Los archivos de trail fueron borrados a las 23:18 hrs (para este ejemplo). A través de la herramienta de ggsci ejecutamos lo siguiente:
GGSCI (oraclelab) 2> Dblogin userid ogg_user@ora11g, password oracle
Successfully logged into database.
Wed Dec 13 15:06:07 CUT 2017
GGSCI (oraclelab as ogg_user@ora11g) 3> alter EXT1, tranlog begin 2017-11-15 22:17,ETROLLOVER
EXTRACT altered.
El log de Golden gate mostrará que se empezara a capturar registros desde esa fecha en adelante o lo más cercano posible a la fecha indicada.
Levantaremos el extractor nuevamente:
GGSCI (oraclelab as ogg_user@ora11g) 4> start ext1
Comprobaremos que el extractor nuevamente está trabajando y está sacando nuevamente las transacciones indicadas desde esa fecha:
[oracle@oraclelab dirdat]$ ls -lptr
total 4
-rw-r----- 1 oracle oinstall 2928 Nov 16 00:28 aa000000006
[oracle@oraclelab dirdat]$
Nos conectaremos a la base de datos de destino en ora12c y revisaremos el contenido de la tabla de checkpoint usada por el replicador (la tabla CKPTBL_SCOTT_DEPT). Nos fijaremos que el último CSN confirmado es el valor: 3700486
Editaremos el archivos de parámetros del replicador y añadiremos el parámetro temporal Handlecollisions:
edit param rep1
–Anadir al final del archivo lo siguiente y guardar:
HANDLECOLLISIONS
Con el valor CSN que hemos obtenido y según lo visualizado en este link:
Configuraremos el replicador para que al levantarlo y comience a aplicar las transacciones generadas a partir de ese cambio (CSN). Esto ejecutado en la herramienta ggsci
--El replicador lo configuraremos para que comience leyendo la secuencia 6
--Este valor “6” es obtenido de la secuencia de achivo que hemos vuelvo a generar
--al levantar el extractor anterior ya que comenzó a generar el archivo con este nombre
--como se pudo apreciar en el paso 5 anteriormente: aa000000006
dblogin userid ogg_user@ora12c, password oracle
alter rep1, extseqno 6, extrba 0
start rep1, aftercsn 3700486
Finalmente al consultar veremos que se han insertado los registros faltantes en el destino:
Luego de que la sincronización termine se debe quitar la keyword handlecollision al archivo de parámetro del replicador, luego se debe bajar y subir el replicador.
--eliminar del archivo de parámetro de rep1
HANDLECOLLISIONS
Se puede hacer online también de la siguiente manera (pero sin olvidar quitarlo del archivo de parámetros)
SEND REPLICAT REP1, NOHANDLECOLLISIONS scott.dept
También puede ocuparse el comando siguiente:
SEND REPLICAT REP1, NOHANDLECOLLISIONS *
*** FIN DE LA PRUEBA DE FALLA ***
