Archivo

Archive for the ‘Tech – Data Management’ 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…

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

Procesamiento de imagenes en Oracle Database 11g

diciembre 19, 2013 Deja un comentario

Existen varias opciones para almacenar imágenes en BBDD Oracle. La manera más común es utilizar una columna de tipo BLOB y cargar una imagen como contenido binario.

A partir de la versión 11g, Oracle ha introducido Oracle Multimedia (anteriormente conocido como Oracle InterMedia), una extensión que permite guardar imágenes, audio, vídeo y otra información multimedial.

Oracle Multimedia introduce los objetos de tipo ORDAudio, ORDDoc, ORDImage, ORDVideo, and SI_StillImage y métodos para:

  • Extraer metadatos y atributos de datos multimediales
  • Incrustar metadatos generados por otras aplicaciones en ficheros imagen
  • Incorporar datos multimediales a partir de Oracle Multimedia, web servers, file systems, y otros servidores
  • Ejecutar operaciones y aplicar transformaciones a imágenes

En otras palabras, Oracle Multimedia permite manipular imágenes con una simple instrucción SQL.

En este post, el enfoque será en las operaciones que se pueden realizar sobre imágenes.

Empezamos creando una tabla donde guardaremos una imagen en formato TIFF.

CREATE TABLE AVT_IMG
(
ID NUMBER,
TIFF_IMG ORDSYS.ORDImage
);

Además se crea un directorio que apunte a la ubicación de las imágenes.

CREATE OR REPLACE DIRECTORY avt_img_dir as 'C:\Imagenes_Blog';

Directorio Imagenes
Construimos un objeto ORDImage a partir de la imagen y lo insertamos en la tabla que acabamos de crear.

Leer más…

Normalización de cadenas de texto en PL/SQL

octubre 16, 2013 5 comentarios

La normalización de cadenas de texto es uno de los temas recurrentes en el desarrollo de procesos ETL. Cuando se tratan datos anagráficos, es muy común encontrarse con duplicados debidos a errores tipográficos y de data entry.

Consideremos el siguiente ejemplo:

Ejemplo Datos Duplicados

Se puede ver que los dos registros se refieren a la misma persona física, pero hay elementos que impiden considerar los registros como duplicados perfectos. El NIF ha sido transcrito mal. Es presumible que el error venga de una introducción manual de los datos ya que la N y la H están muy cerca en el teclado español. Tanto el nombre como el domicilio aparecen en dos formatos distintos, mientras que en el caso de la población es el acento el que hace que no coincidan las dos cadenas.

¿Qué herramientas tenemos en PL/SQL para matchear los dos registros y eliminar los duplicados?

La función SOUNDEX devuelve una representación fonética de una cadena. El resultado es la codificación de cómo se pronunciaría un texto en inglés. A pesar de que estemos trabajando con texto en otro idioma, la función puede resultar útil.

Si la aplicamos por ejemplo a la población, tendremos:

SELECT POBLACIO, SOUNDEX(POBLACIO)
FROM CLIENTES
WHERE NOMDES LIKE '%SCOTT%'

Ejemplo SOUNDEX

En este caso, el código resultante es el mismo y podríamos utilizarlo para considerar que tienen igual valor.

En otros casos, como el nombre, el resultado de la función SOUNDEX no nos ayuda.

SELECT NOMDES, SOUNDEX(nomdes)
FROM CLIENTES
WHERE NOMDES LIKE '%SCOTT%'

El package UTL_MATCH contiene unas funciones desarrolladas para facilitar la detección de duplicados. Hay cuatro funciones:

  • EDIT_SIMILARITY: la función calcula la distancia de Levenshtein. Esta medida debe el nombre al científico ruso que desarrolló un algoritmo para medir la distancia entre dos cadenas de texto s1 y s2. La distancia se calcula como numero de inserciones, cambios, cancelaciones de caracteres que permiten pasar de la cadena s1 a la cadena s2. La función devuelve un número que representa la distancia entre las dos cadenas: 0 indica dos cadenas idénticas. En el ejemplo, si asumimos que el formato correcto es “NOMBRE APELLIDO”, la función devuelve:
SELECT nomdes, utl_match.edit_distance(NOMDES, 'SCOTT TIGER')
FROM clientes
WHERE NOMDES LIKE '%SCOTT%'Ejemplo EDIT_DISTANCE

La distancia entre las dos cadenas no es muy grande y podríamos considerar las dos cadenas como coincidentes.

  • EDIT_DISTANCE_SIMILARITY: actúa como la función EDIT_SIMILARITY pero devuelve un valor normalizado entre 100 (cadenas coincidentes) y 0 (total discordancia).
  • JARO_WINKLER: esta función utiliza el algoritmo de Jaro-Winkler que calcula un índice de similitud entre dos cadenas, para intentar tener en cuenta posibles errores tipográficos. El valor 1 representa dos cadenas coincidentes.
    Ejemplo JARO-WINKLER
  • JARO_WINKLER_SIMILARITY: la función utiliza el algoritmo de Jaro-Winkler y normaliza los resultados entre 0 y 100.

Las funciones del paquete UTL_MATCH permiten definir un umbral de aceptabilidad para establecer si dos cadenas coinciden “lógicamente” y pueden resultar una herramienta muy útil en el proceso de data cleansing.

Categorías:Tech - Data Management Etiquetas: , ,

Oracle Data Modeler: Herramienta gratuita para el modelado de datos

octubre 18, 2012 3 comentarios


En todo proyecto de desarrollo, independientemente de la tecnología o herramienta seleccionada para su implementación, existe la necesidad de almacenar y por lo tanto, de modelar previamente los datos.

Podemos encontrar en el mercado diversas herramientas de pago de reconocido prestigio que nos ayudarán a realizar esta tarea, pero hay también algunas herramientas gratuitas como Oracle Data Modeler capaces de satisfacer las necesidades habituales en el campo del modelado. Oracle Data Modeler lleva ya tiempo disponible y, tras varias versiones (se publicó la semana pasada la 3.1.3), consideramos que ha alcanzado ya el grado de madurez (y robustez) necesario para participar en proyectos empresariales, ayudando a mejorar la productividad, por lo que, como puede ser de utilidad en muchos supuestos, creemos que continúa siendo interesante difundir su existencia.

Oracle Data Modeler es una aplicación que puede ejecutarse de manera independiente o incorporarse como un módulo en otras herramientas como por ejemplo la también gratuita Oracle SQL Developer. Al estar desarrollada en Java, corre sobre cualquier plataforma, y a través de drivers JDBC permite trabajar con los principales motores de base de datos del mercado.


Oracle Data Modeler es fácil de instalar y no tiene coste alguno. Sus funcionalidades son tantas que la mejor manera de evaluarlo es descargarlo aquí y evaluarlo uno mismo, por lo que para animaros, introducimos a continuación algunas de sus características:

  • Los modelos se almacenan en el sistema de ficheros, bajo una estructura de directorios (por lo que son fáciles de transportar, archivar, etc.)
  • Puede trabajar con cualquier base de datos, no está restringido a Oracle
  • Permite realizar ingeniería inversa
  • Dispone de los siguientes niveles de diseño: lógico, relacional y físico, con herramientas de generación automática en ambos sentidos.
  • Cada modelo puede tener diferentes implementaciones físicas (en diferentes tecnologías)
  • Permite definir dominios de tipos de datos
  • Compara diferencias entre modelos
  • Soporte para código almacenado, vistas materializadas, etc. (no sólo tablas y vistas)
  • Versionado de objetos
  • Herramienta de diseño visual y rica en herramientas (colores personalizables, deshacer, búsqueda de objetos, etc.)
  • Múltiples opciones en la generación del DDL

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…