jueves, 4 de julio de 2013

Mover datos entre Oracle y otras Bases de Datos

Por más de 30 años Oracle ha liderado el mercado de bases de datos relacionales y ha apuntado no solo a ser la base de datos número 1 si no también el fabricante de software que encabeza la lista. No obstante, no es el único participante en el universo de bases de datos; existen muchas más: comerciales, libres de uso (con algunas restricciones) y de código abierto. Toda ellas con sus pro y sus contras dependiendo de los usos y de los gustos de cada uno.


Bajo este mercado se mueve una nueva batalla: las alianzas con los sistemas ERP (Enterprise Resource Planning). Para consolidarse también como las bases de datos más utilizadas por estos los fabricantes han puesto de moda dos términos "integración" y "big data" (visite el artículo sobre big data aquí).

La integración permite mover información desde cualquier fuente de datos a la base de datos que se utilice como estándar de operación. Aunque comúnmente estos procesos de ETL (Extracción - Transformación y Carga) tienen herramientas asociadas también es posible usar algunos servicios propios de los motores de bases de datos para "mover" datos de una fuente a un destino.

En este artículo revisaremos el funcionamiento de HTGS o HTS de Oracle, más conocido como los servicios heterogéneos, pero más allá de la configuración e instalación nos centraremos en algunos tips de rendimiento para este tipo de conectividad. Para hacerlo vamos a tomar como ejemplo una integración desde una base de datos Oracle a una base de datos MSSQL. Si aun no se tienen instalados y configurados estos servicios visite este BLOG para saber cómo hacerlo: Oracle Heterogeneous Services y MSSQL

En versiones de Oracle, anteriores a 9i,  la conectividad a otras bases de datos se podía realizar a través de "gateways" que eran un producto licenciable de forma independiente, sin embargo, la nueva batalla por el mercado ha hecho que aparezca un nuevo modelo sin costo llamado "Heterogeneous Services" (La documentación a partir de la version 11G de Oracle se refiere a estos como Database Gateways).

Básicamente estos servicios se comportan como los Database Links, sin embargo requieren de una instalación y configuración de acuerdo a estos pasos:
  • Instalar los paquetes para el funcionamiento de HTGS en la base de datos.
  • Configurar los archivos de conectividad de HTGS.
  • Configurar los archivos de conectividad de Oracle: tnsnames.ora, el listener.ora.
  • Configurar un ODBC/OLEDB para la BD destino a conectar.
  • Crear un DBLINK hacia la BD destino.
Qué tipo de comandos soportan los HTGS?

Con estos servicios es posible:
  • Ejecutar sentencias DML (SELECT, INSERT, UPDATE, DELETE) a tablas en la base de datos destino tal y como si estuviera accediendo a ellas dentro de Oracle.
  • Ejecutar sentencias DDL (Creación de objetos en la base de datos destino, dependiendo de cuáles son soportados por ésta)
  • Ejecutar llamados a procedimientos almacenados
Cómo se ejecutan los comandos HTGS en la base de datos destino?

En general todas las sentencias se ejecutan de la misma forma que en una base de datos Oracle local, solo se debe agregar el nombre del DBLINK creado. Por ejemplo:

INSERT INTO TABLA_REMOTA@HTGS_DBLINK (COL1, COL2) VALUES (VAL1, VAL2)
SELECT COL1, COL2 FROM TABLA_REMOTA@HTGS_DBLINK

También es posible crear objetos locales con referencia a objetos remotos, por ejemplo:

CREATE VIEW VISTA_LOCAL AS SELECT * FROM TABLA_REMOTA@HTGS_DBLINK

Finalmente también es posible utilizar SQL dinámico para ejecutar estas sentencias a través del uso de:

EXECUTE IMMEDIATE 'CONSULTA_SQL'

Cada que se ejecuta uno de estos comandos Oracle realiza una verificación del mismo (PARSING) para luego enviarlo a la base de datos remota. En caso de error evitará que la sentencia se ejecute.

Tips para el uso de HTGS

HTGS es una muy buena herramienta alternativa para procesos de integración, sin embargo, y dado que usa componentes creados de otros fabricantes se debe contemplar algunas consideraciones:

  • Para versiones 10g y 11g de Oracle se recomienda instalar el componente Oracle Database Gateways que se puede descargar aquí, antes que utilizar los ODBC genéricos que vienen con los sistemas operativos.
  • Algunas opciones propias del motor pueden mejorar el cargue de información a bases de datos remotas, como por ejemplo la opción BULK que es soportada por la mayoría de bases de datos. Esta es una muy buena opción para cargue masivo de datos, pero también hace un uso intensivo de recursos de memoria por lo que debe tratarse con cuidado.
  • Existen en el mercado algunas versiones comerciales de drivers ODBC que presentan un mejor rendimiento que los drivers nativos de cada motor. Es el caso de DataDirect que posee conectores para los bases de datos más usadas en el mercado. Puede descargarse para realizar una prueba de concepto y posteriormente licenciarse.
  • Dado que Oracle hace una interpretación de cada sentencia, esto puedo representar un tiempo adicional en el cargue de datos sobre la base de datos remota. Una alternativa para evitar hacer esta evaluación y dejar que se la base de datos remota quien la haga es utilizar un paquete propio de HTGS llamado DBMS_HS_PASSTHROUGH. Este paquete envía la sentencia directamente a la base de datos remota.
  • Para ejecutar el paquete DBMS_HS_PASSTHROUGH se debe hacer de la siguiente manera:
     DECLARE
      vCursor   INTEGER;
     BEGIN
      vCursor := DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@HTGS_DBLINK(CONSULTA_SQL)';
     EXCEPTION
      WHEN OTHERS THEN
       SENTENCIAS;
     END;

O también puede hacerse de la siguiente manera:

     BEGIN
      EXECUTE IMMEDIATE 'BEGIN :vCursor := DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@HTGS_DBLINK(:vSentencia); END;' USING OUT vCursor, IN vSentencia;
     EXCEPTION
      WHEN OTHERS THEN
       SENTENCIAS;
     END;
  • El manejo de excepciones es muy importante, tanto si se envían las sentencias con el DBLINK y mucho más si se hace uso del paquete DBMS_HS_PASSTHROUGH.
  • Se debe tener muy presente que los mensajes de error de las bases de datos son diferentes. Por ejemplo un error de llave única duplicada en Oracle tiene un único identificador, el 00001, mientras que en MSSQL puede ser el 2601 o el 2627.       

No hay comentarios.:

Publicar un comentario