Heterogeneous Services: SQL a Teradata desde Oracle.

Oracle presenta unos productos de acceso a bases de datos no-Oracle que básicamente se pueden clasificar en dos grupos: Transparent Gateways y Heterogeneous Services.

Transparent Gateways son módulos de acceso a determinadas bases de datos (SQLServer, Sybase, Teradata, DB2…) Estos módulos están optimizados y ofrecen un mayor rendimiento, por lo que consisten en licencias que se compran por separado.

Por otra parte, los Heterogeneous Services (o Generic Connectivity) están basados en accesos por ODBC/OLEDB y son gratis, aunque el rendimiento es menor.

Ambos persiguen un mismo objetivo: acceder desde Oracle a bases de datos no-Oracle y que sea el propio Oracle el que se encargue de los aspectos de mapeo de tipos, transferencias, etc, etc…

Vamos a ver como podemos hacer para que desde una ventana sqlplus conectada a una instancia Oracle veamos los datos de tablas de una base de datos Teradata con simples ‘SELECTS’. Por supuesto, utilizaremos la segunda solucion (ODBC/OLEDB y GRATIS).

Vamos a ello.

¿Que vamos a necesitar?

Lo primero, que la infraestructura de los Heterogeneous Services (Tablas, ‘packages’, sinónimos, etc…) esté en la base de datos Oracle. Para ello ejecutamos como SYS el ‘script’ caths.sql:

SQL*Plus: Release 10.2.0.1.0 - Production on Jue Jun 18 13:22:55 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Introduzca el nombre de usuario: sys@XE.localhost as sysdba
Introduzca la contraseña:

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SYS@XE.localhost> @C:\bla\bla\...\10.2.0\server\RDBMS\ADMIN\caths.sql
create role hs_admin_role

...

Cuerpo del paquete creado.

Procedimiento PL/SQL terminado correctamente.

Confirmación terminada.

Lo siguiente en configurar es un origen de datos ODBC. Es muy importante que configuremos el origen de datos como DE SISTEMA (no de usuario).

El nuestro se va a llamar TD_HS:

TD_DS_1

TD_DS_2

Una vez con el origen de datos ODBC listo comenzamos con la configuración de Oracle:

Para que se entere el ‘listener’ de la conexión debemos informarle. Así en el listener.ora añadiremos una entrada bajo SID_LIST_LISTENER:

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = C:\bla\bla\...\server)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (SID_NAME = CLRExtProc)
      (ORACLE_HOME = C:\bla\bla\...\server)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (ORACLE_HOME = C:\bla\bla\...\server)
      (SID_NAME = TD_HS)
      (PROGRAM = hsodbc)
    )
  )

SID_NAME debe corresponder con nuestro orígen de datos ODBC. PROGRAM es el nombre del módulo de Heterogeneous Services para ODBC (hsodbc.exe)

También necesitaremos una entrada en el tnsnames.ora:

teradata.remote=
   (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)
              (HOST = XXX.XXX.XXX.XXX)
              (PORT = 1521)
     )
     (CONNECT_DATA =
         (SERVICE_NAME = TD_HS)
         (SID = TD_HS)
     )
     (HS = OK)
)

Como bien de ve en la configuración será el propio ‘listener’ de Oracle el que se encargue de gestionar las conexiones al ODBC.
HS = OK identifica que será un origen Heterogeneous Services. El SID / SERVICE_NAME debe ser una vez más el nombre del origen de datos ODBC. El HOST y el PORT son los del equipo local (donde está Oracle).

Por último, necesitamos un fichero para la configuración de Heterogeneous Services para el origen de datos. Este fichero se llamará init<SID name>.ora y estará en el directorio \hs\admin de la instalación: C:\bla\bla\…\server\hs\admin\initTD_HS.ora

#
# HS init parameters
#

HS_FDS_CONNECT_INFO = TD_HS
HS_FDS_TRACE_LEVEL = 1
HS_FDS_TRACE_FILE_NAME = C:\bla\bla\...\server\hs\admin\initTD_HS.trc

Lo importante aquí es la línea HS_FDS_CONNECT_INFO = TD_HS (una vez más el SID). Los otros son para establecer el nivel de las trazas y su fichero.

Si hemos llegado hasta aquí, podemos probar cómo están las cosas con un simple ‘tnsping’:

C:\>tnsping teradata.remote

TNS Ping Utility for 32-bit Windows: Version 10.2.0.1.0 - Production on 18-JUN-2009 13:46:53

Copyright (c) 1997, 2005, Oracle.  All rights reserved.

Archivos de parámetros utilizados:
C:\bla\bla\...\server\network\admin\sqlnet.ora

Adaptador TNSNAMES utilizado para resolver el alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = XXX.XXX.XXX.XXX) (PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = TD_HS) (SID = TD_HS)) (HS = OK))
Realizado correctamente (10 mseg)

C:\>

El ‘listener‘ escucha para nuestro TD_HS.

Lo más duro ya está hecho. Ahora sólo nos queda crear un simple dblink en Oracle:

CARLOS@XE.localhost> CREATE DATABASE LINK teradata.remote
CONNECT TO carlos IDENTIFIED BY xxxxxxxx
USING 'teradata.remote';

Enlace con la base de datos creado.

Si hemos hecho todo bien (y parece que sí), podríamos acceder a la base de datos Teradata con SQL Oracle desde sqlplus:

CARLOS@XE.localhost> SELECT COD_PROVINCIA,
  2                         DESC_PROVINCIA
  3                    FROM MY_DB.PROVINCIA@teradata.remote
  4                ORDER BY COD_PROVINCIA;

COD_PROVINCIA DESC_PROVINCIA
------------- --------------------
            1 Álava
            2 Albacete
            3 Alicante/Alacant
            4 Almería
            5 Ávila
            6 Badajoz
            7 Balears (Illes)
            8 Barcelona
            9 Burgos
           10 Cáceres
           11 Cádiz
           12 Castellón/Castelló
           13 Ciudad Real
           14 Córdoba
           15 Coruña (A)
           16 Cuenca
           17 Girona
           18 Granada
           19 Guadalajara
           20 Guipúzcoa
           21 Huelva
           22 Huesca
           23 Jaén
           24 León
           25 Lleida
           26 Rioja (La)
           27 Lugo
           28 Madrid
           29 Málaga
           30 Murcia
           31 Navarra
           32 Ourense
           33 Asturias
           34 Palencia
           35 Palmas (Las)
           36 Pontevedra
           37 Salamanca
           38 Santa Cruz de Tenerife
           39 Cantabria
           40 Segovia
           41 Sevilla
           42 Soria
           43 Tarragona
           44 Teruel
           45 Toledo
           46 Valencia/València
           47 Valladolid
           48 Vizcaya
           49 Zamora
           50 Zaragoza
           51 Ceuta
           52 Melilla
           99 Extranjero
          100 Desconocido

54 filas seleccionadas.

Plan de Ejecución
----------------------------------------------------------
Plan hash value: 3717373614

----------------------------------------------------------------------------------------------------------
| Id  | Operation        | Name          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Inst   |IN-OUT|
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |               |  2000 |   126K|       |    87   (3)| 00:00:02 |        |   |
|   1 |  SORT ORDER BY   |               |  2000 |   126K|   312K|    87   (3)| 00:00:02 |        |   |
|   2 |   REMOTE         | PROVINCIA     |  2000 |   126K|       |    52   (0)| 00:00:01 | TERAD~ | R->S |
----------------------------------------------------------------------------------------------------------

Remote SQL Information (identified by operation id):
----------------------------------------------------

   2 - SELECT "COD_PROVINCIA","DESC_PROVINCIA" FROM "MY_DB"."PROVINCIA" (accessing
       'TERADATA.REMOTE' )

Estadísticas
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
       1600  bytes sent via SQL*Net to client
        413  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         54  rows processed

CARLOS@XE.localhost>

¡Sí señor! Y el autotrace muestra que la ejecución ha sido ‘REMOTE’, como era de esperar.

Y lo que es mejor: podemos utilizar funciones nativas Oracle en el ‘SELECT’ a los datos Teradata:

CARLOS@XE.localhost> SELECT REPLACE(DESC_PROVINCIA,'M','#')
  2    FROM MY_DB.PROVINCIA@teradata.remote
  3   WHERE COD_PROVINCIA = 28;

REPLACE(DESC_PROVINCIA,'M','#')
---------------------------------------------------------------------------------------------------
#adrid

Plan de Ejecución
----------------------------------------------------------
Plan hash value: 1788691278

--------------------------------------------------------------------------------------------------
| Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT|
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |               |    20 |  1300 |    52   (0)| 00:00:01 |        |      |
|   1 |  REMOTE          | PROVINCIA     |    20 |  1300 |    52   (0)| 00:00:01 | ALMAC~ | R->S |
--------------------------------------------------------------------------------------------------

Remote SQL Information (identified by operation id):
----------------------------------------------------

   1 - SELECT "COD_PROVINCIA","DESC_PROVINCIA" FROM "MY_DB"."PROVINCIA" WHERE
       "COD_PROVINCIA"=28 (accessing 'TERADATA.REMOTE' )

Estadísticas
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        456  bytes sent via SQL*Net to client
        380  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

CARLOS@XE.localhost>

Y por supuesto, con los ‘GRANTS’ necesarios, no tenemos por qué limitarnos a ‘SELECTS’…

Saludos.

Carlos.

About these ads

12 respuestas a Heterogeneous Services: SQL a Teradata desde Oracle.

  1. Óscar de la Torre dice:

    Carlos,
    Según la nota 417255.1 del Metalink, Generic Connectivity es una característica desoportada así que a futuro, la opción pasa por Gateways.

    • carlosal dice:

      Óscar:

      ¡Cuánto tiempo!

      >>”Según la nota 417255.1 del Metalink, Generic Connectivity es una característica desoportada así que a futuro, la opción pasa por Gateways.”

      ¿Y van a seguir manteniendo los ‘Gateways’ como licencia por separado? ¡Qué morro!

      De todas formas, lo mismo siguen manteniendo los ‘Heterogeneous Services’ indocumentados (como ocurre con las conexiones ‘bequeath’, que se pueden seguir utilizando sin problemas y te ahorras el ‘listener’).

      Saludos.

      Carlos.

      • Óscar de la Torre dice:

        >>¿Y van a seguir manteniendo los ‘Gateways’ como licencia por separado? ¡Qué morro!

        Hombre, el negocio es el negocio y como ocurre con todas las nuevas funcionalidades poco a poco se persigue rentabilizar la inversión realizada en su desarrollo. Aún así, me reservo mi opinión personal que nunca se sabe quien lee estos blogs :)

  2. [...] afición a las herramientas ‘GUI’ y ‘automágicas’, y aprovechando lo visto aquí, me decidí a intentar la prueba con un Oracle XE y dos ‘dblinks‘ a dichos sistemas [...]

  3. Felipe dice:

    Buenas,

    estoy desarrollando un sistema en J2EE basado en BBDD Oracle, pero se debe conectar a Teradata para obtener algunos datos. Por restricciones técnicas, se debe usar OpenJPA que no es compatible con Teradata, y por restricciones de tiempo (lo de siempre con los plazos), vamos a utilizar el gateway de Oracle con Teradata. Mis dudas después de leer el artículo son las siguientes:

    1.- ¿Se necesita con la versión 11g de Oracle la licencia para usar los Transparent Gateway? ¿o bien ya está incluído si tienes la versión Enterprise?

    2. En el caso de usar los heterogeneous gateway, ¿cómo se configura en un sistema UNIX si no hay conexiones ODBC? ¿Se podría hacer con JDBC?

    Muchas gracias y buen blog ;)

    • carlosal dice:

      Hasta donde yo sé (Óscar sabe de esto más que yo, porque él sí es un ‘chico Oracle’) en la versión 11g la cosa cambia un poco: Ahora todo se llama ‘Heterogeneous Services’ y tiene dos tipos de ‘agents’: los ‘Database Gateways’ que son nativos y especificos para cada RDBMS -y de pago-, y lo que antes llamaban Heterogeneous Services (o Generic Connectivity) que ahora son los agentes ‘Gateway for ODBC’ y que solo permiten estas conexiones (desconozco lo que ha pasado con los antiguos HS OLEDB). Estos me parece que son gratis.

      Quizá tu opción sea utilizar un driver ODBC para UNIX…

      Saludos.

      Carlos.

      • Felipe dice:

        Gracias por tu temprana respuesta.

        He estado mirando algo más y si que me he dado cuenta de que todo se llama ahora igual, heterogeneous services con Gateway XXX (ODBC, Teradata, etc…) Pero sigo sin ver que para la 11g haya que pagar una licencia adicional, porque sí que he visto que o bien viene incluido en el CD Server o bien te lo puedes bajar desde Oracle.

        Para Unix ya he visto que también existe un driver ODBC, cosa que no sabía. Ya estoy mirando cómo se definen.

        Sobre la diferencia de rendimiento que comentas, en nuestro caso sólo vamos a hacer consultas una vez al día a Teradata para tenerlo todo en una vista materializada Oracle. Es decir, generaremos una vista materializada en oracle sobre una consulta a Teradata. De esta manera minimizamos los tiempos de acceso y también facilitamos las comparaciones y otras operaciones entre tablas de Oracle, ya que vamos a ver cambios entre tablas y versiones de los datos. ¿Crees que podemos tener algún problema de rendimiento o algún problema con las vistas materializadas?

        Gracias una vez más

        • carlosal dice:

          “¿Crees que podemos tener algún problema de rendimiento o algún problema con las vistas materializadas?”

          Como dije en el ‘post’, no es lo óptimo (y suelo huir del ODBC como de la peste). Depende de los datos a mover y de cómo sea la MV.

          Una cosa: las transacciones distribuidas vía dblink (aunque sean simples SELECTs) deben acabar SIEMPRE con un commit o con un rollback si no quieres dejar bloqueada la tabla en el sistema remoto.

          Saludos.

          Carlos.

          • Felipe dice:

            Mi intención también es evitar el ODBC como sea, por eso pregunté hasta si había posibilidad de usar JDBC. Si hacemos esto del dblink es porque estamos mal de tiempo y no nos da tiempo implementar el sincronismo para sacar los datos de teradata y meterlos en Oracle, con JDBC y sin un ORM.

            Sobre la vm, será completa, se hará una vez al día (por la noche cuando nadie trabaja) y deberá traer unos 350.000 registros como mucho.

            Lo del commit no lo había leído, pero me lo imaginaba, ya que en las restricciones había visto los problemas con los commit implícitos y que se recomienda hacer commit o rollback con los cursosres para evitar el ORA-1002

            Gracias

  4. carlosal dice:

    Felipe:

    El ORA-1002 al que te refieres no tiene nada que ver con las transacciones distribuidas a través de dblinks (y la necesidad de hacer commit/rollback tras un SELECT), sino con los COMMITS sobre filas de cursores abiertos con SELECT…FOR UPDATE.

    Saludos.

    Carlos.

  5. Oscarp dice:

    Me parece muy bueno Pero te recomendaria que las rutas las escribas completas no con /bla/bla/ no creo que cueste mucho trabajo copiar y pegarlas.
    Mas que todo pq siempre hay personas que no tienes idea y con esas abreviaturas las peudes perder mucho mas.
    Saludos.
    Oscar

    • CarlosAL dice:

      Las rutas, como comprenderás, dependen de cada instalación, con lo que no creo que sirva de mucho poner la ruta completa de MI instalación.
      Por otra parte, trato de evitar el odioso copia-pega: Se busca el ‘explicar y comprender’, no el ‘copiar y ya está’…
      Saludos.
      Carlos.

Deja un comentario

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

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 45 seguidores

%d personas les gusta esto: