martes, 19 de julio de 2016

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;


viernes, 15 de julio de 2016

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');