Oracle Temporal Validity.

3 julio \03\UTC 2013

Una de las nuevas funcionalidades incluidas en el nuevo Oracle 12c es la llamada ‘Oracle Temporal Validity‘. Esta nueva característica añade una dimensión temporal a la información contenida en las tablas (“desde cuándo y hasta cuándo la información de la fila es válida“).

Este tratamiento temporal se implementa utilizando la nueva cláusula ‘add period for valid_time‘ (‘valid_time’ u otro nombre que queramos dar), que crea dos columnas ocultas de principio y fin de vigencia del dato y que se pueden utilizar de manera ‘transparente’ con un nuevo predicado en el ‘WHERE': ‘as of period for valid_time <cuándo>’, lo que mostrará los datos tal y como se verían en el momento especificado (suena muy moderno pero, en el fondo, no deja de ser un ‘BETWEEN’).

Una funcionalidad que parece querer remedar la original Teradata Temporal disponible en Teradata desde la versión 13.10.

Saludos.

Carlos.


Doing it all again…

1 julio \01\UTC 2013

Me he tomado mi tiempo y, como dijimos aquí, me he bajado la nueva versión de la Teradata Express for VMware (v.14.00.03.02) y la he configurado (de nuevo).

Un par de cosas que he hecho y que quizá sean de utilidad:

He cambiado el ‘display manager‘ a gdm, que me gusta más.

He creado lanzadores (‘launchers‘) en el escritorio de mi usuario (‘carlos’) para poder arrancar, parar y ver el estado de Viewpoint (ya que estos lanzadores sólo existen en el escritorio de ‘root‘). Esta VM permite arrancar y parar viewpoint manualmente desde el principio, sin necesidad de tener que hacer todo lo que hice aquí.

El resultado:

Teradata Express 14.0.3

Teradata Express 14.0.3

Por supuesto, toda la configuración de red (NAT), ‘proxy’, ‘gateway’ y demás, ha habido que hacerla también de nuevo.

Saludos.

Carlos.


Teradata Express for VMware Player actualizada.

26 junio \26\UTC 2013

Teradata ha actualizado las máquinas virtuales de los ‘Teradata Express for VMware Player‘ a la versión 14.00.03.02 (que es la versión más reciente del Teradata 14.0 ‘grande’). Esta nueva versión corrige ciertos fallos (como los vistos aquí).

La versión anterior de las MV’ era la 14.00.00.01 y como no es posible realizar ‘upgrades‘ sobre ellas, si quieres tener la última no hay otro remedio que bajarse las nuevas.

El problema: si has invertido una cierta cantidad de tiempo en configurarlas a tu gusto, deberás hacerlo de nuevo.

Disponibles aquí.

Saludos.

Carlos.


Oracle 12c disponible.

26 junio \26\UTC 2013

Oracle 12c (‘c’ de ‘cloud‘) está disponible aquí.

Entre las nuevas ‘features‘ anunciadas está el ‘optimizing data storage and compression according to usage patterns‘, que se parece mucho a la gestión que Teradata hace con su ‘Teradata Virtual Storage’ y la gestión de datos según su temperatura (movimiento de los datos ‘calientes’ a los SSD y la compresión a nivel de bloques de los datos más ‘fríos’) de lo que hablamos un poco aquí.

Saludos.

Carlos.


Teradata Intelligent Memory

18 junio \18\UTC 2013

Una de las novedades más interesantes que traerá Teradata 14.10 es “Teradata Intelligent Memory“. Vamos a ver un poco en qué consiste y para qué sirve.

Todos los RDBMS’s tienen un problema común: los IOs a disco. Esto no tiene ningún misterio: en última instancia todos los datos están almacenados en disco, y esto supone que hay que acceder a ellos mediante lecturas (y escrituras). El problema es que los IOs a disco son operaciones costosas y mucho más lentas que las análogas de acceso a memoria. (En el caso de Oracle el problema de los IOs es algo tan dramático que es ésa y no otra la razón del desarrollo de su Exadata)

Para intentar paliar en lo posible estas costosas operaciones, los RDBMS’s funcionan con unas áreas de memoria (en Teradata es “FSG caché“, en Oracle es “buffer caché“) en las que los datos leídos del disco se mantienen en memoria en previsión de que puedan necesitarse de nuevo (mediante otra “query“, por ejemplo). El objetivo es siempre ahorrar IOs. (Vamos a dejar a un lado las “in-memory databases“, puesto que son un caso muy particular y no muy aplicable a entornos de “data warehousing“).

Lo malo es que estos “buffers” son de tamaño limitado y bastante más pequeños que la capacidad total de almacenamiento de las bases de datos. Surge entonces el problema de qué datos mantener ahí y cuáles “devolver” a los discos. Los algoritmos utilizados en la mayoría de los RDBMS son de tipo MRU/LRU (most recently used/less recently used) lo que significa que los datos contenidos en los “buffers” son los últimos a los que se ha accedido en el tiempo. Si dos “queries” idénticas que acceden a los mismos datos suceden con un cierto intervalo puede ocurrir que los datos recuperados por la primera de ellas ya no estén disponibles en los “buffers” para la segunda, sino que hayan sido sustituídos (“aged out“) por otros más recientes, como consecuencia de otras “queries” ejecutadas en el sistema por otros usuarios, etc…

Cierto es que Oracle es capaz de mantener un área de memoria en la que los datos no son eliminados. Es el llamado KEEP POOL, pero está pensado para tablas pequeñas a las que se accede frecuentemente, como las tablas “lookup“. Esta área suele ser bastante limitada en tamaño.

Teradata 14.10 introduce el “Intelligent Memory“, que no es sino otra área de memoria (“buffer“). La particularidad que tiene es que el mecanismo para mantener allí los datos no es de tipo MRU/LRU, sino MFU (most frequently used). Teradata mantiene información estadística de los datos a los que se accede más frecuentemente y es capaz de mantener con ella los datos más calientes en esta área. Cuando Teradata recibe una petición (request) mira primero en el FSG caché y en esta nueva “Intelligent Memory“, de forma que es probable que los datos a los que se accede más frecuentemente estarán ahí y se evitarán con ello gran cantidad de IOs a disco.

Otra ventaja añadida es que la información acerca de la temperatura de los datos se mantiene entre arranques. Todos hemos visto la cantidad de IOs en los primeros momentos tras un arranque -ya sea Teradata, Oracle o cualquier otro RDBMS- porque los “buffers” están vacíos y deben llenarse poco a poco con la propia actividad del sistema. Por el contrario, el área de “Intelligent Memory” se llena ya desde el inicio partiendo de la información estadística almacenada, y los datos más utilizados estarán disponibles allí desde prácticamente el primer momento.

Esto se añade a otras funcionalidades que Teradata utiliza para tratar la información según su temperatura, como la posibilidad de mover los datos más calientes a unidades SSD (solid state discs) con mejor rendimiento en IO, o comprimir a nivel de bloque (block level compression) los datos más fríos (a los que se accede con poca frecuencia) para ahorrar espacio de almacenamiento.

Lo mejor de todo es que esta nueva funcionalidad es “transparente” (el sistema se encarga de su gestión) y viene instalada de fábrica.

Más información aquí.

Saludos.

Carlos.


Error con arcmain y ‘named pipes’ en Teradata 14

23 abril \23\UTC 2013

Una de las formas más utilizadas en Teradata para traspasar tablas entre sistemas (dejando a un lado ‘moderneces’ como el ‘Teradata Data Mover‘) es usar ‘arcmain‘ con ‘named pipes‘. El concepto en sí es simple: lanzas un ‘arcmain‘ en ‘background‘ que haga un ‘archive‘ en el sistema origen sobre las tablas que quieres traspasar, pero que en vez de exportar a fichero, exporte a un ‘named pipe‘ (fifo). Luego lanzas otro ‘arcmain‘ que haga un ‘restore’ o un ‘copy‘ de las tablas ‘archivadas’ en el sistema destino leyendo de ese mismo ‘named pipe‘. Consigues mucha rapidez, ya que te ahorras el espacio y las lecturas y escrituras (IOs) en el ‘file system‘, ya que todo va en memoria.

Así teníamos montada una herramienta que funcionaba a las mil maravillas en nuestros Teradata 12. Pero vino el ‘upgrade’ a Teradata 14…

Con la actualización del ‘software‘ de base de datos vino asociada la actualización del Sistema Operativo y de las Teradata Utilities (TTUs). No obstante, nuestra herramienta no debería verse afectada, ya que era un humilde ‘script’ de ‘bash’ que lo único que hacía era llamar a las citadas TTUs.

Pero, claro, la cosa no iba a ser tan fácil, ya que al intentar mover tablas entre sistemas la herramienta cascaba y devolvía constantemente un extraño mensaje:

*** Failure ARC0805:Access Module returned error code 34: pmUnxDskOpen: ftello (Illegal seek).

Tan raro era, que en Google aparecían un par de referencias que poco o nada ayudaban a resolver el problema.

El caso es que si sustituíamos el ‘named pipe‘ por un fichero normal y corriente el proceso terminaba OK (eso sí, tardando años y ocupando montones de espacio en el ‘file system‘). Así que el asunto tenía que ver con el ‘named pipe‘ sí o sí.

Afortunadamente, un ‘guru’ me indicó el posible camino a seguir: Resulta que el Teradata Data Connector (‘piom’ para los amigos) de la versión 14 tiene un ‘bug‘ que le hace fallar con los ‘named pipes‘ (“SA-18150: File position of FIFO pipe fails“). Este ‘bug‘ aparece corregido en la versión 14.0.0.6.

Una vez en el camino corecto: bajarse la última versión disponible (14.00.00.12), que viene en forma de rpm, e instalarla.

Tras hacer esto, el ‘arcmain‘ ha vuelto a funcionar correctamente con ‘named pipes‘ y la herramienta vuelve a traspasar tablas entre sistemas como antes.

Saludos.

Carlos.

 


Teradata 14, las funciones Oracle y los errores de juventud

9 abril \09\UTC 2013

Ya hemos hablado aquí de las nuevas funciones nativas de Teradata 14 (“Embedded Services System Functions”) y de cómo nos solucionan algunos problemas de forma sencilla e intuitiva. Muchas de ellas son simple y llanamente ‘clones’ de funciones Oracle, pero a veces ocurren cosas curiosas. Esto es lo que me pasó el otro día al intentar utilizar la archifamosa función TO_CHAR() en su versión Teradata.

Primero, los antecedentes: La función Oracle TO_CHAR() sirve para convertir números a cadenas y permite formatear la salida. Entre otras cosas, se puede indicar los caracteres a utilizar como separador de decimales y grupos para evitar los definidos por el sistema. Esto es muy común si el sistema tiene una configuración anglosajona -con el punto como separador decimal y la coma como separador de grupos- y queremos una representación ‘hispana’, que es justamente al revés. En situaciones como ésta podemos utilizar TO_CHAR() con el parámetro NLS_NUMERIC_CHARACTERS, donde le indicamos nuestras preferencias:

carlos@XE> SELECT * FROM V$VERSION;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE	11.2.0.2.0	Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

carlos@XE> SELECT TO_CHAR (1234.56, '999G990D00', 
   2 'NLS_NUMERIC_CHARACTERS='',.''') 
   3 FROM DUAL;

TO_CHAR(123
-----------
   1.234,56

carlos@XE>

OK.

Vamos ahora a Teradata. La documentación explica un uso exactamente igual que la original Oracle. Así que:

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT * FROM DBC.DBCINFO;

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

InfoKey                        InfoData
------------------------------ ---------------------------------------------------------
LANGUAGE SUPPORT MODE          Standard
RELEASE                        14.00.02.05
VERSION                        14.00.02.05

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT TD_SYSFNLIB.TO_CHAR(1234.56,'9G999D99', 
       'NLS_NUMERIC_CHARACTERS='',.''');

 *** Failure 9134 Error in function TO_CHAR: parameter 3 is invalid.
                Statement# 1, Info =0
 *** Total elapsed time was 1 second.

¡Ahivá! ¿Un error? ¿Por qué? Pues resulta que no va a ser tan ‘exactamente igual’…

Después de probar y probar, me llevó un rato descubrir que Teradata espera un espacio en blanco adicional en la cadena del “NLS_PARAMS” a ambos lados del signo “igual” (=).

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT TD_SYSFNLIB.TO_CHAR(1234.56,'9G999D99', 
       'NLS_NUMERIC_CHARACTERS = '',.''');

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

TO_CHAR(1234.56,'9G999D99','NLS_NUMERIC_CHARACTERS = '',.'''
------------------------------------------------------------
 1.234,56

Parece que esto es un ejempo más de lo que normalmente se llaman ‘errores de juventud’…

Saludos.

Carlos.


Teradata Access Layer Delivery Workshop

24 marzo \24\UTC 2013

Esta semana la he pasado en Praga, República Checa, asistiendo al “Access Layer Delivery Workshop” en las dependencias que Teradata tiene allí.

Teradata Praga

Teradata Praga

El curso ha sido muy interesante y los dos profesores -dos “aussies“-, excepcionales.

Por supuesto, tambén hubo tiempo para hacer algo de turismo (en especial, “turismo gastronómico”):

Especialidades locales en Praga

Especialidades locales en Praga

Saludos.

Carlos.

 


Teradata Virtual Machine Edition

7 marzo \07\UTC 2013

Teradata ha anunciado “Teradata Virtual Machine Edition“, algo que nos había adelantado Mike Coutts en Dublín el año pasado. Se trata de máquinas virtuales (en tres versiones) similares a “Teradata Express” pero orientadas a entornos “profesionales”. La idea es utilizarlas como entornos de desarrollo o de “test” de nuevas versiones o funcionalidades sin la necesidad de disponer del “hardware” para ello.

Se presentan en tres versiones, de 80GB, 320GB y 2,4TB. Funcionan con VMware ESX 4.0, VMware ESXi 5.0 o superior.

Las especificaciones completas son:

AMPs:             4       8      12
Space/AMP:     20GB    40GB   200GB
Total Space:   80GB   320GB   2,4TB
Memory:         8GB    10GB    16GB
CPUs:             1       2       4

El espacio requerido para las instalaciones de las MV’s es de 155GB, 395GB y 2,475TB respectivamente.

Como ventaja añadida está la creación de nuevas MV’s a partir de los ‘templates‘, lo que permite tener instalaciones ‘desde cero’ en cualquier momento o en el caso de un necesario ‘B2B’ (“back to basics“), y su instalación en minutos.

Saludos.

Carlos.


Teradata: ¿Tablas NoPI o SíPI?

1 marzo \01\UTC 2013

A partir de la versión 13.0 Teradata introdujo un nuevo tipo de tablas: las tablas sin Primary Index (tablas NoPI para los amigos). Esto a alguien que llevara cierto tiempo trabajando con Teradata podría rechinarle un poco. En efecto, el Primary Index está en la base de la distribución de las tablas entre los AMPs y por tanto es la base del paralelismo. El algoritmo de ‘hash‘ que es el encargado de distribuir las filas de una tabla entre los AMPs se basa en el valor del PI. Entonces, ¿qué son y cómo funcionan estas tablas NoPI? Y lo que es más importante: ¿para qué pueden valer?

La idea tras estas tablas NoPI está en sustituir el algoritmo de distribución ‘hasing‘ basado en el PI por una distribución aleatoria. Las filas son enviadas a los AMPs a partir de métodos ‘random’, con lo que, de momento, la distribución debería ser mejor (menos ‘skew‘). También se elimina la verificación de filas duplicadas que ocurre con las tablas ‘normales’ y su ‘sort’ correspondiente, así como la redistribución de la fase de ‘application‘. Esto supone mejora en CPU e I/O.

Vamos a ver estos supuestos beneficios sobre el terreno:

Utilizaremos un fichero de 15GB con 63 millones de filas y 44 campos. Lo cargamos con fastload en una tabla ‘normal’ (con un Primary Index) y en una tabla idéntica, pero sin él (NoPI).
En el sistema utilizado (Teradata 14, 40 amps) los números son:

+------+----------+
|      | fastload |
+------+----------+
|  PI  |  4'33''  |
+------+----------+
| NOPI |  3'31''  |
+------+----------+

¡Qué maravilla! ¡Casi un 25% de mejora en tiempo de carga! ¡Pues a usar NoPI como tablas de ‘staging‘ con fastload a mogollón!

Ya pero, un momento. Las tablas de ‘staging‘ son tablas de almacenamiento temporal que normalmente se utilizan como fuente para inserciones en tablas definitivas. Y es aquí donde aparece la “PREGUNTA” con mayúsculas, la madre del cordero. ¿Qué pasa con las inserciones desde las tablas de ‘staging‘?

Es frecuente que las tablas definitivas sobre las que se volcará en contenido tengan el mismo PI que las tablas de ‘staging’. Esto hace que todas las operaciones sean locales en los AMPs y eliminan la necesidad de redistribución (filas arriba y abajo por la bynet moviéndose de un AMP a otro).

Otra prueba nos dará una idea del asunto. Insertaremos las filas desde la tabla de ‘staging‘ a una tabla con la misma estructura y mismo PI que la tabla PI de ‘staging‘. Para los 63 millones de filas el resultado es que:

+------+---------+
|      | INS/SEL |
+------+---------+
|  PI  |  0'56'' |
+------+---------+
| NOPI |  4'32'' |
+------+---------+

¡Epa! Entonces la cosa no está tan clara, porque el total del proceso es:

+------+----------+---------+---------+
|      | fastload | INS/SEL |  TOTAL  |
+------+----------+---------+---------+
|  PI  |  4'33''  |  0'56'' |  5'29'' |
+------+----------+---------+---------+
| NOPI |  3'31''  |  4'32'' |  8'03'' |
+------+----------+---------+---------+

Así pues, si utilizamos tablas NoPI lo que ganamos en el ‘fastload‘ lo perdemos luego con creces en el INSERT…SELECT y al final vemos que la carga con tablas de ‘staging’ que tienen el mismo PI que las tablas destino es alrededor de un 30% más rápida que el que usa tablas NoPI.

Además, hemos dejado aparte otras limitaciones de las tablas NoPI, como la imposibilidad de ejecutar UPDATEs (en forma de “UPSERT”) y MERGEs sobre ellas, ya que ambos comandos dependen de los Primary Indexes.

La moraleja: no es oro todo lo que reluce. Hay que ver exactamente las condiciones de datos, estructuras y procesos antes de tomar decisiones que pueden suponer diferencias sustanciales.

¿Tablas NoPI o SíPI? Pues depende…

Saludos.

Carlos.


Seguir

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

Únete a otros 44 seguidores