Technological recipes that I've held to prepare some solutions DBA environment. (by Felipe Donoso Bastias)

13 Jun 2018

Error en golden gate ERROR OGG-00303 Problem at line 37. Expecting file, table, or record definition: TimeZone



Hace poco me ha sucedido que durante una prueba de replicación de goldengate al momento de levantar el replicador este se me ha caido con el error siguiente:

ERROR OGG-00303 Problem at line 37. Expecting file, table, or record definition: TimeZone


El replicador ocupa un archivo de definición el cual fue credo con un goldengate 11g (goldengate origen) y estoy replicando hacia un ambiente goldengate 12c (goldengate destino). He ahi el problema. La versión 12c de goldengate integra un parámetro de Timezone al archivo de definición que el GG 11g no reconoce.

(linea de archivo de definición de mi replicador)
SOURCEDEFS ./dirdef/archivo_definicion_tablas_origen.def

Aqui la siguiente nota de soporte que explica como arreglar el problema.
OGG v11.2.1 Java Adapter Abend: OGG-00303 Expecting File, Table, Or Record Definition: TimeZone (Doc ID 2040347.1)

La solución es eliminar del archivo de definición el parámetro TimeZone. Luego de eliminar ese parámetro nuestro replicador levantará sin problemas.


Share:

5 Jun 2018

Bug 19213447 - ORA-600 [qkaffsindex3] sobre comandos Merge con índices basados en función

Dejo un tips que me paso hace poco en un cliente al ejecutar un comando MERGE sobre una base de datos 12cR1. Al ejecutar el merge sobre una tabla este devolvía un error interno del tipo: 

 ORA-600 [qkaffsindex3]


Investigando encontré que esto es un Bug que afecta a los releases de base de datos 12cR1. Esto sucede por un bug que afecta a las setencias MERGE que se realizan sobre tablas con índices basados en función (como es mi caso). Para evitar ese error se da un workaround en la siguiente nota:
Bug 19213447 - ORA-600 [qkaffsindex3] on MERGE query with function based indexes present (Doc ID 19213447.8)

El workaround es evitar que el optimizador ocupe en el plan algún índice basado en función (lo que podría traer alguna degradación de rendimiento pero evitar el error de Ora-600 en si)
alter session set "_disable_function_based_index"=true ;

Después de lo anterior ya no he vuelto a tener problemas.
Saludos.
Share:

19 Feb 2018

copiar datafile desde base primaria a standby con ASM


Hace poco me encontré con un datafile en una standby que tenia problemas (standby 12c con ASM). En resumen este era el error que se ve en la standby:

Mon Feb 19 18:21:21 2018
Errors in file /oracle/app/oracle/diag/rdbms/sarchive/SARCHIVE1/trace/SARCHIVE1_pr00_12911036.trc:
ORA-00448: normal completion of background process
Mon Feb 19 18:21:21 2018
Errors in file /oracle/app/oracle/diag/rdbms/sarchive/SARCHIVE1/trace/SARCHIVE1_mrp0_4718782.trc:
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 652, block# 3, file offset is unknown bytes)
ORA-10564: tablespace APPS_TS_TX_IDX
ORA-01110: data file 652: '+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.515.968523631'
ORA-10560: block type '0'
Mon Feb 19 18:21:21 2018

Ahora lo primero que se me ocurria era copia el datafile desde la primaria hacia la standby, pero como esta en ASM ambas bases de datos, hay que hacer un par de pasos adicionales. Estos pasos estan comentados en la siguiente nota:

How to Copy ASM datafile From Primary Database to Standby Database on ASM using RMAN (Doc ID 605234.1)


Bueno en resumen lo que hice fue obtener el nombre del archivo en la primary con el numero de datafile que tiene problemas en la standby (numero de datafile 652). Posteriormente usando rman en la primaria ejecute el siguiente comando:

RMAN> copy datafile '+ARCHIVE/ARCHIVE/DATAFILE/apps_ts_tx_idx.1304.968523459'  to '/gg/gg12c/respaldo/backup_file.dbf' ;

Starting backup at 19-FEB-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2 instance=ARCHIVE2 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00652 name=+ARCHIVE/ARCHIVE/DATAFILE/apps_ts_tx_idx.1304.968523459
output file name=/gg/gg12c/respaldo/backup_file.dbf tag=TAG20180219T183516 RECID=5 STAMP=968524773
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:04:25
Finished backup at 19-FEB-18

Aquello me generó el archivo: /gg/gg12c/respaldo/backup_file.dbf el cual debemos copiarlo a la standby:

scp /gg/gg12c/respaldo/backup_file.dbf t423:/gg/gg12c/respaldo/t423:/gg/gg12c/respaldo/             
oracle@t423's password:
backup_file.dbf                                                                  100%   29GB  24.7MB/s   20:16


Ahora nos ubicamos en la base de datos standby y procederemos a catalogar el nuevo archivo de backup:

rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Mon Feb 19 19:37:30 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ARCHIVE (DBID=4129028332, not open)

RMAN> Catalog datafilecopy '/gg/gg12c/respaldo/backup_file.dbf' ;

using target database control file instead of recovery catalog
cataloged datafile copy
datafile copy file name=/gg/gg12c/respaldo/backup_file.dbf RECID=8 STAMP=968528258


Ahora restauramos el datafile usando ese backup (sobre la standby):
RMAN> copy datafilecopy '/gg/gg12c/respaldo/backup_file.dbf'  to '+ARCHIVE';

Starting backup at 19-FEB-18
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input is copy of datafile 00652: /gg/gg12c/respaldo/backup_file.dbf

output file name=+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.1308.968528345 tag=TAG20180219T183516 RECID=9 STAMP=968531536
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:53:15
Finished backup at 19-FEB-18


Ahora desde la base de datos standby via sqlplus (cambiaremos el nombre del archivo ocupando el file_name antiguo:

SQL> Alter system set standby_file_management=manual scope=both sid='*' ;

System altered.

SQL> Alter database rename file '+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.515.968523631' to
'+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.1308.968528345' ;  2

Database altered.

SQL> Alter system set standby_file_management=auto scope=both sid='*' ;

System altered.


SQL> alter database recover managed standby database disconnect from session ;

Database altered.


Si por algun motivo se nos olvida poner de nuevo standby_file_management en auto la recuperacion de la standby se nos caera si es que desde la primary se crea un nuevo datafile mientras nosotros estabamos arreglando este problema. En el alert log de la base de datos aparecera que no se puede crear el siguiente archivo con un nombre similar a esto: UNNAMED00653

SI esto llegara a pasar hay que crear el archivo desde 0 usando lo siguiente (en ASM y con OMF activo)
alter database create datafile '/oracle/app/oracle/product/12.1.0/db_1/dbs/UNNAMED00653' as new;

Luego de esto dejar activo nuevamente el parametro:
Alter system set standby_file_management=auto scope=both sid='*' ;

Espero haya servido :)
PD: no olvidar eliminar el archivo original de backup tanto en la primaria como en la standby:

RMAN>  delete datafilecopy '/gg/gg12c/respaldo/backup_file.dbf' ;

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2 instance=ARCHIVE2 device type=DISK
List of Datafile Copies
=======================

Key     File S Completion Time Ckp SCN    Ckp Time
------- ---- - --------------- ---------- ---------------
5       652  A 19-FEB-18       51336108383 19-FEB-18
        Name: /gg/gg12c/respaldo/backup_file.dbf
        Tag: TAG20180219T183516


Do you really want to delete the above objects (enter YES or NO)? y
deleted datafile copy
datafile copy file name=/gg/gg12c/respaldo/backup_file.dbf RECID=5 STAMP=968524773
Deleted 1 objects


RMAN>

Share:

4 Feb 2018

12cR1 impdp con dblink ocupando opcion DISABLE_APPEND_HINT no funciona (lo omite por un bug)

La fotografia es de mi querido y bello Sobrino Matteo :)

Hace poco por un requerimiento de un cliente en dónde se necesitaba ejecutar varios comandos impdp que inyectaban datos sobre la misma tabla, me di cuenta que la versión 12cR1 (12.1.0.2) no toma en cuenta el parámetro DATA_OPTIONS=DISABLE_APPEND_HINT, simplemente lo omite por un BUG que afecta a esta versión de base de datos. Recordar que se debe deshabilitar el hint APPEND que realizan los import por default, porque de otro modo no mepermitira realizar otras inyecciones de datos sobre la misma tabla. No olvidemos que el hint APPEND realiza un bloqueo completo sobre la tabla, dejando al resto de los procesos impdp en estado waiting enq-tm contention o similar)

Bueno como les decia esto se trata de un BUG que a continuación les mencionaré. En el ejemplo siguiente me di cuenta problema:

impdp "user1/sdqweq"  PARALLEL=4 directory=impdp logfile=proceso01.log  network_link=dblink1 TABLES=table2:part01  Query=user1.table2:\"where APPLICATION_ID=20004 and AE_HEADER_ID like \'1\%\'\"  INDEXES=NO CLUSTER=NO EXCLUDE=STATISTICS  DATA_OPTIONS=DISABLE_APPEND_HINT TABLE_EXISTS_ACTION=APPEND

Luego de ejecutado el impdp procedemos a revisar la base de datos y se puede apreciar que la sesión del import ejecuta el siguiente comando:

INSERT /*+ APPEND NESTED_TABLE_SET_REFS  */ INTO    "user1"."table2"  KUT$ ("......

Como se puede apreciar efectivamente utiliza el hint append a pesar que en el comando impdp anterior se pone explicitamente que no lo haga.

Todo esto es parte del siguiente bug:
BUG:25684960 - IMPDP DATA_OPTIONS=DISABLE_APPEND_HINT IS IGNORED WHEN USING NETWORK_LINK

Ese bug es mencionado en la nota de soporte:
DataPump Network_Link Import Ignores DISABLE_APPEND_HINT (Doc ID 2273873.1)

En la misma nota se explica que el bug es solucionado aplicando el parche:
Patch 25972261: MERGE REQUEST ON TOP OF 12.1.0.2.0 FOR BUGS 25139545 25684960

Luego de aplicado el parche en el motor de base de datos y posteriormente ejecutado nuevamente el comando de import, se puede ver que efectivamente ya no se vuelve a ocupar el hint append permitiendo que otras sesiones pueden ingresar o modificar datos en la misma tabla:

INSERT /*+ NESTED_TABLE_SET_REFS  */ INTO    "user1"."table2"  KUT$ ("......

Espero haya servido amigos saludos.
Share:

Error al ejecutar datapatch: "make_path" is not exported by the File::Path module (Doc ID 1904046.1)






Estimados,

 les dejo un Tips de un error que ocurre a menudo cuando se aplica datapatch. Cuando se va a aplicar un parche de base de datos (el paso de ejecutar el datapatch) es un error comun ver el siguiente mensaje (sobre todo en ambientes con bastantes ORACLE_HOME o más de alguna versión distinta del motor de base de datos):

laboratorio01[/oracle/app/oracle/product/12.1.0/db_1/OPatch] ./datapatch
"make_path" is not exported by the File::Path module
Can't continue after import errors at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pm line 166
BEGIN failed--compilation aborted at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pm line 166.
Compilation failed in require at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pl line 67.
BEGIN failed--compilation aborted at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pl line 67.


El anterior mensaje sucede cuando no estamos ejecutando correctamente el comando anterior con las variables de ambiente de acuerdo a la instalación que nos corresponde. En mi caso me pasaba que las siguientes variables de ambiente se encontraban apuntando a un ORACLE_HOME distinto. Por lo que se sugiere revisar que estas variables apunten correctamente al ORACLE_HOME sobre el cual existe la base de datos que parcharemos:
export PERL5LIB=/oracle/app/oracle/product/12.1.0/db_1/perl/lib
export PERLBIN=/oracle/app/oracle/product/12.1.0/db_1/perl/bin

Ver la siguiente nota como referencia:
datapatch -verbose fails with error "Perl lib version (5.10.0) doesn’t match executable version (v5.14.1) " (Doc ID 1904046.1)

Luego de declaradas las variables de ambiente PERL5LIB y PERLBIN como corresponde el datapatch funcionará sin problemas.
Share:

14 Jan 2018

Golden Gate 12.2 no purga los trail ya ocupados por los replicadores (BUG 22912874 Doc ID 2149579.1)



Estimados,

Por si alguien ha notado que bajo golden gate 12.2 el mgr (manager) no purga o elimina los trail ya utilizados por los replicadores es debido a un Bug que existe que afecta  a esta versión.

Nota de soporte del problema: GoldenGate Manager (MGR) Not Cleaning Up Trail Files When PURGEOLDEXTRACTS Defined Twice Or More (Doc ID 2149579.1)

En mi caso yo en mi archivo de parámetros del manager (mgr.prm) tenia lo siguiente configurado:

PORT 7809
DynamicPortList 7840-8352
userid ggs@xxxxx, PASSWORD AACAAAAAAAAAAANAZFLEEFMGFAKAGEZCZEJATCLFZGYIHHEJ, BLOWFISH ENCRYPTKEY DEFAULT
PURGEOLDEXTRACTS ./dirdat/EXTBIBCC/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTBIBCT/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTBIBFA/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTBIBSD/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTBIBTC/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXAH/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXAL/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXDL/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXER/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXEV/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXSV/*, USECHECKPOINTS, MINKEEPHOURS 1
PURGEOLDEXTRACTS ./dirdat/EXTFAXTE/*, USECHECKPOINTS, MINKEEPHOURS 1
AUTORESTART EXTRACT *, RETRIES 10, WAITMINUTES 5, RESETMINUTES 60
AUTORESTART REPLICAT *, RETRIES 10, WAITMINUTES 5, RESETMINUTES 60

Como podrán ver tenia bastantes rutas de trails a eliminar y me sucedia que solo se me estaba purgando los trails aplicados de la ruta del primer comando PURGEOLDEXTRACTS es decir solo los trails del path: ./dirdat/EXTBIBCC/*

Eso se debe al Bug 22912874
asi que lo mejor pueden hacer es solo agregar al purgado la carpeta padre que contiene a los trails para que la ventana funcione.

Eejemplo:
PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 1

Luego de esto le dan un refresh al manager y asunto solucionado, los trails efectivamente los elimina (recordar que las tareas de mantenimiento golden gate las realiza cada 10 minutos)

GGSCI (test) 2> refresh mgr

Sending REFRESH request to MANAGER ...
Mgr Params Updated


La solución defintivia es migrar la versión de GG a 12.3   :)

Saludos amigos espero sirva.
Felipe.
Share:

4 Jan 2018

Configuración básica de Golden Gate y como arreglar un replicador ante una pérdida de los trail dat.


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”

  1. 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;

  1. Posteriormente ejecutaremos el siguiente comando que nos debe devolver como resultado: YES
SELECT supplemental_log_data_min, force_logging FROM v$database;

  1. 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='*';
  1. 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

  1. Una vez al interior de la herramienta ggsci ejecutaremos el comando create subdirs para crear todos los subdirectorios importantes:
  1. 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

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

  1. 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:

  1. Usando la herramienta ggsci habilitaremos el trandata para nuestra tabla de ejemplo:
dblogin userid ogg_user@ora11g, password oracle
add trandata scott.dept


  1. 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';

  1. Ejecutamos nuestra carga inicial:

impdp system/oracle directory=data_pump_dir logfile=scott.log network_link=ora11g schemas=scott


  1. 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 ;

  1. Agregamos nuestro extractor y lo enlazamos el TRAIL:
add extract EXT1 tranlog begin now
ADD EXTTRAIL ./dirdat/aa, EXTRACT EXT1

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


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

  1. 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;

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


  1. 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;

  1. 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
  1. Detención del replicador:
GGSCI (oraclelab) 1> stop rep1

Sending STOP request to REPLICAT REP1 ...
Request processed.

  1. Se eliminan los archivos de trail de manera accidental para simular la falla
rm –f ./dirdat/*

  1. 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)
  1. Procedemos a detener el extractor EXT1 desde la herramienta de ggsci
Stop ext1

  1. 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:

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

  1. Levantaremos el extractor nuevamente:
GGSCI (oraclelab as ogg_user@ora11g) 4> start ext1

  1. 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]$

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


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

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

  1. Finalmente al consultar veremos que se han insertado los registros faltantes en el destino:

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

  1. 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 ***
Share:

Copyright © DBA TIPS | Powered by Blogger
Design by SimpleWpThemes | Blogger Theme by NewBloggerThemes.com | Free Blogger Templates