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