1. Instalación ODI 12c - Repositorios - Agente

En este post presento un manual de instalación de Oracle Data Integrator ODI 12c, incluyendo el proceso de creación de los repositorios (Repository Creator Utility) y el dominio para la configuración del Agente (con la utilidad de FMW) de ODI.

A continuación se presenta el listado de tareas generales a realizar

• Requisito: Jdk1.8.0_65 (PATH %JAVA_HOME%\bin, JAVA_HOME C:\Program Files\Java\jdk1.8.0_65)
• Requisito: Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit
• Instalación ODI 12.2.1.1.0
• Instalación RCU para crear los repositorios
• Configuración FMW para crear el dominio para el agente

En la siguiente imagen se ven los archivos jar de instalación para ODI 12c, descargados de http://www.oracle.com/technetwork/middleware/data-integrator/downloads/index.html

Ejecutar como administrador una consola CMD, y ejecutar el comando que se ve en la siguiente imagen:

Con este comando se ejecutara el programa de instalación de la herramienta

En la siguiente interfaz omitiremos las actualizaciones automáticas

En el tercer paso se define la ruta donde se realizara la instalación de ODI

En el cuarto paso seleccionamos el tipo de instalación, para este caso se hace el proceso con instalación autónoma o standalone

En el quinto paso se hace una validación de los requisitos para proceder con la instalación

Si la validación es correcta, en la siguiente interfaz omitiremos el envió de información de seguridad y continuamos

En el paso 7 se presenta un resumen del proceso de instalación que se va a realizar

Damos clic en Instalar para que inicie el proceso

Al final se presenta un resumen del proceso realizado con sus versiones y lugares de registro

De esta manera tendremos instalado el ambiente de ODI 12c.

El siguiente proceso es configurar el repositorio Maestro y de Trabajo, utilizando Repository Creator Utility.

Data Mining paso a paso - Visual Studio - Excel

En lo siguientes vídeos presento dos ejemplos sencillos para implementar un modelo de minería de datos, uno utilizando Visual Studio y otro con MS Excel.

1. Ejemplo Minería de Datos con Visual Studio, implementando un proyecto de Analysis Services, utilizando los datos de BikeBuyer de los datos de ejemplo de Adventure Works.

2. Ejemplo de Minería de Datos con MS Excel con el Addin Data Mining pre instalado, y teniendo disponible el servicio de Analysis Services en el equipo, se utilizan los datos de BikeBuyer de los datos de ejemplo de Adventure Works.

Migración LOB BasicFile a SecureFile

En este post se presenta un ejemplo sencillo del proceso de migración de BasicFile a SecureFile.

1.       Creación de la tabla destino y definición de los objetos a trabajar en este ejemplo guía

a.       Definición de la Tabla Origen BasicFile

CREATE TABLE BASICFILE_TAB (

  ID         NUMBER PRIMARY KEY,

  CLOB_DATA  CLOB

)

LOB(CLOB_DATA) STORE AS BASICFILE BASICFILE_LOB;

b.      Creación de la Tabla destino SecureFile

CREATE TABLE SECUREFILE_TAB (

  ID         NUMBER NOT NULL,

  CLOB_DATA  CLOB

)

LOB(CLOB_DATA) STORE AS SECUREFILE SECUREFILE_LOB (

  DEDUPLICATE COMPRESS MEDIUM

);

c.       A continuación, se presenta la definición resumen de las dos tablas:

SELECT OWNER, TABLE_NAME, COLUMN_NAME, SEGMENT_NAME, TABLESPACE_NAME, COMPRESSION, DEDUPLICATION, SECUREFILE

FROM ALL_LOBS WHERE TABLE_NAME IN ('SECUREFILE_TAB','BASICFILE_TAB');

d.      Se insertan datos en la tabla origen:

DECLARE

  l_clob CLOB := RPAD('X', 10000, 'X');

BEGIN

  FOR i IN 1 .. 1000 LOOP

    INSERT INTO BASICFILE_TAB VALUES (i, l_clob);

  END LOOP;

  COMMIT;

END;

e.      Revisamos el tamaño de las tablas en KB:

SELECT SEGMENT_NAME, BYTES/1024

FROM   USER_SEGMENTS

WHERE  SEGMENT_NAME IN ('BASICFILE_LOB','SECUREFILE_LOB');

2.       Se inicia la redefinición de tablas, donde se mapean los campos de las tablas:

BEGIN

DBMS_REDEFINITION.START_REDEF_TABLE ('JMENDOZA', 'BASICFILE_TAB', 'SECUREFILE_TAB', 'ID ID, CLOB_DATA CLOB_DATA');

END;

Revisamos el tamaño de las tablas en KB, luego de la redefinición, que se observa que se hizo la copia de los datos de la tabla origen (BASICFILE) a la tabla destino (SECUREFILE), se redujo significativamente el espacio gracias a las propiedades definidas Deduplicate y Compression:

SELECT SEGMENT_NAME, BYTES/1024

FROM   USER_SEGMENTS

WHERE  SEGMENT_NAME IN ('BASICFILE_LOB','SECUREFILE_LOB');

3.       El siguiente paso es copiar las dependencias de la tabla origen:

DECLARE

ERROR_COUNT INTEGER := 0;

BEGIN

DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS ('JMENDOZA', 'BASICFILE_TAB', 'SECUREFILE_TAB', 1, TRUE, TRUE, TRUE, FALSE, ERROR_COUNT);

END;

4.       Fin de la redefinición, se intercambian los nombres de las tablas, luego de este paso la tabla BASICFILE_TAB estará migrada, tendrá los datos y la definición de SecureFile:

EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE ('JMENDOZA', 'BASICFILE_TAB', 'SECUREFILE_TAB');

SELECT OWNER, TABLE_NAME, COLUMN_NAME, SEGMENT_NAME, TABLESPACE_NAME, COMPRESSION, DEDUPLICATION, SECUREFILE

FROM ALL_LOBS WHERE TABLE_NAME IN ('SECUREFILE_TAB','BASICFILE_TAB');

5.       Teniendo ya migrada nuestra tabla, podemos eliminar la tabla auxiliar:

DROP TABLE SECUREFILE_TAB;

LOB BasicFile vs SecureFile

Desde la versión de base de datos Oracle 8i se definieron los tipos de datos LOB (Large Object Binary) que permite guardar datos desestructurados. Como opción de mejora en el rendimiento y ahorro de espacio en disco desde la versión 11g R1 se dispone de un nuevo tipo de almacenamiento para este tipo de dato, SecureFile.

Para cambiar el tipo de almacenamiento es necesario realizar una migración (proceso que mostraré de manera sencilla en un siguiente post).

LOB (NombreColumnaLOB) STORE AS [SECUREFILE | BASICFILE]

(

       OpcionesColumnaLOB

);

Mejoras en el rendimiento:

• Mejora en caché: El SecureFile tiene un caché de escritura de 4 Mb, lo que mejora la velocidad de escritura de LOBs, cuando no se use esta opción de Cache Oracle 11g utiliza shared_io_pool para las operaciones de SecureFile.
• LOB Centric Network Protocol: Securefiles tienen un nuevo protocolo TNS que permite rápida transmisión de datos LOB, mejorando el rendimiento de lectura y escritura.
• Baja fragmentación: Oracle SecureFile utiliza Chunks continuos en disco (paginas dentro de un segmento) para reducir la fragmentación y de esta manera mejorar la velocidad de las lecturas físicas.

Requerimientos

• Desde Oracle DB 11.1.0.0.0
• Los tablespace de la columna LOB con SecureFiles sera ASSM (Automatic Segment Space Management)
• Para el uso de Data Compression y Deduplication se requiere la licencia Oracle Advance Compression Option de Oracle Enterprise Edition.

Configuración

Se debe revisar la configuración en el motor de base de datos con el siguiente comando:

(SELECT * FROM V$PARAMETER WHERE NAME = 'db_securefile';)

Las posibles opciones a encontrar son las siguientes:

VALOR	EFECTO
PERMITTED	Es el valor por defecto, indica que los LOBs pueden ser creados con SecureFile
ALWAYS	Asegura que todos los LOBs serán de modo SecureFile asi no se especifique, de esta manera será un valor por defecto, teniendo en cuenta que se requiere Tablespace ASSM
PREFERRED	Los campos LOB son creados por defecto como SecureFile (Oracle 12c)
NEVER	Este valor define que no se pueda usar SecureFile, inclusive si se especifica en el momento de la creación del LOB
IGNORE	Todas las cláusulas de almacenamiento y la de SecureFile son ignoradas

BasicFile Vs SecureFile 

A continuación se presenta un ejemplo sencillo para comparar los dos tipos de almacenamiento:

·         Definición de tablas: Se crean 3 tablas para el ejercicio

o   BASIC_TAB: Tabla con almacenamiento BasicFile
o   DEDUP_TAB: Tabla con almacenamiento SecureFile y Deduplicate

o   DEDUCOMP_TAB: Tabla con almacenamiento SecureFile, Deduplicate y Compress

CREATE TABLE BASIC_TAB (

  id         NUMBER,

  clob_data  CLOB

)

LOB(clob_data) STORE AS BASICFILE BASIC_LOB;

CREATE TABLE DEDUP_TAB (

  id         NUMBER,

  clob_data  CLOB

)

LOB(clob_data) STORE AS SECUREFILE DEDUP_LOB(

  DEDUPLICATE

);

CREATE TABLE DEDUCOMP_TAB (

  id         NUMBER,

  clob_data  CLOB

)

LOB(clob_data) STORE AS SECUREFILE DEDUCOMP_LOB (

  DEDUPLICATE COMPRESS HIGH

);

·         En este paso se inserta la misma cantidad de datos en las 3 tablas:

DECLARE

  v_clob CLOB := RPAD('J', 10000, 'J');

BEGIN

  FOR i IN 1 .. 10000 LOOP

    INSERT INTO DEDUP_TAB VALUES (i, v_clob);

    INSERT INTO BASIC_TAB VALUES (i, v_clob);

    INSERT INTO DEDUCOMP_TAB VALUES (i, v_clob);

  END LOOP;

END;

En este proceso de inserción el resumen de duración fue:

• BASIC_TAB: 19.765 segundos
• DEDUP_TAB: 6.047 segundos
• DECUCOMP_TAB: 4.647 segundos

·        Para terminar comparamos el tamaño de los segmentos de cada tabla con la siguiente consulta, donde podemos observar la disminución de tamaño en disco para cada caso:

SELECT SEGMENT_NAME, BYTES/1024 KB

FROM   USER_SEGMENTS

WHERE  SEGMENT_NAME IN ('DEDUP_LOB', 'DEDUCOMP_LOB','BASIC_LOB');