Lo que nunca debería ocurrir…

29 octubre \29\UTC 2015

…y menos en un entorno de producción:

blocked

Una buena estrategia y configuración de backups es fundamental para no impedir o entorpecer el trabajo de los usuarios y la ejecución de procesos durante las horas de explotación.

Saludos.

Carlos.


Teradata FORMAT: comportamiento caprichoso (cuanto menos)

15 julio \15\UTC 2015

La cláusula FORMAT sirve para fijar el formato con el que se mostrará una columna, pero también influye en el formato que se aceptará en los INSERTs con CASTs implícitos.

Vamos a ver un ejemplo con formatos para DATE y TIME:

SHOW TABLE CARLOS.PRUEBA12;

 *** Text of DDL statement returned.
 *** Total elapsed time was 1 second.

CREATE MULTISET TABLE CARLOS.PRUEBA12 ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT,
     DEFAULT MERGEBLOCKRATIO
     (
      ID_N INTEGER NOT NULL,
      D_FECHA DATE FORMAT 'yyyymmdd',
      H_HORA TIME(0) FORMAT 'hhmiss')
PRIMARY INDEX ( ID_N );


 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA12 VALUES (1, '20150715',NULL);


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.


 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA12 VALUES (2, NULL, '182716');


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

El formato definido para la columnna hace incluso que se rechacen cadenas en formato ANSI / ISO-8601:

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA12 VALUES (3, NULL, '18:28:16');

 *** Failure 6758 Invalid time.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.

 
 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA12 VALUES (6, '2015-07-15', NULL);

 *** Failure 3535 A character string failed conversion to a numeric value.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.
 
 
 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N, D_FECHA, H_HORA
FROM CARLOS.PRUEBA12;


 *** Query completed. 2 rows found. 3 columns returned.
 *** Total elapsed time was 1 second.

       ID_N   D_FECHA  H_HORA
-----------  --------  ------
          1  20150715  (null)
          2    (null)  182716

Así vemos que hemos fallado miserablemente al insertar fechas y horas en formato diferente al establecido con el FORMAT en la creación de la tabla.

Pero ahora es cuando las cosas se lían un poco:

Creamos el fichero C:\Basura\PRUEBAFORMAT.txt como:

3;20150715;183125
4;20150715;183145

E intentamos una carga con un .IMPORT FILE (nótese que las filas en el fichero respetan los formatos definidos):

 BTEQ -- Enter your SQL request or BTEQ command:
.IMPORT VARTEXT ';' FILE C:\Basura\PRUEBAFORMAT.txt;
 BTEQ -- Enter your SQL request or BTEQ command:
.REPEAT *
 BTEQ -- Enter your SQL request or BTEQ command:
USING
  id_n    (VARCHAR(1)),
  d_fecha (VARCHAR(8)),
  h_hora  (VARCHAR(6))
INSERT INTO CARLOS.PRUEBA12 (ID_N, D_FECHA, H_HORA) 
VALUES (:id_n, :d_fecha, :h_hora);
 *** Starting Row 0 at Wed Jul 15 18:37:37 2015

 *** Failure 6758 Invalid time.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.


 *** Failure 6758 Invalid time.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.


 *** Warning: Out of data.
 *** Finished at input row 2 at Wed Jul 15 18:37:37 2015
 *** Total number of statements: 2,  Accepted : 0,  Rejected : 2

 *** Total elapsed time was 1 second.

 *** Total requests sent to the DBC = 2
 *** Successful requests per second =  2.000

¡Fallo!

Probamos con la carga del mismo fichero, pero como de longitud fija, por si acaso:

 BTEQ -- Enter your SQL request or BTEQ command:
.IMPORT FILE C:\Basura\PRUEBAFORMAT.txt;
 *** Warning: No IMPORT mode was given, assuming field mode.
 BTEQ -- Enter your SQL request or BTEQ command:
.REPEAT *
 BTEQ -- Enter your SQL request or BTEQ command:
USING
  id_n    (CHAR(1)),
  filler1 (CHAR(1)),
  d_fecha (CHAR(8)),
  filler2 (CHAR(1)),
  h_hora  (CHAR(6))
INSERT INTO CARLOS.PRUEBA12 (ID_N, D_FECHA, H_HORA) 
VALUES (:id_n, :d_fecha, :h_hora);
 *** Starting Row 0 at Wed Jul 15 18:45:12 2015

 *** Failure 6758 Invalid time.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.


 *** Failure 6758 Invalid time.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.

 *** Warning: Out of data.
 *** Finished at input row 2 at Wed Jul 15 18:45:12 2015
 *** Total number of statements: 2,  Accepted : 0,  Rejected : 2

 *** Total elapsed time was 1 second.

 *** Total requests sent to the DBC = 2
 *** Successful requests per second =  2.000

¡El mismo fallo!

Pero el formato sigue funcionando para cadenas insertadas ‘a mano’ en sentencias:

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA12 VALUES (3, '20150715','184415');


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.


 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N, D_FECHA, H_HORA
FROM CARLOS.PRUEBA12;


 *** Query completed. 3 rows found. 3 columns returned.
 *** Total elapsed time was 1 second.

       ID_N   D_FECHA  H_HORA
-----------  --------  ------
          1  20150715  (null)
          2    (null)  182716
          3  20150715  184415

Y para terminarlo de liar, modificamos el fichero C:\Basura\PRUEBAFORMAT.txt:

4;20150715;
5;20150715;

Es decir, dejamos las fechas según el FORMAT definido, pero hacemos NULL las horas.

Y hete aquí que:

 BTEQ -- Enter your SQL request or BTEQ command:
.IMPORT VARTEXT ';' FILE C:\Basura\PRUEBAFORMAT.txt;
 BTEQ -- Enter your SQL request or BTEQ command:
.REPEAT *
 BTEQ -- Enter your SQL request or BTEQ command:
USING
  id_n    (VARCHAR(1)),
  d_fecha (VARCHAR(8)),
  h_hora  (VARCHAR(6))
INSERT INTO CARLOS.PRUEBA12 (ID_N, D_FECHA, H_HORA) VALUES (:id_n, :d_fecha, :h_hora);
 *** Starting Row 0 at Wed Jul 15 18:48:15 2015


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 *** Warning: Out of data.
 *** Finished at input row 2 at Wed Jul 15 18:48:15 2015
 *** Total number of statements: 2,  Accepted : 2,  Rejected : 0

 *** Total elapsed time was 1 second.

 *** Total requests sent to the DBC = 2
 *** Successful requests per second =  2.000

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N, D_FECHA, H_HORA
FROM CARLOS.PRUEBA12;


 *** Query completed. 5 rows found. 3 columns returned.
 *** Total elapsed time was 1 second.

       ID_N   D_FECHA  H_HORA
-----------  --------  ------
          1  20150715  (null)
          2    (null)  182716
          3  20150715  184415
          4  20150715  (null)
          5  20150715  (null)

¡Y se insertan!

Resumiendo: Los formatos para fechas y horas definen la validez en las inserciones con CASTs implícitos hechas en sentencias. Pero si utilizamos un fichero con IMPORT FILE sólo funcionan en el caso de las fechas (DATE), y fallan en el caso de las horas (TIME).

Ya lo sé, ya lo sé: a mí tampoco me gusta.

Saludos.

Carlos.


Convertir filas a cadenas en Teradata (II)

25 mayo \25\UTC 2015

El viejo problema de convertir filas a cadenas de caracteres es un tema recurrente y ha sido tratado aquí. Normalmente hay que recurrir a algún tipo de recursividad (incluso en Oracle) y suele resultar un tanto engorroso.

Pero resulta que hay otro método. Aunque es un tanto extraño, ya que necesita utilizar Teradata XML Services, y más específicamente la función XMLAGG.

Esta función agrega múltiples filas para construir un valor XML (devuelve un XMLTYPE). Pero lo interesante es que podemos utilizarla para algo que no tiene que ver con XML: convertir filas en cadenas.

Veamos cómo:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT * FROM PRUEBA08;


 *** Query completed. 4 rows found. 2 columns returned.
 *** Total elapsed time was 1 second.

       ID_N  C_TXT
-----------  -------------------------
          3  TRES
          1  UNO
          4  CUATRO
          2  DOS


 BTEQ -- Enter your SQL request or BTEQ command:
SELECT XMLAGG(C_TXT ORDER BY ID_N) FROM CARLOS.PRUEBA08;


 *** Query completed. One row found. One column returned.
 *** Total elapsed time was 1 second.

XMLAGG(C_TXT ORDER BY ID_N ASC RETURNING SEQUENCE)
--------------------------------------------------
UNO DOS TRES CUATRO

¿Así de fácil? Casi. Hay que tener en cuenta que XMLAGG se comporta como una función de agregación (sí, como SUM(), COUNT(), MAX()…):

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N,XMLAGG(C_TXT ORDER BY ID_N) FROM CARLOS.PRUEBA08;

 *** Failure 3504 Selected non-aggregate values must be part of the associated group.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.

Exacto:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N,XMLAGG(C_TXT ORDER BY ID_N) 
FROM CARLOS.PRUEBA08 GROUP BY 1;


 *** Query completed. 4 rows found. 2 columns returned.
 *** Total elapsed time was 1 second.

       ID_N XMLAGG(C_TXT ORDER BY ID_N ASC RETURNING SEQUENCE)
----------- --------------------------------------------------------------------------------
          3 TRES
          1 UNO
          4 CUATRO
          2 DOS

Teniendo eso claro, lo tenemos casi:

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA08 VALUES (1,'DOS');


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.


 BTEQ -- Enter your SQL request or BTEQ command:


INSERT INTO CARLOS.PRUEBA08 VALUES (1,'TRES');


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.


 BTEQ -- Enter your SQL request or BTEQ command:


INSERT INTO CARLOS.PRUEBA08 VALUES (2,'TRES');


 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.
 
 BTEQ -- Enter your SQL request or BTEQ command:
SELECT * FROM CARLOS.PRUEBA08 ORDER BY 1;


 *** Query completed. 7 rows found. 2 columns returned.
 *** Total elapsed time was 1 second.

       ID_N  C_TXT
-----------  -------------------------
          1  UNO
          1  DOS
          1  TRES
          2  DOS
          2  TRES
          3  TRES
          4  CUATRO

Entonces:

  BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N, XMLAGG(C_TXT) 
FROM CARLOS.PRUEBA08 GROUP BY 1 ORDER BY 1;


 *** Query completed. 4 rows found. 2 columns returned.
 *** Total elapsed time was 1 second.

       ID_N XMLAGG(C_TXT RETURNING SEQUENCE)
----------- ----------------------------------------------------------
          1 UNO DOS TRES
          2 DOS TRES
          3 TRES
          4 CUATRO

Sólo queda un asunto menor: XMLAGG devuelve XML:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N,
       TYPE(XMLAGG(C_TXT)) 
  FROM CARLOS.PRUEBA08 GROUP BY 1 ORDER BY 1;


 *** Query completed. 4 rows found. 2 columns returned.
 *** Total elapsed time was 1 second.

       ID_N  Type(XMLAGG(C_TXT ORDER BY ID_N ASC RETURNING SEQUENCE))
-----------  --------------------------------------------------------
          1  SYSUDTLIB.XML
          2  SYSUDTLIB.XML
          3  SYSUDTLIB.XML
          4  SYSUDTLIB.XML

Por lo que un ‘cast‘ le pone la guinda al pastel:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT ID_N, 
       XMLAGG(C_TXT) (VARCHAR(64)) 
  FROM CARLOS.PRUEBA08 GROUP BY 1 ORDER BY 1;


 *** Query completed. 4 rows found. 2 columns returned.
 *** Total elapsed time was 1 second.

       ID_N  XMLAGG(C_TXT RETURNING SEQUENCE)
-----------  ----------------------------------------------------------------
          1  UNO DOS TRES
          2  DOS TRES
          3  TRES
          4  CUATRO

Y si en vez de un espacio queremos un separador específico (‘|’, ‘;’, ‘,’…), es un juego de niños implementarlo.

Saludos.

Carlos.


DATE + TIME as TIMESTAMP

12 mayo \12\UTC 2015

Otra más de ‘casting‘ entre diferentes tipos de fechas, horas y ‘timestamps‘: ¿cómo obetener un TIMESTAMP a partir de un DATE y un TIME?

Podemos intentar una suma directa:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT (CURRENT_DATE + CURRENT_TIME(0));

 *** Failure 5407 Invalid operation for DateTime or Interval.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.

Error.

Podemos sumarle un TIME a un DATE convertido en TIMESTAMP:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT CAST(CURRENT_DATE AS TIMESTAMP(0)) + CURRENT_TIME(0);

*** Failure 5407 Invalid operation for DateTime or Interval.
               Statement# 1, Info =0
*** Total elapsed time was 1 second.

Otro error.

Siempre podríamos convertir el DATE y el TIME a cadenas de caracteres, concatenar y volver a convertir a TIMESTAMP, pero hay otra solución.

Ya vimos que las operaciones entre TIMESTAMPs siempre resultan en INTERVALS. Lo mismo ocurre con los TIME:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT CURRENT_TIME - TIME '01:00:00' HOUR TO SECOND(0);


 *** Query completed. One row found. One column returned.
 *** Total elapsed time was 1 second.

(Current Time(0) - 01:00:00) HOUR TO SECOND
-------------------------------------------
                                   18:46:09

Por otra parte, siempre podemos sumar un INTERVAL a un TIMESTAMP:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT CURRENT_TIMESTAMP(0) + INTERVAL '1' HOUR;


 *** Query completed. One row found. One column returned.
 *** Total elapsed time was 1 second.

(Current TimeStamp(0)+ 1)
-------------------------
2015-05-12 19:50:08+00:00

Así que, convirtiendo TIME en INTERVAL, sí podemos sumarlo a un TIMESTAMP. Y no hay forma más sencilla que restarle un TIME que en realidad no reste nada: ’00:00:00′.

 
 BTEQ -- Enter your SQL request or BTEQ command:
SELECT CAST(CURRENT_DATE AS TIMESTAMP(0)) + 
((CURRENT_TIME - TIME '00:00:00') HOUR TO SECOND(0)) DT_TO_TIMESTAMP;


 *** Query completed. One row found. One column returned.
 *** Total elapsed time was 1 second.

    DT_TO_TIMESTAMP
-------------------
2015-05-12 18:52:41

Saludos.

Carlos.


I stand corrected… TTUs for Apple OS X

8 mayo \08\UTC 2015

En alguna entrada de este blog dije que no existían TTUs para Mac. Pues bien: estaba equivocado. Las TTUs para Mac (una versión reducida de las TTUs, en realidad) existen, aunque no son de ‘dominio público’. Se deben bajar de Teradata At Your Service.

Si puedes conseguirlas, están en forma de .tar.gz:

TeradataToolsAndUtilitiesBase__macosx_x86_64.15.10.01.00.tar.gz

No hay mas que descomprimirlas a un directorio de trabajo (donde se descomprimirán en forma de directorio “Teradata_Client“) y allí está el TeradataToolsAndUtilities15.10.01.00.pkg. Pinchas en él y aparece el instalador, en el que pinchas ‘continue’, ‘continue’, ‘continue’… ‘install’ y:

TTUs On Mac 1

TTUs On Mac 1

 

La instalación queda ubicada en /Applications/Teradata Client 15.10/ y el software en /Library/Application Support/teradata/client/15.10/

TTUs On Mac 2

TTUs On Mac 2

Saludos.

Carlos.


Arreglando Teradata Studio en Teradata Express for VMware

23 abril \23\UTC 2015

Hace algún tiempo decidí instalar Teradata Studio 15 en la máquina virtual de Teradata 14.10 sobre SLES11. Bajé el fichero comprimido desde downloads.teradata.com y seguí las instrucciones (descomprimir el tar.gz, ejecutar como ‘root‘ studioinstall, etc…) y Teradata Studio 15 quedó instalado.

Pero las cosas se empezaron a torcer cuando comencé a utilizarlo: cada vez que abría una ‘perspectiva’ de ‘query development‘ la aplicación se cerraba. Miré los logs y allí se indicaba que había un problema:

Problematic frame: libpangoft2-1.0.so.0+0x18df1

Miré y miré, le pregunté a Francine Grimmer, quien me dijo que borrase el ‘workspace’ y empezase otra vez, pero no obtuve ningún cambio visible. Así que dejé el tema aparcado…

Recientemente apareció Teradata Studio 15.10, y pensé “¡Ya está! Desinstalo la versión 15.0, instalo la 15.10 y seguramente los problemas desaparecerán…” Qué iluso.

Después de desinstalar la 15.0, bajarme e instalar la 15.10 el problema seguía exactamente igual. Así que, cabezón que es uno, me puse a investigar cuál podría ser el problema. Después de mucho buscar, encontré una referencia a un problema del java runtime environment (jre) 1.6 que viene instalado en la máquina virtual de Teradata 14.10 sobre SLES11. Solución: actualizarlo.

Así pues, me bajé la última versión (jre1.8) desde el ‘site’ de Oracle (puajjj) y me dispuse a instalarla en forma de rpm (rpm -ivh …) Pero aquí también pinché en hueso: la instalación abortaba reclamando ‘alternatives’. Esto lo solucioné con un symbolyc link de ‘update-alternatives’ mediante:

ln -s /usr/sbin/update-alternatives /usr/sbin/alternatives

y ejecutando la instalación del jre con:

rpm -ivh --nodeps jre-8u45-linux-x64.rpm

So far, so good, pero ahora hay que indicarle al sistema que utilice este jre 1.8 en vez del corrupto 1.6. Esto lo hacemos editando el fichero /etc/profile (que todos los usuarios cargarán por defecto). Allí sustituimos:

PATH=/opt/teradata/jvm64/jre6/jre/bin:"${PATH}"; export PATH

por:

PATH=/usr/java/jre1.8.0_45/bin:"${PATH}"; export PATH

Y con estos cambios, probamos a ver si hemos arreglado el problema de la ‘query development perspective‘:

Teradata Studio 15.10Teradata Studio 15.10

Teradata Studio 15.10

¡OK!

Saludos.

Carlos.


SQL a Teradata desde Oracle (II): Oracle Database Gateways

21 abril \21\UTC 2015

Aprovechando que tenemos instalado en el servidor CentOS 6 el driver ODBC de Teradata y como allí hay instalado un Oracle 11g, vamos a retomar el viejo tema de la conexión de Oracle a Teradata. Anteriormente (Oracle 10g) esto se hacía mediante “Heterogeneous Services”. Más recientemente esto se hace mediante los llamados “Oracle Database Gateways”, y en nuestro caso particular con el “Oracle Database Gateway for ODBC”, heredero directo de aquellos “Heterogeneous Services” que configuramos en su día en un servidor Windows.

Los pasos son fundamentalmente los mismos, aunque con las particularidades propias del Sistema Operativo (de Windows a CentOS). También cambian algunos pequeños detalles, como los nombres de los módulos (ya no se llama “hsodbc”, sino que ahora su nombre es “dg4odbc”).

Así pues, vamos por partes.

Si queremos que la configuración ODBC sea global y no sólo para un usuario (quién sabe quién arrancará Oracle) deberemos especificarlo en el entorno (esto es análogo a la definición de DSN “de sistema” en Windows). En nuestro caso hemos creado el fichero /opt/odbc/.odbc.ini con los datos del DSN ODBC de Teradata (TD1410_SLES11, los mismos que utilizamos aquí). Definimos para ello una variable de entorno “ODBCINI” que apunte a él.

Con esto (y tras haberlo probado, con tdxodbc como también dijimos aquí) podemos comenzar.

Primero hay que crear un fichero de parámetros de inicialización para el “Gateway ODBC”. Se crea en $ORACLE_HOME/hs/admin y su nombre debe ser init<SID>.ora, siendo SID el identificador de sistema para el sitio remoto. En nuestro caso el fichero se llamará initTD1410.ora y, entre otros, contendrá los parámetros:

HS_FDS_CONNECT_INFO = TD1410_SLES11
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so

En realidad /usr/lib64/libodbc.so es un symbolic link al “driver manager” odbc de Teradata que instalamos en su día en /opt/teradata/client/ODBC_64/lib/libodbc.so

Una vez con nuestro initTD1410.ora, vamos a configurar el listener para el “Gateway”, para ello añadiremos una entrada en listener.ora:

...
  (SID_DESC= 
     (SID_NAME = TD1410)
     (ORACLE_HOME = <valor de $ORACLE_HOME>)
     (PROGRAM = dg4odbc)
     (ENVS = "LD_LIBRARY_PATH=/usr/lib64:<valor de $ORACLE_HOME>/lib")
  )

Tras hacer estas modificaciones debemos parar (lsnrctl stop) y volver a arrancar (lsnrctl start) el listener y ver que su estado (lsnrctl status) es correcto.

[carlos@CentOS6 ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production
...
Service "TD1410" has 1 instance(s).
  Instance "TD1410", status UNKNOWN, has 1 handler(s) for this service...
  ...

Ahora hay que hacer que Oracle pueda comunicarse con el “Gateway”. Y esto lo hacemos mediante el nunca bien conocido y siempre temido tnsnames.ora (¡Uuuuhhhh!, ¡tnsnames, qué miedo!). Pero no es para tanto. Sólo hay que incluir el “connect descriptor” y ya está:

teradata.remote =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = CentOS6.2_64)(PORT = 1521))
    (CONNECT_DATA = (SID = TD1410))
    (HS=OK)
  )

Es muy importante no olvidarse del (HS=OK) ni de hacerse un lío con tanto paréntesis abierto y cerrado.

Podemos comprobar que todo va bien con tnsping:

[carlos@CentOS6 ~]$ tnsping teradata.remote

TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 21-APR-2015 19:58:59

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

Used parameter files:


Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = CentOS6.2_64)(PORT = 1521)) (CONNECT_DATA = (SID = TD1410)) (HS=OK))
OK (0 msec)
[carlos@CentOS6 ~]$ 

Bueno, pues ya casi está. Sólo queda crear el dblink :

CARLOS@CentOS6.2_64> CREATE DATABASE LINK teradata.remote 
  2  CONNECT TO carlos IDENTIFIED BY xxxxxxxx 
  3  USING 'teradata.remote';

Database link created.

Y ver que efectivamente podemos seleccionar datos de Teradata desde Oracle:

CARLOS@CentOS6.2_64> select * 
  2  from carlos.prueba01@teradata.remote;

      ID_N D_DATE
---------- -------------------
         3 2014/09/18 00:00:00
         1 2014/09/18 00:00:00
         2 2014/09/18 00:00:00

Mission accomplished!

Saludos.

Carlos.


Seguir

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

Únete a otros 67 seguidores