Archive

Archive for the ‘GoldenGate’ Category

Generar comandos SQL a partir de los ficheros de trail de Oracle GoldenGate

Como ya hemos comentado en otras entradasGoldenGate es una herramienta que “permite capturar, enrutar, transformar y enviar datos transaccionales entre entornos heterogéneos en tiempo real”. Los datos (las transacciones) una vez capturados se almacenan en unos ficheros con formato propietario (independientes de la plataforma) llamados ficheros de “trail”. Vamos a revertir este proceso y obtener, de estos ficheros de trail, las sentencias SQL equivalentes a las transacciones almacenadas en ellos.

En esta entrada considero que el lector ya tiene un mínimo conocimiento de Goldengate, por lo que en caso contrario os recomiendo que reviséis la presentación que acompaña al post indicado anteriormente (ya que os estáis perdiendo un producto muy muy interesante).

Los datos capturados por GoldenGate se pueden almacenar en forma de ficheros de trail en diferentes puntos (dependiendo de la arquitectura escogida) y estos ficheros tendrán mas o menos información dependiendo de si ésta ha estado filtrada en la ruta hasta ese fichero concreto.

oracle_config

Pueden existir casos en que sea interesante disponer de las sentencias “SQL” que equivalen a los datos almacenados en estos ficheros de trail, o lo que es lo mismo, obtener las sentencias que GoldenGate ejecutaría en la BBDD destino al aplicar en ella esos ficheros de trail.

Existe una herramienta propia de GoldenGate llamada logdump que nos permite abrir estos ficheros, movernos entre las diferentes transacciones y sentencias, filtrar, buscar transacciones determinadas e incluso modificar el contenido de los ficheros.

El “aspecto” que tienen las transacciones mostradas mediante logdump dista mucho de lo que podríamos esperar si estamos acostumbrados a trabajar con sentencias SQL en herramientas tipo SQL*Plus o SQL*Developer:

logdumprecord_wseqinfoNo obstante podemos pasar estas sentencias SQL a formato “texto”, lo que nos permitirá trabajar con ellas (modificarlas/auditarlas/contabilizarlas) mas fácilmente.

La manera de conseguir esto consiste en crear un proceso de replica replicat, que leerá de los ficheros de trail y escribirá en un fichero de texto las sentencias (en lugar de aplicarlas a una BBDD).

Leer más…

Categorías:GoldenGate Etiquetas: , ,

Prueba real de integración de GoldenGate y Data Guard

En este post aportamos un ejemplo de integración de GoldenGate y Oracle Data Guard, aprovechando de cada uno sus mejores funcionalidades.

En primer lugar comentar que en ocasiones existen dudas sobre los usos “objetivo” de GoldenGate y Data Guard, en la siguiente gráfica podemos ver una descripción genérica de sus posibilidades.

gg_vs_sb

A grandes trazos, Data Guard nos aporta un entorno de recuperación ante desastres sólido y de alto rendimiento ideal para BBDD productivas críticas y con posibilidades de ser usado simultáneamente como entorno de bakup, reporting y pruebas.

GoldenGate por su parte es una herramienta de réplica heterogénea en tiempo real, de una enorme flexibilidad. Nos permite seleccionar de manera precisa los datos a replicar, enviar a cada destino solo los datos necesarios e incluso aplicar transformaciones en estos datos replicados. Todo ello sin ser intrusivo en las BBDD origen  y permitiendo replicas entre BBDD de diferentes tipos y fabricantes.

El cliente al que se le planteó esta arquitectura disponía en origen de un RAC productivo de 2 nodos y requería:

  1. Una solución de “Disaster Recovery” para su BBDD principal dentro del plan de “Bussines Continuity”. Este entorno de DR debería consistir en una réplica total de la BBDD en una ubicación remota, asegurando una pérdida de datos “cero” en caso de problemas.
  2. Descargar de su entorno principal ciertas selects realizadas por parte de sus clientes/proveedores. Un destino objetivo para estas selects eran BBDD en el “cloud”, por aportar flexibilidad y posibilidad de crecimiento bajo demanda.

La arquitectura planteada consistió en una BBDD Standby en un datacenter remoto replicada mediante Data Guard, así como la réplica de los datos necesarios para las selects mediante GoldenGate en BBDD remotas en el cloud. El siguiente esquema muestra la solución planteada:

solucion_planteada

Solución técnica:

  • La configuración de recuperación ante desastres con Data Guard consiste de un RAC de dos nodos en el CPD origen y una BBDD standby monoinstancia en el datacenter remoto.  La configuración mediante DataGuard permite conmutar el rol de las BBDD en unos pocos minutos, un alto rendimiento en la replica de la información y una perdida de datos “cero” en caso de problemas.
  • La BBDD que actúe como principal, independientemente de la que sea, está configurada para enviar la información de “redo” que genera además de a la correspondiente standby a una tercera BBDD que llamaremos “Downstream Database“.
  • En esta “Downstream Database” se ha configurado GoldenGate integrado con LogMiner para capturar los cambios de la BBDD productiva extrayendo estos del la información de “redo” recibida, la captura de datos por tanto no es un proceso intrusivo (no interfiere la BBDD principal para realizar la captura). Para optimizar más incluso el rendimiento se plantea configurar GoldenGate para capturar solo los datos del subconjunto de tablas implicado en las selects a externalizar (ignorando los cambios del resto de tablas).
  • Es el mismo GoldenGate quien, una vez capturados los cambios, los envía a las máquinas remotas y los aplica en sus respectivas BBDD. Las máquinas remotas sólo reciben el subconjunto de datos necesario para cada una de ellas, no todos los datos capturados. Las BBDD remotas pueden ser de fabricante, versión, arquitectura y dimensionamiento totalmente diferente a las originales, permitiendo ajustar su coste de mantenimiento al mínimo necesario para que realicen su cometido.
  • El cambio de roles de las BBDD principal/standby (sea mediante switchover o failover) no afecta el envío de los datos de redo a la BBDD de Downstream ni, por tanto, a la captura y aplicación de los cambios en las BBDD remotas. En caso de switchover/failover la réplica continua de manera trasparente sin necesidad de actuación por parte de los administradores.

Con esta configuración obtenemos todas las ventajas de Recuperación ante Desastres que nos aporta Data Guard así como una réplica trasparente, automática y no intrusiva de un subconjunto de datos a BBDD remotas de tipo “comodity” mediante GoldenGate.

Ajuntament de Girona: Disaster Recovery de sus BBDD Oracle con GoldenGate

junio 16, 2014 1 comentario

caso_exito_ajgirona_v3

El Ajuntament de Girona necesitaba asegurar la continuidad del negocio y una rápida recuperación de datos ante posibles desastres, a través de la replicación de su centro de datos a un segundo CPD. La plataforma está formada por 150 servidores y 100 TB de información.

Con el proyecto de Disaster Recovery (DR) se han cubierto los servicios críticos alojados en la plataforma VMware, en la base de datos Oracle y en la infraestructura CFIS. Este proyecto forma parte de un proceso de modernización de su infraestructura IT.

Los objetivos principales del proyecto eran la réplica del centro de datos, automatizando la transmisión de información para asegurar la recuperación, la alta disponibilidad, para garantizar la seguridad y accesibilidad de los datos replicados, y minimizar al máximo tanto el RPO (Recovery Point Objective: cantidad máxima de información que se puede llegar a perder, medida en tiempo anterior al desastre) como el RTO (Recovery Time Objective: tiempo máximo pactado para realizar la restauración del servicio).

El Ajuntament de Girona confió en avanttic para la implementación de Oracle GoldenGate:

Decidimos otorgar a avanttic Consultoría Tecnológica este proyecto dada su especialización en las soluciones de Oracle. El grupo implementó la solución GoldenGate de Oracle de forma eficiente y, ahora, gracias a Oracle, tenemos la solución de recuperación ante desastres que necesitamos.

Jacint Paredes, IT manager del Ajuntament de Girona

Lee los detalles del proyecto en la sección Oracle Customers de la web de Oracle (formato html).

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.

Leer más…

Categorías:GoldenGate Etiquetas: , ,

Oracle tools for Data Replication and Synchronization: Industry Leaders

junio 28, 2011 4 comentarios

En el último informe de Gartner sobre Data Integration Tools, las herramientas de Oracle aparecían con una valoración de 5 sobre 5 en la categoría de Data Replication and Synchronization:

La puntuación de esta categoría se calcula en base a estos pesos relativos:

Business Intelligence and Data Warehousing 10%
Data Consistency Between Operational Applications 25%
Data or System Migrations and Consolidations 35%
Master Data Management 10%
Interenterprise Data Acquisition or Sharing 10%

Oracle GoldenGate delivers low-impact, real-time data acquisition, distribution, and delivery across heterogeneous systems. Using this technology, it enables cost-effective and low-impact real-time data integration and continuous availability solutions. Oracle GoldenGate offers tighter integration with Oracle technologies and applications, support for additional heterogeneous systems, and improved performance. (web, datasheet)

Oracle Data Integrator Enterprise Edition delivers unique next-generation, Extract Load and Transform (E-LT) technology that improves performance, reduces data integration costs, even across heterogeneous systems. Unlike conventional ETL tools, Oracle Data Integrator EE offers the productivity of a declarative design approach, as well as the benefits of an active integration platform for seamless batch and real-time integration. In addition, hot-pluggable Knowledge Modules provide modularity, flexibility, and extensibility. (web, datasheet)

Real Time Data Integration

El uso combinado de ambos productos nos permite, por ejemplo, dar una solución de Business Intelligence en tiempo real cuando existe la necesidad de analizar la situación y estado del negocio, con los datos más actuales y sin necesidad de impactar en los sistemas críticos.

Traspaso inicial de datos con Oracle GoldenGate

Oracle GoldenGate es una herramienta de replicación de datos entre entornos heterogéneos. Permite configurar soluciones de alta disponibilidad, de integración de datos o de réplica en tiempo real.

Para los que desconozcáis este producto, os recomiendo visitar esta entrada del blog y, en especial, ver la presentación que lo acompaña.

En la entrada de hoy comentaré una parte de la configuración de GoldenGate que no aparece en la mayoría de ejemplos existentes en la Web: el traspaso inicial de datos.

Al configurar una réplica con GoldenGate lo más común es que en el entorno de destino no dispongamos de datos, por lo que como paso previo a la réplica deberemos traspasar los datos para posteriormente poder empezar a traspasar únicamente los cambios. A este proceso lo llamamos la “carga inicial”.

Las cargas iniciales normalmente tienen como hándicap que el origen de datos se mantiene activo, esto es, se siguen generando cambios durante el proceso de carga inicial de datos.

Tenemos varias opciones para realizar esta tarea:

  • Carga de datos en formato nativos con utilidades de la BBDD

En este caso replicaríamos la BBDD mediante las herramientas nativas de las que se disponga. En caso de Oracle podría ser desde una recuperación mediante RMAN (completa o Tablespace Point In Time Recovery) o mediante expdp/impdp.

Deberemos tener arrancado un proceso de EXTRACT/REPLICAT que controlará los cambios realizados durante el tiempo que dure la carga inicial y que posteriormente los aplicará en destino.

Leer más…