Inicio > GoldenGate > Volver a sincronizar esquemas o tablas en Oracle GoldenGate

Volver a sincronizar esquemas o tablas en Oracle GoldenGate

En ocasiones en nuestras instalaciones de GoldenGate nos podemos encontrar con esquemas o tablas que quedan fuera de sincronía con el resto. Esto puede ser a causa de problemas que nos obligan a “saltar” ciertas transacciones o incluso a eliminar esquemas de la configuración de réplica para que ésta pueda continuar.

En esta entrada explicaremos como recuperar estos usuarios o tablas que han dejado de estar sincronizados sin tener que cargar nuevamente todos los esquemas o tablas de la réplica.

Usaremos dos sistemas, el primero disponible en todas las versiones de GoldenGate y tipos de BBDD y el segundo específico para GoldenGate 11.1.1 o superior y BBDD Oracle.

En ambos casos partiremos de un proceso EXTRACT que captura los datos en una BBDD origen y otro proceso REPLICAT que los entrega en una BBDD Destino.

Supongamos que tenemos algunas de las tablas/esquemas de la réplica que han dejado de estar sincronizados, a partir de este momento deberemos hacer:

Sincronización genérica

  1. Modificar las tablas a sincronizar en la BBDD Origen para que se capturen siempre todas las columnas de los registros modificados (no sólo las afectadas por la modificación). Esto lo podemos hacer mediante el parámetro COLS del comando ADD TRANDATA.
  2. Parar el REPLICAT que aplica los cambios en destino.
  3. Traspasar nuevamente los datos para los esquemas/tablas afectadas de la BBDD origen a la BBDD destino mediante el procedimiento que creamos oportuno (expdp/impdp, carga puntual de GoldenGate, comandos sql…). Durante el tiempo que se tarde en traspasar los datos se deberá intentar mantener las modificaciones sobre ese esquema al mínimo posible (lo ideal sería que no se realizara modificación alguna en esos esquemas) y evitar totalmente el DDL (las modificaciones de tablas).
  4. Finalmente arrancamos nuevamente el proceso de REPLICAT añadiendo a su configuración el parámetro “HANDLECOLLISIONS”. Este parámetro permite que GoldenGate trate las modificaciones realizadas durante el traspaso de datos sin provocar errores.
  5. Finalmente y una vez la réplica vuelva a estar “online” eliminaremos el parámetro del REPLICAT y el logging extra que hemos añadido a las tablas en origen.

Sincronización para BBDD Oracle y Oracle GoldenGate 11.1.1 o superiores

Notas: Para este procedimiento nos basaremos en lo indicado en la nota 1339317.1. El identificador del estado de la BBDD Oracle SCN (System Change Number) en nomenclatura Oracle GoldenGate equivale aproximadamente al CSN (Commit Sequence Number).

1. En primer lugar tendremos que añadir a los datos que capturamos de las tablas la información del SCN (System Change Number) al que pertenecen.

Estos datos ya se incluyen por defecto a partir de la versión 11.1.1.1 de GoldenGate, de manera que solo es necesario este paso si nos encontramos en la versión 11.1.1.0.

Por tanto, si nos encontramos en este caso tendremos que añadir al EXTRACT para cada una de las tablas/esquemas a sincronizar el siguiente parámetro:

table MIUSUARIO.MITABLA , Tokens (tk-csn = @GETENV (“TRANSACTION”, “CSN”)) ;

2. Paramos el REPLICAT en caso que no esté ABENDED (si por ejemplo hemos eliminado los esquemas/tablas de la réplica para permitir que ésta continúe).

3. Realizamos un export en la BBDD Origen de los esquemas tablas a sincronizar nuevamente especificando un SCN.

La sentencia que nos permite hacer esto es:

expdp system/xxxxx schemas=miusuario FLASHBACK_SCN=4746443 dumpfile=miusuario.dmp directory=midirectorio

Para conseguir el SCN actual de la BBDD podemos usar la siguiente select, deberemos seleccionar un SCN anterior al que nos indique la select.

select dbms_flashback.get_system_change_number from dual;

4. Importamos los datos en la BBDD destino.
5. Finalmente modificamos el REPLICAT indicando en las tablas o esquemas que acabamos de importar que queremos replicar solo cambios que dispongan de un SCN superior al indicado:

Para versión de GoldenGate anterior a  11.1.1.1 añadiriamos un filtro similar al siguiente:

map miusuario.*, target miusuario.* , Filter ( @NUMSTR (@TOKEN (“TK-CSN“)) > 4746443);

Para versión GoldenGate 11.1.1.1 o superior:

map miusuario.*, target miusuario.* , Filter ( @NUMSTR ( @GETENV (‘TRANSACTION’, ‘CSN’)) > 4746443);

Nota importante: Hemos usado comillas simples en esta ultima sentencia, si usáramos comillas dobles (como aparece en alguna nota de oracle support) confundiría el campo TRANSACTION con una columna de la tabla y fallaría.

Al arrancar el REPLICAT, solo nos queda esperar que la réplica se sincronice nuevamente. A partir del momento que la réplica esté nuevamente “online” se pueden eliminar los parámetros de filtro, ya que no serán necesarios.

Categorías:GoldenGate Etiquetas: , ,
  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 )

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 )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: