Estándar de Desarrollo Plataforma Teradata V.4.2-Publicado

LATAM AIRLINES GROUP
Estndar de Desarrollo Plataforma

Teradata
(Aplica desde TDT Versin 14.10 en adelante)
Arquitectura Corporativa LATAM

22/12/2014
ltima Actualizacin: 18/05/2016
Documento - Versin 4.2

CONTROL DE LAS MODIFICACIONES
Versin Descripcin Autor Fecha Revisado por

1.0 Construccin del documento Juan Pablo Morales 2009-
02-19
Se incorporan
2 nuevos tems y Juan Pablo Morales 2009-
0
definiciones. 03-09
Correccin,
2 ejemplo con alias Guillermo Ordenes 2013-
nemotcnico
. y ajustes 05-16
1 de formato.
menores
Incorporacin
2 de mejores Gloria Appelgren 2014-
prcticas . 01-14
2
Usuarios, Vistas
Incorporacin y correccin de Gloria Appelgren 2014-
Ambientes, Particiones, Tipos 02-25
Hector Saavedra
de Tablas y su operacin,
2014-
aplicacin de estadsticas y
03-11
otros
2.0 Incorporacin de links y Gloria Appelgren 2014- Guillermo
modificaciones de sintaxis. 05-23 Ordenes
Configuraciones y otros. Hector Saavedra
3.0 Incorporacin de Gloria Appelgren 2014- TDT
observaciones y mejores 06-15
prcticas
Cambio de orden de Temas
4.0 Arquitectura de Referencia BI Gloria Appelgren 2014- TDT
para EDW corporativo. 09-30 Guillermo
Ordenes
Modificacin de Modelos de
Vincent Beghin
Base de Datos Estructura de
Elitsoft
Data Warehouse Corporativo
EDW.
Incorporacin de nuevas
funcionalidades TDT v14.10 de
DB Columnar.
Mejores prcticas de Teradata
Parallel Tranport. Extensin de
los Operadores TPT
Recomendacin para la
Estndar de Desarrollo TERADATA Pgina 1 de 43

Plataforma Teradata Fecha de Publicacin: 2-12-2014
Arquitectura Corporativa LATAM Fecha de Actualizacin: 18-05-2016
Recoleccin de estadsticas
4.1 DB Extra para casos de uso Gloria Appelgren 2016- Lorena Vivanco
en los que se requiera 03-15 Vincent Beghin
extracciones de datos desde Guillermo
TDT a otros sistemas. Ordenes
4.2 Modificaciones a PI de tipo Gloria Appelgren 2016- Guillermo
Char o Varchar, Modificaciones 03-15 Ordenes
a reglas de Tablas voltiles y Vincent Beghin
temporales, Clculo de
Estadsticas y
responsabilidades, uso de
vistas DBC, uso de NOPI y
otros.
Links importantes de documentacin complementaria:

1. Estndar de Manejo de Histricos: EMH
2. Estndar de Construccin Objetos DB: ECODB
3. Estndar de Construccin de Sentencias SQL: ESQL
4. Validacin MDC en Detalle: VMDC
5. Estndar de Construccin BTEQ. EBTEQ
6. Estndar DataStage. EDST
7. Polticas de Procesamiento DataStage: PPDST
8. Estndar Pentaho. EPTHO
9. Polticas de la Plataforma Teradata. PPTT
10. Estndares de Desarrollo Plataforma Teradata. EDPTT
Nota: para acceder a los links debe estar dentro de la Red LATAM

ndice de Contenidos
1. INTRODUCCIN ................................................................................................................. 5
2. ARQUITECTURA DE REFERENCIA ................................................................................. 5
3. DISTRIBUCIN DE ESTRUCTURA DE BASE DE DATOS .............................................. 6
3.1. DISTRIBUCIN DATABASE GENERAL ........................................................................... 6
3.2. DATABASE PARA EXTRACCIONES .............................................................................. 10
4. DEFINICIONES SOBRE EL USO CORRECTO DE TERADATA .................................... 10
5. TABLAS ............................................................................................................................ 11
5.1. CREACIN DE TABLAS .................................................................................................. 11
5.2. ORDEN DE SCRIPT DE CREACIN DE TABLAS INICIALES ...................................... 12
5.3. ORDEN DE SCRIPT DE TRASVASIJE TABLAS ............................................................ 13
5.4. PRIMARY INDEX DE TABLAS ........................................................................................ 13
5.4.1. VALIDACIN DE DISTRIBUCIN DE DATOS ......................................................... 14
5.4.2. VALIDACIN DE SKEW FACTOR ............................................................................ 14
5.5. TABLAS DE TIPO NOPI ................................................................................................... 16
5.6. SET VERSUS MULTISET ................................................................................................. 17
5.7. COMPRESIN DE TABLAS ............................................................................................ 17
5.8. PARTICIONAMIENTO DE TABLAS ................................................................................ 19
5.9. FALLBACK Y JOURNALIST ........................................................................................... 20
5.10. JOINS DE TABLAS .......................................................................................................... 20
5.11. TABLAS TEMPORALES Y VOLTILES ......................................................................... 21
5.12. ALTER TABLE .................................................................................................................. 21
6. VISTAS .............................................................................................................................. 22
7. MACROS ........................................................................................................................... 22
8. FUNCIONES ..................................................................................................................... 23
9. EXPLAIN Y VISUAL EXPLAIN ......................................................................................... 23
10. COLLECT STATISTICS.................................................................................................... 25
11. PROCESOS DE CARGA FRAMEWORK DE ETL/ELT ................................................ 28
11.1. BTEQ ................................................................................................................................. 28
11.2. TERADATA PARALLEL TRANSPORTER (TPT) ............................................................ 28
12. CALIDAD DE DATOS ....................................................................................................... 29
13. MEJORES PRCTICAS TDT ........................................................................................... 30

14. USO Y ACCESO DBC ...................................................................................................... 33
15. CONFIGURACIN CORRECTA DEL ODBC .................................................................. 33
16. ESTANDAR DE GENERACIN DE USUARIOS. ............................................................ 35
17. NOMENCLATURA DE TABLAS Y CAMPOS DIMENSIONALES................................... 35
18. ANEXOS ........................................................................................................................... 36
18.1. FORMATO GENERAL. SINTAXIS DE CREACIN DE TABLAS ................................... 36
18.2. INDEX WIZARD ................................................................................................................ 37
18.3. SPOOL FANTASMA ......................................................................................................... 37
18.4. USO DE DATA BLOCK SIZE ........................................................................................... 37
18.5. TERADATA COLUMNAR ................................................................................................. 38
18.6. CONJUNTO DE COMANDOS BTEQ ............................................................................... 39
18.7. TERADATA PARALLEL TRANSPORTER (TPT) ............................................................ 39
18.7.1. OPERADORES PRODUCTORES ............................................................................. 40
18.7.2. OPERADORES CONSUMIDORES............................................................................ 41
18.7.3. OPERADORES STANDALONE ................................................................................ 41
18.7.4. OPERADORES PERSONALIZADOS ........................................................................ 42
18.8. COLLECT STATS ............................................................................................................. 42
18.9. LINK DE UTILIDAD .......................................................................................................... 43

1. INTRODUCCIN
El siguiente documento tiene por objetivo indicar los estndares y mejores prcticas para los
desarrollos en la plataforma Teradata versin 14 en adelante. Estos lineamientos son una
referencia respecto a la construccin de objetos de base de datos, procedimientos y mejores
prcticas a la hora de enfrentar un buen desarrollo en TDT, el cual es aplicable a Proyectos
tradicionales y Business Intelligence relacionados con Datawarehouse para LATAM Airlines Group.
En consecuencia, las reas de validacin y calidad podrn usar las recomendaciones que se
proponen en el documento, con el objetivo de adaptarlas al proceso de certificacin y poder
mitigar los problemas de perfomance futuros y otros inconvenientes post produccin.
2. ARQUITECTURA DE REFERENCIA
En este apartado se muestra la arquitectura de referencia para un Enterprise Data Warehouse

(EDW), que todo proyecto de Gestin en LATAM Airlines Group, deber considerar al momento de
implementar en Teradata. Este lineamiento sigue las mejores prcticas de Teradata.
La siguiente figura muestra la arquitectura de referencia que define los lineamientos para el EDW
implementado en Teradata.
Figura 1. Arquitectura de Referencia BI Enterprise Data Warehouse en Teradata
Las tres capas en Teradata corresponden a:

Layer 1: Capa de Adquisicin correspondiente a las bases Temporales, de Staging y Raw Histricos.
Es la primera etapa de carga de datos al motor DB.
Layer 2: Capa de Integracin de Datos: Corresponde a la ODS donde se encuentran las bases WRK
y ODS, cuyo modelo normalizado o desnormalizado que almacena el data warehouse del
negocio. Esta base debe responder en forma dinmica a las necesidades de data para
gestin de la compaa y permita construir diferentes datamarts.
Layer 3: Corresponde a la capa de acceso y a la base FDM, donde se encuentran la base

dimensional final y las vistas a tablas o de negocio que se requieren para explotar la base
dimensional. Por lo tanto se encuentran los datamarts, vistas analticas o de minera que
sean requeridas por el negocio.
El objetivo del data warehouse corporativo es fomentar la reutilizacin y minimizar costos y el uso
de recursos aprovechando los procesos de carga y las bases de datos que genera y usa la
compaa para la gestin.
3. DISTRIBUCIN DE ESTRUCTURA DE BASE DE DATOS
3.1. DISTRIBUCIN DATABASE GENERAL
En este apartado se define las bases de datos con las que cuenta un proyecto. Cada una de ellas
tiene un objetivo y ciertos permisos que facilitan la carga y la explotacin de la base de datos
Nombre DB corresponde al Nombre Corto del Proyecto. Para las bases existentes, Ej: BIFUEL,
GPNR, GMIDT, etc. Para un Enterprise Data Warehouse, la base tendr las siglas EDW.
Las Bases de Datos principales para EDW son: _FDM, _ODS, _LOG, _STG.
Figura 2. Modelo lgico y fsico para la divisin en Bases de Datos en Teradata
Cada una de las bases de datos tiene un propsito especfico y permisos los cuales se detallan en
la siguiente tabla.

Nombre de DB y Descripcin Permisos de usuario Permiso usuario explotacin
mbito para carga de datos (usr_m_...) o (userid)
(usr_o_....) Desa/Beta/Prod
Desa/Beta/Prod
1.- En esta base Final Dimensional Insert N/A
<NombreDB>_FDM Model - se encuentra el Update
modelo dimensional final de los Select
Ej proyectos en el que se Delete
EDW_FDM encuentran las tablas de
modelos estrella o copo de
nieve.
Estos deben ser explotados a
travs de vistas que se detallan
en los puntos 2 y 3 de esta
tabla.
2.- Es la base en la que se Select N/A
<nombreDB>_VT encuentra las vistas a tablas VT
(view table) del proyecto
Ej: correspondiente a la capa de Select (slo usuarios
EDW_VT ACCESO. Los usuarios o clientes Microstrategy, Administradores
pueden acceder para explotar de Sistemas, CdN, Mantto y Arq)
las Tablas de la base de datos
de _FDM.
Vistas a Tablas: sus nombres
deben seguir la nomenclatura
de las tablas. Para identificarlas,
todas las consultas debern
llevar el prefijo de la base.
3.- Es la base en la que se Select N/A
<nombreDB>_VW: encuentra las vistas de negocio
del proyecto correspondiente a
Ej: la capa Semntica. Se puede Select (slo usuarios
EDW_VW acceder para explotar la base Microstrategy, Administradores
de datos de _FDM. Esto se debe de Sistemas, CdN, Mantto y Arq)
realizar a partir de las _VT y no
directamente a las tablas del
_FDM.
Vistas de Negocio: sus nombres
deben seguir la nomenclatura
de las tablas. Para identificarlas,
todas las consultas debern
llevar el prefijo de la base.
4.- Es la base en la que se Create N/A
<nombreDB>_WRK incorporan tablas de trabajo, Drop
previas a la carga del modelo Insert
Ej: final o intermedia entre STG y Update
EDW_WRK ODS. Select
Delete
5.- Es la base dinmica en la que se Insert N/A
<nombreDB>_ODS encuentra una ODS Update
(Operational Data Store), Select
Ej: correspondiente a un modelo Delete
EDW_ODS normalizado. Contiene las

tablas fundamentales del
negocio que permitan construir
los diferentes modelos
dimensionales para _FDM.
Tambin es posible mantener
las tablas agregadas, fact y
Lookup de manera que no sea
necesario replicar las tablas en
el FDM, sino que sean
accesadas a travs de vistas.
6.- Es la base que contiene las Select N/A
<nombreDB>_VTODS vistas a tablas del modelo en
_ODS. Corresponde a la capa de Select (slo usuarios
Ej: acceso a _ODS. Microstrategy, Administradores
EDW_VTODS de Sistemas, CdN, Mantto y Arq)
7.- Es la base que contiene las Select N/A
<nombreDB>_VWODS vistas de negocio que permiten
esmascarar semnticamente la Select (slo usuarios
Ej: _ODS. Las vistas deben ser Microstrategy, Administradores
EDW_VWODS creadas apuntando a vistas de de Sistemas, CdN, Mantto y Arq)
_VTODS. Nunca directo a las
tablas.
8.- Es la base que contiene el log Insert N/A
<nombreDB>_LOG de negocio. Su objetivo es dar Update
visibilidad a CdN o Negocio para Select
Ej: evaluar los indicadores. Delete
EDW_LOG
9.- Es la base correspondiente a la Select N/A
<nombreDB>_VTLOG capa de acceso a las tablas del
log de negocio del punto 8. Select (slo usuarios
Ej: Microstrategy, Administradores
EDW_VTLOG de Sistemas, CdN, Mantto y Arq)
9.1- Es la base correspondiente a la Select N/A
<nombreDB>_VWLOG capa semntica a las Vistas de
LOG. Select a usuarios Microstrategy,
Ej: _VTLOG acceso a tablas con Administradores de Sistemas,
EDW_VWLOG loocking for Access. CdN, Mantto y Arq.
_VW se construyen utilizando
las _VT.
10.- Es la base que almacena las Create N/A
<nombreDB>_STG tablas RAW Data y corresponde Drop
a la etapa de Staging de la carga Insert
Ej: de datos. Esta debe actualizarse Update
EDW_STG de acuerdo al periodo Select
requerido por el negocio Delete
(diario, mensual o anual)
11.- Corresponde a la base que Select N/A
<nombreDB>_VTSTG contendr vistas a tablas de la
base _STG. Est enfocada Select (slo usuarios
Ej: exclusivamente para las cargas Microstrategy, Administradores
EDW_VTSTG de la base ODS y permite evitar de Sistemas, CdN, Mantto y Arq)
los bloqueos de tablas.
<nombreDB>_VWSTG contendr vistas de negocio y

que apunta a la base _VTSTG. Select (slo usuarios
Ej: Est enfocada exclusivamente Microstrategy, Administradores
EDW_ VWSTG para las cargas de la base ODS y de Sistemas, CdN, Mantto y Arq)
evitar los bloqueos de tablas.
13.- Es la base en la que se Create N/A
<nombreDB>_TMP incorporan tablas temporales y Drop
que se pueden borrar Insert Select (slo usuarios
Ej: estructuras y datos. Update Microstrategy, Administradores
EDW_TMP Advertencia: Administracin Select de Sistemas, CdN, Mantto y Arq)
podr borrar sin necesidad de Delete
solicitar permisos.
14.- Corresponde a la base Histrica Select N/A

<nombreDB>_HIS de los Staging. Update
Slo debe almacenar lo que Delete
Ej: estipule el DWH. Se debe
EDW_HIS administrar de manera que slo
est disponible lo que se usar
en el lapso de 1 ao calendario.
<nombreDB>_VTHIS contendr vistas a tablas de la
base _HIS. Est enfocada Select (slo usuarios
Ej: exclusivamente para las cargas Microstrategy, Administradores
EDW_HIS de Histricos del Staging y de Sistemas, CdN, Mantto y Arq)
busca optimizar los tiempos de
carga en caso de requerir datos
histricos. Se deba aplicar la
poltica de manejo de histricos
vigente.
16.- Es la base en la que se incluyen Insert N/A
MCP_FDM (modelo las tablas de Log para el control Update
dimensional) de todos los proyecto. Select Select (slo usuarios
MCP_ODS (modelo Esta base es centralizada y Microstrategy, Administradores
operacional 3FN) entrega info de control de malla de Sistemas, CdN, Mantto y Arq)
MCP_STG (slo si es para todos los procesos de
necesario para cargas carga de Teradata en todas las
de archivos externos) capas (adquisicin, integracin
y explotacin).
17.- MCP_VT Es la base en la que se incluyen Select N/A
las vistas a la base MCP_FDM o
MCP_ODS para control de Select (slo usuarios
carga de todos los proyecto Microstrategy y
pero que permita ser utilizado Administradores de Sistemas)
desde MSTR.
18.- MCP_VW Es la base en la que se incluyen Select N/A
las vistas de negocio a la base
MCP_VT para control de carga Select (slo usuarios
de todos los proyecto pero que Microstrategy y
permita ser utilizado desde Administradores de Sistemas)
MSTR.

19.- MCP_SP Corresponde a la base con los exec N/A
stored procedure exclusivos
para el modelo de control de
procesos centralizado.
Para los scripts de creacin de modelos que se realizar en la primera oportunidad de paso a
beta y produccin sern aceptadas todas las instrucciones (create, drop, insert, etc) para los
procesos de carga. Sin embargo, en los procesos de carga sistemtica no deben existir scripts
con instrucciones de Create, Alter y/o Drop en los mbitos _FDM u _ODS. Esto ser controlado
en paso a beta.
3.2. DATABASE PARA EXTRACCIONES

Slo en el caso de uso de extracciones de datos desde Teradata, que involucran procesos
temporales y que prepararn archivos de salida para otros sistemas externos a Teradata.
Se dispone de una base de datos centralizada y compartida que tiene como raz una DB
denominada EXTRA para este tipo de requerimientos.
Cada proyecto deber gestionar una BD nueva dependiente de EXTRA y una BD de vistas con la
estructura como se muestra en el ejemplo. Con lo anterior se garantiza la no interferencia con
otros proyectos y recursos independientes.
La nomenclatura definida es: [Direccin]_[Negocio o CdN]_ [Proyecto]
Estructura de Ejemplo:
>> EXTRA
MKT_CU_HUB
o MKT_CU_HUB_WRK
MKT_CU_HUB_VTWRK
La BD tendr una cuenta de proceso. En este caso ser de extraccin dem a las de procesos de
carga (usuario usr_o) con permisos de lectura a los modelos a consumir, permisos de
insert/update/drop sobre la base de trabajo y un spool adecuado para resolver las extracciones.
No podrn tener una cuenta de tipo usr_m.
El tamao de la BD propia debe se establecer en 200 GB como lmite mximo para este tipo de
iniciativas. Sin embargo, se deber estudiar cada caso y definir el tamao requerido con las
reas indicadas. El responsable o proyecto deber asegurar que las consultas que requiera
realizar a bases existentes en Teradata estn optimizadas.
4. DEFINICIONES SOBRE EL USO CORRECTO DE TERADATA

La plataforma TERADATA es en esencia un motor de bases de datos relacional orientado al
procesamiento de grandes volmenes de datos para la gestin y el anlisis. Es por ello que en
LATAM esta plataforma est orientada al DataWarehouse Corporativo. Por lo tanto el uso

operacional de la plataforma TERADATA no ser aceptado, excepto para el mbito de
integracin de datos.
5. TABLAS
5.1. CREACIN DE TABLAS

La creacin de tabla es una de las actividades ms relevantes para un buen desarrollo en la
plataforma TDT. Una mala definicin de tabla puede ocasionar serios problemas al desempeo
al motor.
La mejor definicin de una tabla depende de una serie de caractersticas y objetivos. Algunas
preguntas tpicas que ayudan a modelar y definir en forma ms precisa una tabla.
1. Cul es el Primary Index de cada tabla? Puede ser NOPI?
2. Se debe usar la(s) columna(s) Primary Key como Primary Index?
3. Cundo debiera ser Non-Unique Primary Index? Qu consecuencias trae esto?
4. Necesitar Secondary Indexes? Si es as, Qu Tipo? Qu columna(s)?
5. Debemos / Podemos permitir filas duplicadas?
6. Qu tipo de datos debiera usar? Qu atributos?
7. Podemos / debemos comprimir? Valores literales? Tabla completa?
8. Qu restricciones se deben definir? Qu costos y consecuencias tiene eso?
9. Se debe generar valores partir de otros campos?
10. Puede/debe particionarse una tabla?
11. Debemos realizar drop a las tablas al final de la sesin en reas temporales?
La definicin LATAM para la creacin de tablas busca aplicar mejores prcticas para
optimizar las bases de datos. Para ms detalles de la estructura general de sintaxis para
creacin de tablas en Teradata se puede ver en el anexo 18.1 de este documento.
A continuacin se presenta un ejemplo de una estructura tpica de la creacin de una Tabla
en Teradata para LATAM, que recoge mejores prcticas para mejorar y optimizar el uso de
recursos.
CREATE <<MULTISET/SET>> TABLE <<DATABASENAME>>.<<TABLE_NAME>>,

NO FALLBACK,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT
(
<<Field_1>> <<DataType1>> <<NOT NULL>>,
<<Field_2>> <<DataType2>>

<<Field_N>> <<DataTypeN>> <<COMPRESS (for type)>> )
<<UNIQUE>> PRIMARY INDEX <<Name_Table>>_<<TypePI>>(<<Field(s)>>)
<<PARTITION BY RANGE_N>>(<<FieldFCH>> BETWEEN DATE <<'2013-09-01' AND DATE '2015-12-31'>>
EACH INTERVAL <<IntervalType>> )
<<PARTITION BY (<<Partitioning Expression>>)>>;
COMMENT ON TABLE TABLE_NAME AS Ejemplo:'Tabla para registrar las transacciones de prueba.';
COMMENT ON COLUMN TABLE_NAME.FIELD_1 IS 'Identificador de los eventos;
COMMENT ON COLUMN TABLE_NAME.FIELD_2 IS 'Indicador de vigencia de los eventos. S=Si; N=No;

Dnde:
<< SET/ MULTISET>>: De preferencia use multiset si es posible, para ms detalles
ver apartado 3.3 sobre uso de SET/MULTISET
<<Field_N>> es el nombre de los campos de la tabla, cuya nomenclatura est
definida en el documento Estndar de Construccin Objetos DB (ECODB).
<<DataTypeN>> corresponde al tipo de dato de un campo. Para ms detalles puede
hacer uso del siguiente link TDT-DataType
<<UNIQUE>> PRIMARY INDEX. Se refiere al ndice Primario que debe ser definido
por cada tabla, con el objetivo de obtener una buena distribucin de datos en la
plataforma. Para ms detalle ver apartado 3.2.
<<DATABASENAME>>. Corresponde al nombre de la base de datos en la que debe
crear la o las tablas.
<<<Table_Name>>_<<TypePI>>(<<Field(s)>>). Corresponde al nombre del Primary
Index. Debe indicarse el nombre de la tabla, seguido del Tipo de PI: UPI (Unique
Primary Index) o NUPI (No Unique Primary Index) y entre parntesis van los
campos que se han definido como PI. Para ms detalle y ejemplos debe hacer uso
del Estndar de Construccin Objetos DB (ECODB).
<<PARTITION BY RANGE_N or CASE_N>>. Corresponde a las particiones definidas
para la tabla. Deben seguir las definiciones estndares de TERADATA y su uso es
obligatorio para todos los casos en que las consultas y tanto las cargas como la
explotacin, requieran optimizacin.
Comment corresponde a las descripciones de la tabla y de cada uno de sus campos.
La descripcin debe ser explicativa de la funcin u operacin de la tabla o campo y
ojal con algn ejemplo. Esto aplica slo a tablas fsicas. Tablas temporales o
voltiles no aplica.
5.2. ORDEN DE SCRIPT DE CREACIN DE TABLAS INICIALES

Para la primera instalacin, los scripts de creacin de tablas, poblamiento y estadsticas,
deben estar en el siguiente orden y por separado:
a) Crear la estructura de la tabla con su PI o NOPI.
b) Poblar la o las tablas. Realizar el Select-Insert o usar TPT - BTEQ.
c) Colectar Estadsticas al menos de los campos PI de las tablas fsicas y de sus
particiones en el caso de que existan. Este script en general ser utilizado por los
administradores semanalmente. Slo si es estrictamente necesario, este script
podr ser utilizado en los procesos del proyecto y ser el arquitecto quien verifique
su utilizacin. (Ver apartado 9 para ms detalle).

Esto aplica para la base STG principalmente, sin embargo, tambin aplica a las bases ODS y
FDM e incluso LOG en la primera instalacin del producto. Los scripts de cada base
(ejemplo: STG, ODS y FDM al menos) deben ir por separado.
En especial el punto c) debe ser aplicable a todos los proyectos. Se reitera que las
estadsticas debieran estar en procesos masivos semanalmente, excepto a los que
requieran que los procesos actualicen las estadsticas frecuentemente debido a
performance de estos mismos, como por ejemplo previo a la carga de ODS o FDM. Cada
caso debe ser validado por el arquitecto y supervisado por el DBA.
En general el diseo fsico de la base de datos en Teradata se debe considerar demografa
de acceso, demografa de datos y volatilidad de stos. Por ello no puede faltar el punto c).
Para ms detalles de diseo DB y tipos de ndices en Teradata utilice el documento
publicado por Teradata y que puede encontrar en TDT-DBDesign.
5.3. ORDEN DE SCRIPT DE TRASVASIJE TABLAS

Para realizar el trasvasije se deber realizar un script por cada tabla.
En el script de trasvasije por cada tabla debe contemplar:
a) Respaldar tabla origen. Es decir, renombrar las tablas existentes.

b) Crear la estructura de la tabla destino con su PI y descripciones.
c) Poblar la tabla o las tablas, realizar el Insert- Select de tablas origen a destino.
d) Borrar la tabla origen (drop de tabla renombrada o de respaldo)
e) Actualizar estadsticas ya sea por administracin o por proceso. Deber definirlo
arquitecto del proyecto. En caso de mantenimientos, lo definir DBA.
En otro script, debe colectar estadsticas al menos de los campos PI de las tablas fsicas.
Este script ser utilizado por los administradores y no deben ser usadas por los procesos
del proyecto. (Ver apartado 9 para ms detalle).
5.4. PRIMARY INDEX DE TABLAS

Se debe asegurar una buena distribucin de los datos en Teradata aplicando las mejores
prcticas respecto a Primary Index (PI) o NOPI. Toda tabla debe tener un PI definido
durante la creacin o tambin puede indicarlo como NoPI (Este tipo de tablas son
particularmente utilizadas para el volcados de cargas de datos en el staging). Los campos
seleccionados como PI deben propiciar distribucin de los datos en los AMPs en forma
eficiente y el JOIN con otras tablas del modelo. Es recomendable usar tablas de tipo NOPI
para el STG en los que slo requiera una carga masiva de tablas sin transformaciones
intermedias o posteriores.
La identificacin de los PI para la explotacin de la base de datos es importante a la hora de
consultar el objeto. Para asegurar que el diseo fsico haya incorporado un anlisis de PI,
todo proyecto deber adjuntar el documento denominado Anlisis de PI y su

distribucin. Este documento debe contener al menos las tablas ms representativas del
modelo que haya sido aprobada por el arquitecto.
Generar tablas con mala distribucin puede ocasionar serios problemas de perfomance de
las consultas y de todo el sistema.
Siempre debe analizar la utilizacin de Primary Index nicos (UPI), pero cuando no exista
uno viable o no sirva para joins con otras tablas, entonces se debe verificar la utilizacin de
un Primary Index no nico (NUPI).
5.4.1. VALIDACIN DE DISTRIBUCIN DE DATOS

Para analizar la distribucin de datos en base a PI, se puede utilizar la siguiente estructura
de consulta que entrega la cantidad de registros que maneja cada AMP. Lo que
corresponde a la distribucin para el PI seleccionado.
SELECT (HASHAMP(HASHBUCKET(HASHROW(<<PI_SELECCIONADO>>)))) AS AMP_No,

COUNT(*) AS Row_Count
FROM
<<TABLA>>
GROUP BY AMP_No ORDER BY AMP_No;
5.4.2. VALIDACIN DE SKEW FACTOR

El skew factor debe tener un valor menor a 10. Pueden existir excepciones en el caso de
que la cantidad de registros sea muy baja y no alcance a cubrir la totalidad de los AMPs.
Para calcular el skew se puede utilizar la siguiente consulta. Si no tiene autorizacin, por
favor solictela a QA.
/* CALCULO DE SKEW */ VALIDAR porque no me funcion --- me dio errro

SELECT
SUM(SKEWCALC.NumberOfRows) AS TotalRows
,MIN(SKEWCALC.NumberOfRows) AS MinRowsOnAmp
,MAX(SKEWCALC.NumberOfRows) AS MaxRowsOnAmp
,AVG(SKEWCALC.NumberOfRows) AS AVGRowsOnAmp
,100 - ( AVG(SKEWCALC.NumberOfRows)
/ MAX(SKEWCALC.NumberofRows) * 100 ) AS SkewFactor
FROM ( /* Tabla derivada para calculo de Skew*/
SELECT
HASHAMP (HASHBUCKET (HASHROW(
/* Campos candiadtos para Primary Index (PI )*/
))) AS AMPNumber
,COUNT(*) AS NumberOfRows
FROM /* Base.Tabla */
<<base>>.<<Tabla>>
GROUP BY TotalRows
No debe permitir valores nulos o vacos en los campos que formarn parte del PI. Al
momento de definir una tabla, se debe agregar Not Null a los campos del PI.

Para realizar copia de tabla, siempre debe hacerlo a una tabla vaca en el destino. Estas
tablas deben tener el mismo PI. El beneficio de este es que se evita la comparacin de
registros ya existentes con los registros que se insertaran, y a su vez no hay redistribucin
de informacin.
Desde la versin 14.10 se permite utilizar Varchar en el PI. Este tipo de datos no tiene
ningn impacto sobre recursos del servidor. El valor del PI es usado en el Hash Algorithm
de la lataforma para generar la distribucin de los datos entre los AMPs del sistema. Esto
se efecta independiente del tipo de dato y del tamao de valor usado como PI.
Cuando se define un PI como NUPI intente que la cantidad de registros por combinatoria
de NUPI no supere los 150 registros. Valores nulos o vacos disparan esta cantidad.
Debe utilizar valores pequeos para los campos que formaran parte del PI. Esto es bueno al
momento de actualizar estadsticas y en los Joins de tablas.
Se debe utilizar la menor cantidad de campos posibles al momento de definir un UPI o
NUPI.
No confundir los Primary Index con Primary Key. Recordemos que en Teradata el Primary
Index es el criterio de distribucin de los registros en los AMPS y el Primary Key es una
restriccin de unicidad.
Mtodo de
Fortalezas Debilidades
acceso
Es el mtodo ms eficiente, cuando la declaracin SQL Ninguno, mientras la(s) columna(s) sean se
ndice nico contiene el valor del ndice primario. bien escogidas.
primario No requiere un archivo contenido en la base de datos
UPI cuando el nmero de filas retornadas es pequeo
Provee un acceso eficiente cuando la declaracin SQL Es lenta bajo un INSERT

contiene el valor del ndice primario.

ndice no nico No requiere un archivo contenido en la base de datos Puede disminuir la eficiencia, cuando algunos
primario NUPI cuando el nmero de filas retornadas es pequeo valores se repiten muchas veces en las misma
columna.
Provee un acceso eficiente cuando la declaracin SQL Requiere costo adicional para INSERT, UPDATE,
contiene los valores de USI, y no se especifica valores de MERGE y DELETE
ndice nico
ndices primarios.
secundario
No requiere un archivo contenido en la base de datos para Se sugiere su uso principalmente para
USI
un SELECT. explotacin de datos. Para las cargas es
afectado en performance.

Provee un acceso eficiente cuando el nmero de filas por Requiere costo adicional para INSERT, UPDATE,
ndice no nico
valor en la tabla es pequea. MERGE y DELETE
secundario
Puede requerir un archivo contenido en la base de datos.
NUSI

No ser usada por el Optimizador de Teradata.
Accede a cada fila de la tabla a la vez Examina cada fila

Bsqueda
Provee acceso usando cualquier condicin Requiere un archivo contenido en la base de
completa de
datos tan largo como la tabla
tabla
Si no se puede asegurar una buena distribucin o es difcil definirlo, utilice las

herramientas existentes para identificar candidatos a PI o contacte a QA para solicitar
servicio de anlisis de PI.
5.5. TABLAS DE TIPO NOPI

Tablas NoPI son particularmente usadas para tablas de staging para carga de datos
masivas (bulk data loads). Cuando una tabla no tiene primary index, sus filas pueden
ser enviadas arbitrariamente a cualquier AMP, de manera que el sistema puede cargar
datos en tablas staging ms rpida y eficientemente usando operaciones insert en
TPTLoad (Fastload) o Teradata Parallel Data Pump (TPump). El impacto en el
rendimiento de CPU e I/O se reduce significativamente.
NoPI indica No Primary Index. Se debe especificar NO PRIMARY INDEX en la sintaxis de
CREATE TABLE.
Algunas restricciones:
No se debe crear tablas de cola como NoPI
No se debe crear tablas de errores como NoPI
No se deben crear tablas NoPI tipo SET, slo deben ser MULTISET.
Tablas NoPI no deben tener permanent journal.
SQL UPDATE no pueden realizar update a tablas NoPI.
Beneficios:
Una table de tipo NoPI reduce el skew en tablas intermedias de ETL las cuales
no tienen un PI natural.
Las cargas (insert - TPTLoad (FastLoad) y/o TPump) a Tablas de Staging tipo NoPI
son ms rpidas.
Para ms detalles refirase a documentacin oficial Teradata en NoPI

5.6. SET VERSUS MULTISET
Al momento de crear tablas se deber usar MULTISET por sobre el SET para el
poblamiento de tablas, esto para que el motor no ocupe ms recursos en la
identificacin de registros duplicados.
Toda tabla de carga debe ser creada como MULTISET y con ndice de tipo UPI, para as
evitar retardos en la carga de datos y disminuir la carga de procesamiento del motor, la
unicidad del dato estar garantizada. No se debe sobrecargar al motor con tablas de tipo
SET.
1. Tabla SET con UPI. De esta manera Teradata chequea por duplicidad de valores PI y
rechaza los duplicados, no hay necesidad de escanear toda la fila y todas las
condiciones se satisfacen. Es recomendable.
2. Tabla MULTISET con UPI. De esta manera si ya se ha chequeado que no existan
valores duplicados para PI, se satisfacen todas las condiciones. No requiere escaneo
completo a las filas. Es recomendable.
3. Tabla SET con NUPI. Necesita escanear fila completa para evitar filas duplicadas en
PI. Puede tener filas duplicadas si eso no es problema para el caso de negocio. No
conviene esta combinacin
4. Tabla MULTISET con NUPI, no requiere ningn chequeo, es aplicable slo si las
restricciones se han controlado en ETL y todo est bien en los datos. Es recomendable
para el motor ya que no impacta en la carga, pero puede contener duplicados o skew
podra ser alto.
Para optimizar las cargas, es ms eficiente usar MULTISET UPI. Cualquier opcin con
NUPI debe ser justificada. Slo en casos de que utilice NUPI, se recomienda realizar el
manejo de duplicidad en la capa de ETL.
Es decir:
SI no tiene control de duplicidad en ETL entonces Teradata necesariamente tendr que
garantizar la no duplicidad y por lo tanto debe tener SET/MULTISET con UPI para que la
revisin sea ms eficiente.
5.7. COMPRESIN DE TABLAS

Teradata puede comprimir campos de una tabla para reducir el espacio utilizado, esto
genera un mejor performance al leer o escribir en los campos con compresin aplicada.
Existen algunas consideraciones:
Campos ndices no pueden ser comprimidos.
La comprensin no aportar mayor beneficio si la columna en cuestin tiene
valores mayoritariamente nicos.

Los valores nulos son automticamente comprimidos.
El lmite de valores a comprimir por columna es de 255.
La comprensin de datos no es aplicable a objetos voltiles.
La comprensin tiene que ver directamente con la definicin de creacin de una tabla,
esto implica que cualquier actualizacin de la compresin de datos requiere una nueva
definicin para la tabla afectada por ende se hace necesario un trasvasije de datos
renombrando la tabla original y creando la estructura modificada para realizar el
trasvasije y luego dropear la tabla backup.
El impacto de actualizar una definicin de comprensin para una tabla en uso guarda
relacin con el tamao de dicha tabla ya es preciso contar con un espacio temporal
para hacer el respectivo movimiento de datos. Por lo tanto es recomendable que todos
los modelos incorporen la mayor cantidad de campos con compresin desde su
desarrollo o su mantencin.
Se puede mejorar la compresin de multivalores solo para los siguientes tipos de datos:
Nulls, Zeros, Blanks
BYTE. Hasta 510 bytes
BYTEINT. Hasta 510 bytes
CHARACTER. Hasta 510 caracteres.
DATE. Expresado como COMPRESS (DATE yyyy-mm-dd).
DECIMAL/NUMERIC
DOUBLE PRECISION
FLOAT
GRAPHIC. Hasta 510 caracteres.
INTEGER
REAL
SMALLINT
VARCHAR
VARGRAPHIC
Para definir los valores candidatos que se pueden comprimir, se debe analizar la
demografa del dato.
Siempre es recomendable aplicar compress a las tablas. Por lo tanto, si la tabla
generada y cargada sobrepasa 1 GB debe incorporar compresin obligatoriamente con
el fin de disminuir el tamao.
Para calcular el tamao de una tabla use la siguiente consulta:

Select databasename
,tablename
,(((sum(currentperm))/1024/1024) (decimal(15,2))) as espacio_mb
From dbc.allspace
where
tablename = <nombre de la tabla>
and
Databasename = <nombre de la base de dato>
Groupn By databasename, tablename;
Para las actividades de anlisis de compresin se debe usar MVC que permite obtener
los DDL de los modelos con las compresiones sugeridas. Se puede aplicar posterior a un
anlisis.
5.8. PARTICIONAMIENTO DE TABLAS

Las particiones permiten mejorar el performance de las consultas. Por lo tanto es
necesario realizar anlisis y aplicar particionacionamiento (PPI: Partition Primary Index
o MPPI: Multiple Partition Primary Index) en los modelo de datos siempre y cuando
mejore las consultas o las eliminaciones en base a particiones.
Una particin o particiones pueden optimizar bsquedas pero depender de las
estrategias o procesos que requiere realizar sobre la base. Una de estas condiciones
son las siguientes: la tabla contiene algn campo fecha y adems que el acceso a la
tabla sea por fecha. Los campos de particionamiento estn en el PI si se requiere Otras
condiciones de particionamiento dependen del problema de negocio que se desea
resolver.
Si las condiciones no se dan para utilizar particiones favor contactar a QA para evaluar
alternativas o consensuar la no utilizacin de PPI. Debe justificar si la tabla no lo
requiere.
El proyecto deber entregar el resultado del estudio de particionamiento de tablas,
utilizando las mejores prcticas para la definicin de los PPI. Las particiones a definir,
depender de las estrategias para explotar el modelo. Para su implementacin, todo
proyecto o mantencin debe explicar en la documentacin las razones por las cules se
elige un PPI en particular. En revisiones tempranas y control de calidad debe verificarse
el uso apropiado de esta capacidad.
El o los PPI elegidos deben estar indicados en la creacin de las tablas que aplica
particionamiento.
Las particiones multinivel (MLPPIs), permiten mejorar significativamente el
performance de ciertas queries y para realizar operaciones de insert de alto volumen,
update y delete.

Para su administracin posterior, debe ser entregado un script con indicacin de
mantenciones de los PPI al menos por un ao las que sern responsabilidad de quienes
se hagan cargo de las mantenciones. Ms detalles en documentacin oficial de
Teradata en PPI-MPPI.
5.9. FALLBACK Y JOURNALIST

Fallback y Journalist no est permitido debido al exceso de uso de disco y I/O.
Los scripts de creacin de tablas debern contener como se muestra a continuacin.
CREATE <<MULTISET/SET>> TABLE <<BASE>>.<<NOMBRE_TABLA>>,
NO FALLBACK,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT
Si algn proyecto o modelo requiere usar una o ambas capacidades, deber ser
fundamentado y aprobado por Arquitectura.
5.10. JOINS DE TABLAS

Se debe considerar que un inner joins, automticamente analiza las tablas y utiliza la
tabla de menor tamao para su copia en los AMPs. En el caso de los outer joins
Teradata no hace lo mismo, por lo que se debe tener cuidado en el orden de las tablas
en el join.
Por la manera en que Teradata hace los joins, es ideal que las tablas usadas tengan el
mismo Primary Index.
Nunca se debe realizar joins entre campos NUPI de una tabla versus NUPI de otra tabla.
Si no se est seguro si los campos contienen o no nulos, debe filtrarlos en la sentencia
where de la consulta. Ejemplo ( where col1 is not NULL;)
Utilizar los outer join solo cuando sea realmente necesario. Se recomienda no
involucrar ms de dos tablas en el outer joins.
Si se utilizara la sentencia union para hacer uniones de tablas, debe considerar que
esta sentencia elimina los duplicados, en algunos casos, es recomendable utilizar las
sentencias union all, en el caso de no realiza la validacin de unicidad (ya que esta
sentencia no elimina los dupicados) por lo que la respuesta es ms rpida y ocupa
menos recursos. Los registros duplicados no siempre son un problema y depender de
la necesidad de la query.
Se recomienda nunca colocar campos de condicin de filtro en los ON de los joins.
Si va a utilizar subselect para realizar un join de tablas, debe filtrar las tablas antes de
realizar el join, es decir, colocar los filtros dentro de cada subselect. Siempre se
recomienda el uso de explain para analizar la consulta antes de ejecutarla.
Recordar que cuanto menos espacio utilice una consulta, mejor ser su perfomance.
Ms lectura de disco (I/O) se traduce en consultas con mal performance y a su vez muy
costosas de resolverlas.
5.11. TABLAS TEMPORALES Y VOLTILES

Las tablas temporales o voltiles deben ser implementadas en el mbito _TMP de la
base de datos.
La aplicacin de estadsticas se debe aplicar a tablas temporales. Se podrn exceptuar
las tablas cuya variabilidad de datos sea menor al 10% o si las tablas de origen y destino
tienen el mismo PI y es para select/insert exclusivamente. Pero si este tipo de tablas es
utilizado por vistas o por utilitario para realizar transformaciones o explotacin de ellas,
se debe incorporar script para clculo de estadsticas.
Las tablas temporales, deben identificarse en el nombre con el prefijo TMP y con la
concatenacin al final de la fecha de creacin. Por ejemplo:
TMP_DET_CLIENTESLAN_130201: Esta tabla fue creada el 1 de febrero del 2013.
Siempre debe considerar que el DBA podr borrar las reas TMP sin previo
aviso.
Las tablas voltiles se deben identificar en el nombre con el prefijo VLTL. Por ejemplo:
VLTL_ DET_CLIENTESLAN. No requiere fecha porque su vigencia caduca al
finalizar la sesin del usuario.
El DBA ser responsable de eliminar estos objetos mediante un proceso automtico.

Las tablas temporales y/o voltiles sirven de mucho a la hora de mejorar la perfomance
de un query en particular. Adems, sirven para hacer agrupaciones previas lo cual
genera rapidez en ciertos casos. Tambin permite minimizar la cantidad de registros a
involucrar en un query que no son necesarios.
Es importante realizar explain a las consultas que utilizarn este tipo de tablas para
verificar que la incorporacin de temporales o voltiles alcance el objetivo esperado.
Las tablas temporales y voltiles requieren generar estadsticas al menos de los campos
PI, las que deben ser calculadas en los procesos segn corresponda. (bteq o scripts).
5.12. ALTER TABLE

Los alter table solo sern permitidos en tablas pequeas. Es decir, se puede realizar
alter sobre tablas que no superen 1 GB de tamao. No es recomendable para tamaos
mayores a 1 Gb ya que corre el riesgo de bloqueo de la base de datos.

6. VISTAS
El acceso a datos debe ser mediante vistas. Se pueden diferenciar dos tipos de vistas:
vistas a tablas, vistas de negocio.
Las vistas a tablas corresponden a una capa de acceso de una tabla en especfico y se
debe ubicar en base <<BASE>>_VT. Todas las consultas deben tener como prefijo la
base en la que se encuentra el objeto referenciado.
select <<fields>> from <<Base>>.<<Table>>;
Las vistas de negocio corresponde a una vista que incorpora alguna restriccin o lgica
de negocio a una o varias tablas.
Select <<some_fields>> from <<base>>.<<table o consultas>>
where <<condition>> <<group by some_fields >> <<order by some_fields >>.
La vista tabla o tabla debe seguir las reglas indicadas en el captulo de tablas.
Los usuarios finales no deben crear vistas, ya que se podra estar violando normas de
seguridad a nivel de acceso a objetos, ya que un usuario eventualmente podra dar
acceso a otro usuario que no posee el mismo perfil a travs de una vista. Toda vista que
no est creada en un proyecto, debe ser solicitada a mantenciones LATAM.
Se debe optimizar el uso vistas anidadas considerando todas las mejores prcticas de
las tablas y utilizando las herramientas propias de teradata para este objetivo (Visual
Explain e Index Wizard en ambientes desarrollo y beta).
Es preferible generar solo una vista que llame a tablas y no a otras vistas, esto con el fin
de eliminar filtros adicionales a vistas ya filtradas.
Todas las vistas que hacen refencias a tablas fsicas directamente deben incorporar
locking for access, esto es para evitar posibles bloqueos con otro tipo de sentencias. En
el caso de vistas de tablas VT deben tener locking for Access, pero en el caso de Vistas
de negocios VW, que hagan referencia a VT, no es necesario duplicar la sentencia de
lock. Lo importante es que realice el locking antes de utilizar la tabla para las sentencias
que corresponda.
Para ms detalles debe hacer uso del Estndar de Construccin de SQL existente en
http://arquitectura.lan.com.
7. MACROS
Las macros se utilizan para ejecutar un conjunto de tareas repetibles. Las macros son
objetos de base de datos y por lo tanto pertenecen a un usuario o base de datos
especificada en su creacin. Una macro puede ser ejecutada por usuario, BTEQ o por
otra macro. Sin embargo, las macros ejecutadas por otra no se permitirn.

Las macros deben ser cortas. Una macro completa es una sola transaccin requiere un
Transient Journal de la transaccin total, por lo tanto sobrecargar el sistema si es
muy extensa.
El cdigo de las macros puede tambin especificar parmetros que pueden ser
reemplazados por datos cada vez que la macro es ejecutada.
Las macros usualmente son ms eficientes para queries repetitivas que para una
sentencia simple. Las macros no estn diseadas para retornar parmetros a algn
solicitante: Retornan solo el conjunto de respuestas para las sentencias SQL que
contiene.
Las macros solo pueden ser ejecutadas con los privilegios EXEC sobre la BD
Las macros pueden proveer seguridad a nivel de columna.
Las Macros tienen las siguientes ventajas:
Se reduce el trfico de red.
El plan de ejecucin puede estar en cach, reduciendo la sobrecarga del parsing
del motor.
Aseguran un funcionamiento eficiente de las componentes en la sentencia SQL.
Permite tener componentes de base de datos reutilizables ahorrando recursos
del cliente.
Pueden ser utilizados para obligar a la integridad de datos y modificadores de
bloqueo.
Pueden ser utilizados para hacer cumplir la seguridad.
8. FUNCIONES
En Teradata podemos encontrar funciones estndares y definidas por el usuario. Se
aceptar utilizar las funciones estndares y no se aceptar funciones definidas por el
usuario.
9. EXPLAIN Y VISUAL EXPLAIN

El uso del EXPLAIN es clave para visualizar el buen desempeo de una consulta. Es
responsabilidad de cada rea interesada en explotar Teradata, profundizar en la lectura y
anlisis de consultas mediante EXPLAIN, considerando que es parte integral de todo
diseo, documentacin y explotacin de un modelo. Debido a que la demografa del dato
cambia constantemente, el resultado de los anlisis por explain varan.
Se debe considerar que los tiempos que el optimizador seala son solo de comparacin,
por lo tanto no son necesariamente exactos. Generalmente depende de aplicacin de
estadsticas y de otros factores relacionados con el diseo y los recursos disponibles.
Por ejemplo:
Caso 1 (no ptimo):
SELECT rut, nombre FROM bd.pasajeros WHERE rut IN (SELECT rut FROM bd.viajes);
Estimed time: 30 min.
Caso 2:
SELECT pax.rut, pax.nombre FROM bd.pasajeros pax inner join bd.viajes vjs
ON pax.rut = vjs.rut;
Estimed time: 2 min.
No es correcto decir que el caso 2 demora 28 minutos menos que caso 1

Lo correcto es decir el caso 2 es 14 veces ms eficiente que el caso 1.
Terminologa output del Explain que se debe ser analizada:

All-AMPs ..
Redistributed by Hash Code
Product join
All-AMPs Join
Index not used
With Low / No Confidence
Terminologa output del Explain cuando es ptimo:

Built Locally on the AMPs
Duplicated on all AMPs
Merge join
Single AMP JOIN
By way of index
With High / Index Join Confidence
Es muy importante saber que en Teradata existen muchas formas de realizar una misma
consulta sin perder los resultados. Los tiempos de espera son dramticamente distintos
entre una buena y mala consulta, es importante que cada Query que se desarrolle sea
visualizada utilizando Explain.
Si un Query demora demasiado favor revisarlo y no volver a reintentar su ejecucin sin
antes haber analizado su plan de ejecucin.
Tomar en cuenta tambin que para un buen desarrollo, primero las mquinas de desarrollo
y beta, deben ser lo ms parecido a su ambiente productivo. El optimizador se comporta
distinto si las versiones de motor Teradata son distintas entre ambientes, o bien, si en
produccin las tablas poseen ms datos que en ambientes de desarrollo y testing.
Intentar siempre utilizar el signo igual (=), cuando se requiere filtrar algn campo de la
tabla esta sean siempre los que forman parte de UPI / NUPI.

Ejemplo:
Select rut, nombre from ejemplo.tabla where rut <> 3456768,
En este caso el primary index no es utilizado, por lo que el Teradata realiza un proceso
costoso. (All-AMPs..)
Se recomienda no realizar operaciones matemticas con campos que forman parte del
primary index.
El uso de Visual Explain estar restringido a usuarios lderes en las reas de mantenimiento,
arquitectura, continuidad de negocio y tcnicos en los proyectos. Uno de los entregables de
proyectos y mantenciones debe ser la evidencia del anlisis de explain.
10. COLLECT STATISTICS

Una estadstica adecuada logra disminuir notablemente los tiempos de ejecucin y mejoran
el performance de TDT sin embargo requiere ms recursos para ello. Por lo tanto, cada
nuevo proyecto o mantencin debe aportar su propio set de estadsticas requeridas en
funcin de las consultas que ms frecuentemente se utilizarn o a lo menos de los PI
definidos para cada tabla.
No obstante, en el transcurso del tiempo las consultas con las que se explote el modelo
pueden variar, o dada la naturaleza dinmica de los negocios en particular pueden
generarse nuevas consultas. Por lo tanto, es fundamental que el rea encargada de la
administracin de la plataforma establezca un plan de actualizacin peridica de
estadsticas. Para esta actividad TDT cuenta con una herramienta administrativa llamada
Statistics Wizard que permite generar estadsticas para uno o varios modelos al mismo
tiempo.
Los collects statistics pueden crearse o actualizarse tanto para ndice o bien por campos que
no participan en el PI.
Se debe usar sintaxis de la nueva versin para la coleccin y recoleccin de las estadsticas
(recomendado desde la versin 14.0 en adelante)
Para la Coleccin:
COLLECT STATISTICS
COLUMN (o_orderdatetime,
o_orderkey)
,COLUMN o_orderdatetime
,INDEX o_orderkey
ON Orders;

Para la Recoleccin:
COLLECT STATISTICS ON Orders;

La recoleccin en este formato permite aprovechar la informacin de la coleccin original
para usar un plan ptimo
Adems las estadsticas a nivel de una columna puede aprovechar la informacin de las
estadsticas combinadas generando en este caso especfico un ahorro de 50% de CPU
Para el caso de Indices se debe usar el siguiente comando:
Collect statistics index (col1, col2) ON ejemplo.tabla; (esta es requerida)
Collect statistics column (col1) ON ejemplo.tabla; (esta es requerida)
Collect statistics column (col2) ON ejemplo.tabla; (esta es requerida)
Donde Col1 y Col2 son campos que participan del PI elegido.
Para el caso de campos que no participan del PI, los collect statistics consumen y exigen
muchos recursos del sistema, por lo que se debe tener cuidado en el consumo de estos en
estos casos.
Se debe analiza el tamao de las tablas para decidir realizar un collect statistics utilizando
todos los registros o con un una muestra representativa de ellos, por ejemplo 10%, como
recomendacin, sin embargo se puede otro tamao de muestra, la que se debe justificar.
Esta actividad en principio es responsabilidad del proyecto o mantencin, sin embargo, en
el on-going es responsabilidad del DBA para la recoleccin.
Ejemplo:
Collect statistics using sample index (col1, col2) ON ejemplo.tabla;

Collect statistics using sample column (col3, col4) ON ejemplo.tabla;
Dnde col1, col2, col3 y col4 no participan del Primary Index.
Se debe colectar Estadsticas de tablas temporales y voltiles al menos de los campos PI, las
que deben ser calculadas en los procesos segn corresponda (bteq o scripts).
Se recomienda generar y actualizar estadsticas en campos que son de alta modificacin
como lo pueden ser campos fecha, nmeros de vuelos, etc.
Se debe calendarizar las actualizaciones de las estadsticas. Si las estadsticas no son
actualizadas, los queries pueden tener un mal performance (Tarea que corresponde a DBA).
Durante la construccin y explotacin de una base de datos, se recomienda preparar planes
de estadsticas. Para ello, con el utilitario SQL Assistant o Teradata Studio Express, se debe
usar el comando DIAGNOSTIC HELPSTATS ON FOR SESSION;, de esta forma, obtener
recomendaciones del motor y adems evaluar la variabilidad de los datos en las tablas.

Cada vez que prepare una consulta, utilice explain. Para ello, si utiliza SQLAssistant, desde la
ventana de la consulta a la cual se le requiere obtener estadsticas se presiona la tecla F6
(explain de la consulta), lo anterior permite ver el plan de ejecucin con las
recomendaciones de estadsticas hacia el final de dicho plan de ejecucin. Del plan de
ejecucin debern rescatar las estadsticas de alta recomendacin (HighConf),
Otra tcnica que se aplica a tablas con gran volumen de registros, es la utilizacin de
estadsticas parciales. As, se indica un porcentaje de los registros, lo cual permite reducir
los tiempos de recoleccin de estadsticas. Se debe utilizar a criterio y depender de la
variabilidad del dato y del tamao de la tabla.
La recomendacin de TDT es aplicar estadsticas a todas las tablas independientes de factor
skew.
Para el caso de aplicacin de estadsticas sobre campos que no participan del PI la
recoleccin de estadsticas se debe aplicar con criterios ya que el collects demanda recursos
del sistema. Por lo tanto, en el caso de que el motor recomiende aplicar sobre campos que
no participan de PI, slo se debe aplicarse en los que indiquen HighConf. Para el caso del
refresco de stas mismas, se debe verificar si tiene alta variabilidad de datos.
Observacin: todo proyecto es responsable de entregar los scripts para la aplicacin de
estadsticas de sus modelos. La ejecucin de scripts para recolectar estadsticas a tablas
fsicas es responsabilidad del DBA para los casos ms centralizados y as definidos, sin
embargo, es aceptado ejecutar estadsticas dentro de los procesos si es necesario para
mejorar el performance de otros procesos que dependan de ellas, esto debe ser verificado
por Arquitectos y DBA. La ejecucin de scripts para recolectar estadsticas a tablas voltiles
y/o temporales debe ser implementada en los procesos de proyectos.
Recomendaciones para TDT 14.10 sobre cundo y a qu aplicar recopilacin de estadsticas
completa
Columnas no indexadas utilizadas en el predicado
Todas las NUSI (No Unique Secundary Index)
USI/UPI si es utilizada en un predicado non-equality (restricciones de rango)
La mayora de las NUPIs (ms abajo se discute en detalle)
Estadsticas completa siempre requieren ser colectadas sobre columnas
relevantes e ndices en tablas pequeas (menos de 100 filas por AMP)
En todas las tablas particionadas que estn sometidas a un crecimiento.
Partitioning columns of a row-partitioned table.
Para ms detalle ver el Anexo 18

11. PROCESOS DE CARGA FRAMEWORK DE ETL/ELT
Para los procesos de carga se recomienda siempre utilizar las herramientas nativas de
Teradata. En el caso de cargas a rea de Staging es recomendable utilizar TPT load. Para las
cargas de ODS y FDM es recomendado utilizar BTEQ.
11.1. BTEQ
Es un utilitario basada en herramientas va comando que permite al usuario conectarse a
base de datos Teradata. Provee una interaccin en lnea o batch que permite al usuario
ejecutar sentencias SQL para las operaciones de datos.
Para ms detalles de estndar y mejores prcticas BTEQ debe consultar el documento:

Estndar de Construccin BTEQ. EBTEQ
11.2. TERADATA PARALLEL TRANSPORTER (TPT)

Teradata ha actualizado los conectores llamados TPT (Teradata Parallel Transporter) que
consisten en las cuatro operaciones bsicas:
1. Load Operator: Carga masiva de tablas vacas (FastLoad protocol)
Corresponde al uso del protocolo FASTLOAD. Herramienta de carga diseada
para mover grandes volmenes de datos a tablas vacas. Sobre todo para
proyectos que realizan cargas iniciales histricas que demandan mucho tiempo
de proceso y muchos registros. Un escenario adecuado es cuando desde otras
fuentes se deben cargar tablas temporales, de paso a modelos finales, que
facilita la carga de datos iniciales en forma expedita.
2. Update Operator: Load/update/upsert/delete masiva de tablas (MultiLoad
protocol)
Corresponde al uso del protocolo MULTILOAD. Herramienta que utiliza el
paralelismo de Teradata. Multiload trabaja a nivel de bloques lo cual lo hace
que sea una de las mejores herramientas para cargar tablas con datos ya
existentes. Los update utilizando multiload no son tan eficientes como se puede
esperar, en ciertos casos es ms rpido eliminar los registros a actualizar e
insertar el dato como si fuera nuevo, recordar que siempre se debe analizar qu
es lo que se debe resolver antes de implementar una solucin.
3. Stream Operator: Carga continua de tablas (TPump protocol)
Es un operador consumidor, que emula las utilidades de TPump para realizar
Inserts, Updates, Deletes, y Upserts en forma paralela a alta velocidad en un
near-real-time, a una o ms tablas vacas o preexistentes, sin bloquear las
tablas destino. El bloqueo es a nivel de fila, tal como se hace con los Operadores
SQL. El operador stream permite realizar operaciones de carga en background
durante el uso normal del sistema. Las instancias del operador Stream pueden

actualizar hasta 127 tablas en Teradata. Se pueden utilizar multiples instancias
paralelas para mejorar el performance de la actualizacin de los datos.
4. Export Operator: Descarga masiva de tablas (FastExport protocol).
Corresponde al uso del protocolo FASTEXPORT. Herramienta de extraccin de
datos de Teradata. Es lo contrario del fastload pero tan eficiente como l. Es
una herramienta extremadamente rpida para exportar grandes volmenes de
datos. El fastexport puede utilizar tanto una tabla como una vista de teradata
como fuente de datos.
Cuando se requiere incluir informacin que reside en archivos fuera de Teradata se puede
hacer utilizando el protocolo MULTILOAD . Si los tiempos de respuesta no son los esperados
utilizar protocolos FASTEXPORT o FASTLOAD a una tabla de paso y luego integrar la
informacin al Teradata con un Insert Select.
En los casos en que se debe realizar un update, es recomendable no usar la instruccin
update ya que los procesos son altos. Adems, se debe considerar que los rollback en
Teradata son bastante costosos en lo que se refiere a tiempo y uso de recursos. En ese caso,
el lugar de update se deber borrar los registros e insertarlos con los valores nuevos.
Si el proceso requiere eliminar registros, mejor hacer una copia utilizando la sentencia
insert select de los datos que no sern borrados en otra tabla. Renombrar la tabla original,
verificar que el insert select haya copiado los registros esperados. Restaurar los permisos
grant de la tabla si corresponde. Realizar un drop table de la tabla original.
Nunca abortar un proceso que lleva mucho tiempo en ejecucin ya que los rollbacks son
costosos en Teradata, sobre todo en los pasos de Merge.
12. CALIDAD DE DATOS

Asegurar la calidad de los datos es un asunto que hay que considerar. En general, mejorar la
calidad implica realizar varias operaciones en las consultas con el objetivo de obtener o
mantener los datos correctos. La mayora de las consultas podran provocar malos accesos a
los datos o bien nunca utilizan los primary index indicados para el acceso a los objetos, lo
que se traduce en mucha lectura de disco.
Es recomendable no cargar registros que no cumplen con algn tipo de calidad esperada
por el usuario. Adems, es recomendable asignar valores a campos que contienen datos
nulos.
Utilizar ms codificacin en tablas de gran tamao (tablas minor), o bien evitar almacenar
descripciones en tabla de estas caractersticas.
Considerar tabla de formatos y valores posibles de almacenar.
BYTEINT: Values between -128 to +127
SMALLINT: Values between -32,768 to +32,767
INTEGER: Values between -2,147,483,648 to 2,147,483,647
Fechas se debe utilizar DATE. No utilizar CHAR, a no ser que sea estrictamente necesario.
Para esto se solicitar justificacin.
Siempre utilice el mismo formato de campos para valores iguales de distintos modelos,
sobre todo si se piensa interactuar con otros modelos.
Extender el modelo de industria (DataWarehouse), esto facilita la integracin de la
informacin y evita modelos con objetivos similares, agregaciones innecesarias o bien
informacin duplicada.
13. MEJORES PRCTICAS TDT
No realizar update en campos que forman parte del primary index.
No solo porque este comando violara la integridad referencial de un modelo entidad

relacin sino que tambin porque son extremadamente lentos ya que los campos que
forman parte del primary index, Teradata los utiliza para realizar la distribucin de los
datos.
Es ms eficiente para el motor utilizar las agrupaciones en lugar de utilizar distincts.
Ejemplo:
Select <<field(s)>> from example.table_X group by <<field(s)>> order by <<field(s)>>;
El uso de Select distinct (a) from example.table_X order by XX ; este tipo de consultas
es menos eficiente en el motor teradata y por lo tanto no son recomendadas.
Para validar si una tabla contiene datos es recomendable utilizar:
Select TOP 100 <<campos>> from ejemplo.tabla_A;
Para estos casos tambin se puede utilizar el procedimiento que posee Teradata para
dicha funcin:
Exec sysdba.istableempty (nombre base de datos, nombre_Tabla);
Las consultas deben tener los campos nombrados en la estructura select. Esto garantiza
que los procesos de carga y explotacin no fallen.
Por ejemplo
Select <<campo(s)>> From <<Tabla(s)>>;
El tipo de estructura select * from ejemplo.tabla_A; tiene varios peligros. Si no tiene

condiciones podra no resolverse por el tamao de la tabla.
Si la respuesta a este tipo de consulta es ingresada en otra estructura, se corre el riesgo
de que no mapee.
Siempre debe utilizar locking for Access en las vistas o en consultas que hacen referencias a
tablas fsicas directamente de esta manera se evitan los bloqueos y mejoran el
performance del motor. Recuerde que el motor asume que los registros no estn siendo
modificados.
Nunca utilice un select * from <table> para revisar informacin. Realice la misma sentencia
pero utilizando el top 100 como mximo. Ejemplo: Select top 100 * from <table>.
FORMATO.
Para los campos fechas y a fin mejorar la lectura de estos, siempre deben crearse con
formato. (Ej. YYYY-MM-DD).
Se recomienda no utilizar definiciones de creacin de tablas que se importen de otros
motores sin una revisin del cdigo segn estas recomendaciones.
Desde la versin 13.10 los campos CHAR y VARCHAR tambin pueden ser comprimidos, por
lo tanto no es necesario restricciones a estos tipos de datos. En relacin a PI de tipo char o
varchar no hay diferencia para el clculo del algoritmo de distribucin.
El uso de Varchar es recomendado si el largo del dato es variable o es null ya que usar
mejor los espacios en el disco que un char.
Se debe tener en consideracin que un campo varchar siempre usara 2 bytes adicionales
para la cabecera. Esto ltimo no es una restriccin de facto.
Los campos CHAR o VARCHAR siempre debe definirlos como CHARACTER SET LATIN NOT
CASESPECIFIC.
Tablas Temporales
Se permitir definir tablas temporales con Set o Multiset, debe tener en consideracin que
la carga sea vlida para el objetivo de negocio o para registros nicos completos.
Nunca use Primary Index(PI) por defecto.
Teradata requiere siempre un PI a no ser que sea declarado NOPI. Si un PI no es definido

en el DDL de la tabla, Teradata toma la primera columna de la tabla y la hace NUPI (not
unique primary index) por defecto. Esto puede ser desastroso para el performance!

Siempre debe definir su propio PI para una tabla y nunca dejar que TDT cree un PI por
defecto de esta manera. Sin embargo, tambin puede declarar NOPI a las tablas de staging
que son para volcado masivo de datos sin transformaciones o uniones en los procesos.
Nunca permitir valores NULLS en una columna PI.
Configure todas las columnas PI como NOT NULL.
No prefiera usar un NUPI por sobre un UPI
Si los datos soportan, use UPI. Es una mala prctica definir como NUPI un ndice que puede
ser nico. Esto ltimo tiene implicancias negativas en el rendimiento.
Nunca elija un PI con el que sea imposible realizar Join.
Los tipos de datos TIME o TIMESTAMP no hacen un buen PI ya que es casi imposible
conocer sus valores exactos. Si tiene que hacer Join entre varias tablas, debe elegir el PI
que permita esa accin y que distribuya bien con skewfactor menor a 10.
Siempre debe revisar las tablas existentes antes de crear una nueva.
Sin duda es ineficiente crear tablas con idnticos contenidos. Incluso en los casos donde se
necesita slo un subconjunto de los datos existentes, no tiene sentido crear una tabla
nueva y copiar estos datos en ella. Una vista (VIEW) es todo lo que se requiere. Estas
medidas mejorarn el rendimiento general.
Defina NOT NULL siempre que sea posible
Si una columna nunca puede tener un valor NULL, defnala como NOT NULL, incluso si no
es una columna ndice. El performance del sistema mejorar.
Evitar datos nulos o vacos en campos que se utilizaran de filtros.
Nunca Actualice las columnas PI bien definidas.
Teradata se basa en el valor del PI para determinar en qu VPROC residir una fila de
datos. Si cambia el valor del PI, la fila tendr que ser trasladado a otro VPROC. Los cambios
masivos en los valores de PI resultarn en reubicaciones masivas de datos, que son muy
costosos para el rendimiento de TDT.
La mejor eleccin de PI
La mejor eleccin de PI son columnas de tipo de dato: SMALLINT or INTEGER. Sin embargo,
no es una restriccin del motor usar char o varchar como PI.
Tambin es recomendado usar PI donde las columnas sean de tipo char lo ms corta
posible.

Si el campo es variable, es mejor usar PI de tipo varchar, si el campo es fijo es mejor usar PI
de tipo char. Cualquiera de los dos, se debe indicar que sea not null.
No hay restricciones para usar char o varchar como PI, sin embargo, tambin puede usar
llaves subrogadas de tipo small or integer con el objetivo de usar menos espacio en el
sistema, si le es posible. Sin embargo, esto no es una restriccin del motor para el
algoritmo de distribucin.
Recuerde que el mejor JOIN es cuando las tablas a unir comparten el mismo PI.
Nunca use insert/select dentro de la sentencia de creacin de tablas
Este tipo de sentencias tiene un mal performance y podra bloquear el row hash del
diccionario de datos. Por lo tanto siempre debe primero crear la tabla con sus PI y
posteriormente realizar insert/select.
Nunca use insert/select dentro de la sentencia de creacin de tablas
Se debe verificar la consistencia de los tipos de datos en todas las tablas del modelo.
14. USO Y ACCESO DBC

El uso y acceso a DBC es mediante consultas a las vistas del DBC. Estas son permitidas y el
usuario de tipo usr_o/m_* puede tener acceso Selet. Sin embargo, como una forma de
garantizar consultas exclusivas al dbc para una base especfica, DBA deber generar las
vistas de DBC filtradas para cada base necesaria de consultar. Esto lo debe verificar en
revisin temprana el arquitecto y los dba de los ambientes de TERADATA debern proveer
dichas vistas. Para todo lo existente que use vistas de dbc no es obligacin realizar
modificaciones. Sin embargo, los nuevos proyectos o mantenciones requerirn estas vistas
adecuadas del DBC.
15. CONFIGURACIN CORRECTA DEL ODBC

Teradata recomienda su driver ODBC como mtodo de conectividad desde un cliente como
SQL Assistant.
Este driver ODBC tiene varias opciones por lo cual se recomienda lo siguiente:
A. Poner Nombre descriptivo al ODBC
B. No dejar las claves de acceso en el setup. Puede indicar el usuario paro no
almacene la contrasea.
C. Deje slo las opciones que se indican en la imagen

Es altamente recomendable desactivar la opcin "Use X Views".
Otro parmetro importante en el tamao del buffer.
En la opciones avanzadas, se puede ajustar el "Maximum Response Buffer Size"

(Tamao mximo del buffer de respuesta). El valor predeterminado es 8192. El valor
mximo permitido es 1048575. No hay un valor especfico recomendado. Cada uno de
las conexionesde los clientes requerir de un valor diferente. Si el valor es muy alto,
impactar las llamadas de metadatos. No existen efectos secundarios por usar valores
bajos.
Para el caso de cargas de datos es recomendable usar los conectores nativos de

Teradata como Fastload o Multiload por ejemplo.
Para el caso de interactuar con Datastage u otro ETL debe seguir las recomendaciones
indicadas por el vendor en conformidad con Teradata.
16. ESTANDAR DE GENERACIN DE USUARIOS.
El estndar de usuarios en Teradata es el siguiente:
usr_o_proy usuario de operacin para realizar la carga de datos.
usr_m_proy usuario de explotacin desde MSTR.
usr_p_proceso usuario de explotacin exclusivo para procesos que deben ser
identificados por reas productivas. No es de uso general. Slo PROD y ARQ definen
qu procesos deben usar este tipo de usuario.
Username: Nombre usuario: usuario con autorizacin, generalmente de CdN que
puede acceder a las vistas mediante un cliente como sql assisstant o teradata studio.
17. NOMENCLATURA DE TABLAS Y CAMPOS DIMENSIONALES

Las tablas definidas para un modelo dimensional deben estar en DataBase_FDM.
Tipo Objeto Nomenclatura Ejemplo

Tabla de Hechos FT_nombreTabla FT_SEGMENTOS
Tabla de Relacin RT_nombreTabla RT_VUELOS
Tabla de Loockup o LT_nombreTabla LT_PAISES
Dimensiones
Tabla Agregada FT_ nombreTabla _AGG_Nivel FT_TRAMOS_AGG_1
Para ms detalles de nomenclatura de tablas y campos, haga uso de Estndar de

Construccin Objetos DB: ECODB.

18. ANEXOS
18.1. FORMATO GENERAL. SINTAXIS DE CREACIN DE TABLAS

Las siguientes figuras corresponden a la sintaxis de creacin de tablas en Teradata

18.2. INDEX WIZARD
Index Wizard de Teradata es una herramienta que elimina las dificultades de la indexacin.
Automatiza la seleccin de ndices y genera informacin estadstica que permite a los
administradores de DB o diseadores tomar una decisin con pleno conocimiento de
ndices.
Esta herramienta consta de un componente de servidor de base de datos y una aplicacin
cliente front-end. El motor de anlisis del ndice se encuentra dentro del programa de
anlisis de Teradata y trabaja en estrecha colaboracin con el optimizador paralelo a
enumerar, simular y evaluar los candidatos de seleccin de ndice. La aplicacin cliente
front-end es una interfaz grfica de Microsoft Windows, que proporciona instrucciones
paso a paso para definicin de la carga de trabajo y anlisis de ndices, y reportes para la
carga de trabajo y anlisis de ndice.
18.3. SPOOL FANTASMA

Este apartado corresponde a mbito y exclusiva responsabilidad de DBA.
Spool fantasma (Leftover Spool) es una situacin anormal donde Teradata no libera su
spool despus de concretar la transaccin. Este significa que la cuenta con este problema
ve disminuido su lmite de spool. Para evitar este tipo de anomalas se debe realizar una
tarea administrativa en forma peridica o a pedido en cuanto el fenmeno aparece.
Cabe destacar que la gestin del leftover spool es una tarea administrativa recurrente
sobre la plataforma.
18.4. USO DE DATA BLOCK SIZE

Este apartado corresponde a mbito y exclusiva responsabilidad de DBA.
Data Block es la unidad fsica I/O para el sistema de archivos Teradata.
Con Data Block Size se puede determinar el tamao de bloque mximo para el
almacenamiento de mltiples filas sobre el disco. Por otro lado, este realiza los tamaos de
las operaciones con escaneo completos de tablas mediante la recuperacin de ms filas en
un solo I/O.
A modo simple, este concepto tiene relacin con la creacin de tablas en donde se
especifica la escritura de los datos en los cilindros. Lo mximo disponible es 255 bloques
por cilindro. Manipular el Data Block Size trae como beneficio evitar la fragmentacin de
los datos, sin embargo, requiere un anlisis para definir el tamao a aplicar para cada tabla.

En el ejemplo anterior hay una manipulacin directa sobre la definicin del tamao de data
block size y el porcentaje de espacio libre requerido, en este caso 10%. Se recomienda
incorporar en cada creacin de tabla la siguiente instruccin para asegurar un delta de
espacio para actualizacin de registro con lo cual se minimiza la redistribucin de datos:
DATABLOCKSIZE= # BYTES,
FREESPACE = 10 PERCENT,
El parmetro Freespace debe estar entre valores de 5% a 10%.
Esta actividad slo debe ser realizada por Administracin (DBA) y permite la limpieza de
cilindros. Debe ser considerado en las mantenciones y on-going. No es responsabilidad de
un proyecto especfico.
18.5. TERADATA COLUMNAR

Teradata Columnar es un nuevo paradigma de particionado, almacenamiento de datos y
compresin de datos que favorece la disponibilidad de combinaciones para el diseo de la
base de datos. Teradata Columnar provee Beneficios ya que reduce I/O para ciertas clases
de consultas y al mismo tiempo decrece el espacio utilizado.
Teradata Columnar ofrece la posibilidad de particionar una tabla o join index por columna.
Introduce un column-storage como una alternativa a row-storage para una particin
columnar y autocompresin. La columna particionada puede ser usada solo en una
definicin de particin nica o como una particin por fila en una definicin de particin
multinivel.
Una tabla particionada en forma columnar (CP) o join index tiene varias caractersticas
claves:
No tiene primary index.
Cada una de sus columnas particionadas puede estar compuesta de una o multiples
columnas.
Cada una de las columnas particionadas usualmente contiene mltiples filas fsicas.
Las filas fsicas son las que estn estructuradas en disco que el sistema de archivos
de Teradata usa para almacenar el dato basado en la rowid asociada con cada fila
fsica. La primera parte de un rowid indica el nmero de la particin en la que estn
las filas fsicas.
Una nueva fila fsica con format COLUMN podra ser utilizada por una particin
columnar tal como una fila fsica es llamada un container. Este es usado para
implementar el almacenamiento columnar, compresin de cabecera de la fila y
autocompresion por una particin de columna. Esto proporciona una forma
compacta para almacenar una serie de valores de columna particionada.
Alternativamente, una particin por columna podra tener filas fsicas con format
ROW que es utilizada para implementar almacenamiento por fila; es llamada
subrow.

Cada uno de los valores de una particin columnar est en su propia fila fsica.
Usualmente una subrow es amplia (multicolumnar, grandes cadenas de caracteres,
etc.).
Una tabla Columnar es solo otro tipo de tabla que puede ser accesada por una
consulta. Una query simple puede accesar mltiples tipos de tablas.
Para ms detalles ver en la documentacin de Teradata CP.
18.6. CONJUNTO DE COMANDOS BTEQ
Para ms detalle consultar el estndar de BTEQ en EBTEQ
18.7. TERADATA PARALLEL TRANSPORTER (TPT)
Los Operadores Teradata Parallel Transporter (TPT) juegan un rol vital en la alta velocidad
o mejoras de performance para la extraccin y carga de datos en forma nativa con
Teradata. Adems de la interfaz con la base de datos Teradata, algunos de los operadores
de Teradata PT proporcionan acceso a fuentes externas tales como archivos, DBMS
compatibles con ODBC y middleware orientado a mensajes.

TPT tiene 4 tipos de Operadores:
Figura 3. Operadores TPT
1. Operadores Productores (Producer),

2. Operadores Consumidores (Consumer),
3. Operadores Standalone, y
4. Operadores Personalizados por usuario. (estos ltimos no estn permitidos)
A continuacin se detalla cada uno de estos Operadores y en qu escenarios son

recomendados.
18.7.1. OPERADORES PRODUCTORES
Operadores de productores leen datos de un origen y envan los datos a los streams o
flujos de datos TPT. Los flujos de datos son buffers de memoria en que permiten que
los datos se transmitan de un operador de productor a un operador de los
consumidores, sin almacenar los datos en el disco. TPT proporciona los siguientes
operadores productores:
Operador Export: Utiliza multiplea sesiones del protocolo Teradata FastExport para extraer un gran
volume de datos a alta velocidad desde una o ms tablas en Teradata.
Operador Selector SQL: usa una sola session de Teradata SQL para extraer poco volume de datos
desde una tabla en Teradata. El operador selector SQL tiene dos caractersticas que no estan
disponibles en el operador de export. Puede extraer datos en field mode (i.e. columnas en
formato VARCHAR) y pasa los datos al Operador conector de datos con el fin de tener los datos
escritos en formato delimitado a un archivo externo. El operador Selector SQL puede extraer datos
de tipo LOB.
Operador Data Connector: como un operador productor, este operador lee dato en paralelo
desde multiples fuentes tales como archivos, pipes nombrados, mdulos de acceso y sistemas de
cola de mensajes.
Operador FastLoad INMOD Adapter: Lee datos desde cualquier rutina de tipo FastLoad INMOD.
Las rutinas INMOD son escritas por los usuarios y preprocesan los datos antes de que el dato sea
pasado al adaptados FastLoad INMOD.

Operador MultiLoad INMOD Adapter: Lee datos desde un MultiLoad o rutina TPump INMOD. La
rutina INMOD es escrita por el usuario. La rutina INMOD preprocesa la data antes de que sea
enviada al operador MultiLoad INMOD Adapter.
Operador ODBC: Leer datos desde Reads data from many ODBC-compliant DBMS, such as Oracle,
SQL Server, and DB2.
18.7.2. OPERADORES CONSUMIDORES

Operadores consumidores consume datos desde TPT data streams y enva datos a la base
Teradata o archivos. TPT prove de los siguientes operadores consumidores:
Operador de carga (Load operator): Utiliza multiples sesiones del protocol FastLoad para insertar
grandes volmenes de datos a alta velocidad en tablas vacas de Teradata.
Operador de actualizacin (Update operator): Usa multiples sesiones del protocol MultiLoad para
ejecutar Inserts, Updates, Deletes, y Upserts en tablas vacas o pobladas (hasta un mximo de 5
tablas concurrentemente) en la DB Teradata.
Operador de Stream: Utiliza multiples sesiones de Teradata SQL para ejecutar Inserts, Updates,
Deletes y Upserts en tablas vacas o pobladas (hasta un mximo de 127 tablas concurrentemente) en
Teradata sin bloquear las tablas. El bloqueo ocurre a nivel de fila.
Operador SQL Inserter: Utiliza una sola sesin de Teradata SQL para insertar un pequeo volumen
de datos en una tabla vaca o poblada en Teradata. El operador de insert SQL tiene una caracterstica
que no est disponible en los operadores Load, Update, o Stream. Este operador puede cargar datos
LOB.
Operadores Data Connector: Es un operador consumidor, escribe datos a archivos o modulos de
acceso.
Operador FastExport OUTMOD Adapter: Escribe datos a uma rutina Teradata FastExport OUTMOD.
La rutina de tipo OUTMOD es escrita por el usuario. La rutina OUTMOD que post procesa los datos.
18.7.3. OPERADORES STANDALONE
Operadores Standalone realizan funciones nicas que no implican el envo o recepcin de datos a TPT
streams. TPT provee los siguientes operadores standalone:
Operador DDL: Enva requerimientos SQL requests a Teradata para realizar operaciones de configuracin
antes de ejecutar tareas de carga o de exportacin. Por ejemplo, antes de cargar datos usando
operadores de carga Load operator usa el operador DDL para enviar un requerimiento de DROP
TABLE y CREATE TABLE para asegurar que la tabla destino est vaca.
Operador OS Command: Enva commandos al OS. Estos son peligrosos ya qye envan instrucciones al
sistema operativo, iniciar ejecutables o shell scripts. Este tipo de comandos no es permitido para los
desarrollos en LATAM.
Operador Load: Es un operador standalone. Este operador enva un requerimiento a Teradata para
aplicar los datos en la tabla destino. Por ejemplo, cuando no hay mas datos en el paso de stage, usa el
operador Load operator como un operador standalone para aplicar los datos que ya estn en la tabla de
destino.
Operador Update operator: Es un operador standalone, este operador realiza la tarea Delete task a una
nica tabla en Teradata. La tarea Delete realiza el borrado ms rpido que usar una sola instruccin
DELETE de SQL cuando se deben eliminar un gran porcentaje de filas de una tabla, como por ejemplo, la
eliminacin de todas las filas con una fecha de la transaccin antes de una fecha determinada.

18.7.4. OPERADORES PERSONALIZADOS
Los operadores personalizados son operadores desarrollados por el usuario operators. Esta debe ser escrita
en lenguajes de programacin C o C++. Este tipo de desarrollos no estn permitidos para los proyectos en
LATAM.
18.8. COLLECT STATS
En el caso de Collect Statistics Full, se debe considerar
Utilizar en el predicado las Columnas no indexadas.

Todas las tablas con NUSI.
USIs/UPIs, Si es usado en predicados de tipo non-equality (restricciones de rango)
La mayora de los NUPIs.
Estadsticas completas siempre necesitan ser colectadas en las columnas y los ndices relevantes en
tablas pequeas (menos de 100 filas por AMP).
PARTITION para todas las tablas con particiones sometidos a un alza en el crecimiento
PARTITION por columnas de una tabla particionada por fila.
Muestreo Dinmico de AMP
USIs o UPIs si solo es utilizada con predicados de igualdad

NUSIs con una distribucin uniforme de los valores
NUPIs que muestra una distribucin uniforme, y si es usada para joining, ajustarse a la unicidad
supuesta.
Collect Statistics Multicolumna
Grupos de columnas que aparecen a menudo junto con predicados de igualdad. Estas estadsticas se
utilizan para estimar sobre una tabla.
Grupos de columnas usadas para unin o agregaciones, donde hay una dependencia o algn grado
de correlacin entre ellas. Si no se recolectan estadsicas multicolumnas, el optimizador asume una
completa independencia entre los valores de las columnas. Mientras ms haya combinacin de los
valores reales correlacionados, mayor ser el valor de la recoleccin de estadsticas de varias
columnas en esta situacin.
Sugerencias Generales para el Proceso de Coleccin de Estadsticas
Cuando se recogen mltiples estadsticas sobre una tabla por primera vez, el grupo de todas las
estadsticas con las mismas opciones utilizando en una sola peticin.
Despus de la primera vez que se colectan estadsticas, recoger todas las estadsticas se actualizan
en una tabla en una sentencia, y si todos estn siendo renovados, vuelva a recoger a nivel de tabla.
No confe en las estadsticas de resumen copiadas o transferidas de las estadsticas de resumen de
estadsticas
No confe en resumen o particin de estadsticas copiadas o transferidas entre tablas dentro de un
sistema o a travs de l. Recolectarlos nativamente. Esto asegura que los cambios a la configuracin
y otros detalles internos (por ejemplo cuando se dispone de particiones internas) estn disponibles
para el optimizador.
Recolectar las estadsticas de resumen a nivel de tabla despus de los eventos de carga de datos con
el fin de proporcionar al optimizador recuentos de fila de tabla actuales y otros detalles. Esta
operacin se ejecuta muy rpidamente y es compatible con las extrapolaciones ms eficaces de
estadsticas que no eran capaces de ser recolectado despus de las actualizaciones.
No haga drop y luego recolecte estadsticas. Como registro histrico, las estadsticas se pierden
cuando son eliminadas ya que es menos probable que el optimizador se salte la coleccin de
estadsticas o el muestreo.
Nuevas Recomendaciones para Teradata Database 14.10
Esperar a realizar varias recolecciones completas antes de considerar la omisin de estadstica o de

realizar una actualizacin automtica del muestreo.
Utilice la opcin coleccin THRESHOLD , slo para los casos en que hay una necesidad especfica
de reemplazar el valor predeterminado del umbral global.
Considere la recoleccin de estadsticas (proporcionando un nombre) en las expresiones SQL si se
utilizan con frecuencia en las consultas y si hacen referencia a las columnas de una sola tabla.
Para ms detalles de collecting statistics para Teradata Database 14.10, ver el orange book
titulado: Teradata Database 14.10 Statistics Enhancements by Rama Krishna Korlapati.
18.9. LINK DE UTILIDAD

1. Tipos de Datos:
http://developer.teradata.com/doc/connectivity/tdnetdp/14.00/webhelp/DataTypeSectionOverview.html
2. Estndares de Desarrollo LATAM

http://arquitectura.lan.com
3. Documentos Teradata
http://www.info.teradata.com/
4. Teradata Columnar
http://developer.teradata.com/blog/paulsinclair/2011/09/teradata-columnar
http://developer.teradata.com/database/training/rows-versus-columns-why-not-both
5. Recomendaciones para Collect Stats

http://developer.teradata.com/blog/carrie/2014/09/statistics-collection-recommendations-teradata-
database-14-10
6. Recomendaciones a PPI MPPI

http://apps.teradata.com//TDMO/v08n03/Tech2Tech/HandsOn/ImprovePerformance.aspx
7. Recomendaciones a NoPI
https://developer.teradata.com/database/articles/say-yes-to-no-primary-index-no-pi-tables


Estándar de Desarrollo Plataforma Teradata V.4.2-Publicado

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Estándar de Desarrollo Plataforma Teradata V.4.2-Publicado

Hochgeladen von

Copyright:

Verfügbare Formate

LATAM AIRLINES GROUP

Estndar de Desarrollo Plataforma

Arquitectura Corporativa LATAM

Documento - Versin 4.2

Versin Descripcin Autor Fecha Revisado por

Estndar de Desarrollo TERADATA Pgina 1 de 43

Links importantes de documentacin complementaria:

Estndar de Desarrollo TERADATA Pgina 2 de 43

2. ARQUITECTURA DE REFERENCIA ................................................................................. 5

3. DISTRIBUCIN DE ESTRUCTURA DE BASE DE DATOS .............................................. 6

3.1. DISTRIBUCIN DATABASE GENERAL ........................................................................... 6

3.2. DATABASE PARA EXTRACCIONES .............................................................................. 10

4. DEFINICIONES SOBRE EL USO CORRECTO DE TERADATA .................................... 10

5.1. CREACIN DE TABLAS .................................................................................................. 11

5.2. ORDEN DE SCRIPT DE CREACIN DE TABLAS INICIALES ...................................... 12

5.3. ORDEN DE SCRIPT DE TRASVASIJE TABLAS ............................................................ 13

5.4. PRIMARY INDEX DE TABLAS ........................................................................................ 13

5.4.1. VALIDACIN DE DISTRIBUCIN DE DATOS ......................................................... 14

5.4.2. VALIDACIN DE SKEW FACTOR ............................................................................ 14

5.5. TABLAS DE TIPO NOPI ................................................................................................... 16

5.6. SET VERSUS MULTISET ................................................................................................. 17

5.7. COMPRESIN DE TABLAS ............................................................................................ 17

5.8. PARTICIONAMIENTO DE TABLAS ................................................................................ 19

5.9. FALLBACK Y JOURNALIST ........................................................................................... 20

5.10. JOINS DE TABLAS .......................................................................................................... 20

5.11. TABLAS TEMPORALES Y VOLTILES ......................................................................... 21

5.12. ALTER TABLE .................................................................................................................. 21

9. EXPLAIN Y VISUAL EXPLAIN ......................................................................................... 23

10. COLLECT STATISTICS.................................................................................................... 25

11. PROCESOS DE CARGA FRAMEWORK DE ETL/ELT ................................................ 28

11.1. BTEQ ................................................................................................................................. 28

11.2. TERADATA PARALLEL TRANSPORTER (TPT) ............................................................ 28

12. CALIDAD DE DATOS ....................................................................................................... 29

13. MEJORES PRCTICAS TDT ........................................................................................... 30

Estndar de Desarrollo TERADATA Pgina 3 de 43

15. CONFIGURACIN CORRECTA DEL ODBC .................................................................. 33

16. ESTANDAR DE GENERACIN DE USUARIOS. ............................................................ 35

17. NOMENCLATURA DE TABLAS Y CAMPOS DIMENSIONALES................................... 35

18. ANEXOS ........................................................................................................................... 36

18.1. FORMATO GENERAL. SINTAXIS DE CREACIN DE TABLAS ................................... 36

18.2. INDEX WIZARD ................................................................................................................ 37

18.3. SPOOL FANTASMA ......................................................................................................... 37

18.4. USO DE DATA BLOCK SIZE ........................................................................................... 37

18.5. TERADATA COLUMNAR ................................................................................................. 38

18.6. CONJUNTO DE COMANDOS BTEQ ............................................................................... 39

18.7. TERADATA PARALLEL TRANSPORTER (TPT) ............................................................ 39

18.7.1. OPERADORES PRODUCTORES ............................................................................. 40

18.7.2. OPERADORES CONSUMIDORES............................................................................ 41

18.7.3. OPERADORES STANDALONE ................................................................................ 41

18.7.4. OPERADORES PERSONALIZADOS ........................................................................ 42

18.8. COLLECT STATS ............................................................................................................. 42

18.9. LINK DE UTILIDAD .......................................................................................................... 43

Estndar de Desarrollo TERADATA Pgina 4 de 43

En este apartado se muestra la arquitectura de referencia para un Enterprise Data Warehouse

Figura 1. Arquitectura de Referencia BI Enterprise Data Warehouse en Teradata

Las tres capas en Teradata corresponden a:

Estndar de Desarrollo TERADATA Pgina 5 de 43

Layer 3: Corresponde a la capa de acceso y a la base FDM, donde se encuentran la base

3. DISTRIBUCIN DE ESTRUCTURA DE BASE DE DATOS

3.1. DISTRIBUCIN DATABASE GENERAL

Figura 2. Modelo lgico y fsico para la divisin en Bases de Datos en Teradata

Estndar de Desarrollo TERADATA Pgina 6 de 43

Estndar de Desarrollo TERADATA Pgina 7 de 43