Oracle Database 12c: In-Memory (Parte II)

Por Joel Perez , Mahir M. Quluzade (OCE) & Sebastián D'Alessandro (OCE)
Publicado en Julio 2015

Este artículo es la continuación de Oracle Database 12c: In-Memory (Parte I), donde nos adentramos a esta nueva y poderosa funcionalidad del manejador de base de datos que fue incluida en la versión 12 Realease 1 (12.1.0.2).

Habilitación de “In-Memory Column Store”

A partir de Oracle Database 12c Release 1 (12.1.0.2) se agregaron seis nuevos parámetros de inicio que comienzan con el prefijo INMEMORY_ para controlar la funcionalidad de In-Memory (Listado de código 1).  Adicionalmente el nuevo parámetro OPTIMIZER_INMEMORY_AWARE activa o desactiva todas las mejoras del optimizador basado en costos para “In-Memory”. El valor predeterminado es TRUE. Establecer  el parámetro en FALSE hace que el optimizador ignore la propiedad in-memory de las tablas durante la optimización de  sentencias SQL.

Listado de código 1: Parámetros de inicio para  In-Memory

SQL> show parameter  inmemory

NAME                                              TYPE            VALUE
------------------------------------------------- --------------  --------
inmemory_clause_default                           string                     
inmemory_force                                    string          DEFAULT
inmemory_max_populate_servers                     integer         1
inmemory_query                                    string          ENABLE
inmemory_size                                     big  integer    0
inmemory_trickle_repopulate_servers_percent       integer         1
optimizer_inmemory_aware                          boolean         TRUE
    

“INMEMORY_SIZE” establece el tamaño del área de In Memory  para el In-Memory Column Store (IM column store)  de una instancia de base de datos. El valor por defecto es 0, lo cual significa que IM column store  no esta siendo utilizado, ya que la característica In-Memory  no esta habilitada de forma automática. Tenemos que cambiar el parámetro de inicialización “INMEMORY_SIZE” a una cantidad distinta de cero para poder habilitar “IM Column store”. Si desea que esta cantidad no sea tomada del tamaño de SGA actual, entonces debe ampliar el tamaño de la SGA teniendo en cuenta el valor del parámetro INMEMORY_SIZE. De esta manera, si se está utilizando Gestión de Memoria Automática (AMM), se deberá  ampliar el valor del parámetro MEMORY_TARGET o en el caso que se esté utilizando Gestión Automática de Memoria Compartida(ASMM), entonces tendrá que hacerlo con el valor del parámetro SGA_TARGET.
En nuestro caso estamos usando AMM con un máximo de memoria target de 1024MB y estamos estableciendo el parámetro INMEMORY en 300MB (Listado de código 2). 

Listado de código 2:Habilitar la funcionalidad de In-Memory

SQL> alter system set memory_max_target=1324M scope=spfile; System altered.

SQL>alter system set inmemory_size=300M  scope=spfile; System altered.

SQL>shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  1392508928 bytes
Fixed Size                2924304 bytes
Variable Size             1040187632 bytes
Database Buffers          16777216 bytes
Redo Buffers              13852672 bytes
In-Memory Area            318767104 bytes
Database mounted.
Database opened.
 SQL> alter system set memory_target=1324M;
System altered.

SQL> select * from  v$sga;

NAME                  VALUE      CON_ID
--------------------  ---------- -------
Fixed Size            2924304          0
Variable Size         939524336        0
Database Buffers      117440512        0
Redo Buffers          13852672         0
In-Memory Area        318767104        0
 


Populación de In-Memory
Solo los objetos a los cuales se le especifique el atributo INMEMORY en la sentencia DDL serán cargados en el área de IM Column Store.



Figura 3:
Clausula INMEMORY

Se puede definir la cláusula INMEMORY a:

  • Tablas enteras
  • Grrupos específicos de columnas
  • Vistas materializadas
  • o particiones de una tabla (Listado de código 3).

Listado de código 3: IM ClomunStore para tablas y Vistas Materializadas

SQL> conn  pekinuser/pekinuser
Connected.
   
SQL> create table TBIM1 (id number, d date) INMEMORY; 
Table created.

SQL> create table TB1  as select level as id from dual connect by level<=1e6;
Table created.

SQL> create  materialized view MVIM_TB1 INMEMORY as    
2 select * from tb1;

Materialized view  created.

SQL> select  table_name, inmemory from user_tables;

TABLE_NAME          INMEMORY
------------------  ----------------
TBIM1               ENABLED
TB1                 DISABLED
MVIM_TB1            ENABLED
   

Sin embargo, se puede activar IM Column Store a nivel tablespaces. De este modo, todas las tablas y vistas materializadas en dicho “Tablespace” son automáticamente habilitadas para “IM column store”. También se puede habilitar IM Column store para todos los objetos y “Tablespaces” posteriormente a su creación con la instrucción DDL: ALTER ….(Listado de código 4).

Listado de código 4:IM Column Store para tablespaces

SQL> create tablespace  TBSIM1 datafile '/u01/app/oracle/oradata/prmdb/tbsim1.dbf' size 10M default  inmemory;
Tablespace created.

SQL> select  tablespace_name, def_inmemory from user_tablespaces;

TABLESPACE_NAME                 DEF_INME
------------------------------  --------
SYSTEM                          DISABLED
SYSAUX                          DISABLED
UNDOTBS1                        DISABLED
TEMP                            DISABLED
USERS                           DISABLED
CMDATA                          DISABLED
TBSIM1                          ENABLED

SQL> create table  TBIM2 as select * from dba_objects;  
Table created.

SQL> alter table TBIM2  INMEMORY;
Table altered.

SQL> create tablespace  TBSIM2 
2   datafile '/u01/app/oracle/oradata/prmdb/tbsim2.dbf' size 10M ;
Tablespace created.

SQL> alter tablespace TBSIM2 default INMEMORY;
Tablespace altered.


Cuando se activa “IM Column Store” a nivel tablespaces, la funcionalidad es habilitada por defecto solo para los nuevos objetos creados en el tablespace. En otras palabras, no se hace efectiva para objetos que ya residían en dicho “Tablespace”.
Los objetos cargados en el área de “In-Memory” son almacenados en dos “pools”: un pool de tamaño de 1 MB -IMCU(“In-Memory CompressionUnits”) utilizado para almacenar los datos de columnas con el formato real y un pool  de 64KB -SMU(“SnapshotMetadataUnits”) utilizado para almacenar metadatos sobre objetos cargados (“tranasactionjournal”). Podemos  verificar la cantidad de memoria disponible para cada poolpor medio de la vista V$INMEMORY_AREA (Listado de código 5). 

Listado de código5: Cantidad de memoria disponible en área de In-Memory

SQL> select * from  v$inmemory_area;
   
POOL                        ALLOC_BYTES USED_BYTES POPULATE_STATUS
--------------------------  ----------- ---------- ----------------
1MB POOL                    250609664   6291456               DONE
64KB POOL                   46137344    262144                DONE
     

Parámetros de INMEMORY

Podemos especificar como serán almacenados los datos de la tabla en el área de memoria de IM Column store utilizando los parámetros de IM. Estos parámetros son de cuatro tipos:

  • Compresión de memoria (Memory Compression)
  • Prioridad (Priority)
  • Distribución (Distribute) 
  • & Duplicación(Duplicate)

Compresión de memoria (inmemory_memcompress): esta cláusula especifica el método de compresión para los datos almacenados en área de IM Column store. El valor predeterminado es NOMEMCOMPRESS, significa que no comprime los datos en memoria. Para indicarle a la base de datos que comprima los datos en memoria, especifique MEMCOMPRESS FOR seguido por alguno de los siguientes métodos (Tabla 1):

Tabla 1: Métodos de Compresión

Compresión(inmemory_memcompress)

Descripción

DML

Este método esta optimizado para operaciones DML y realiza poca o ninguna compresión de datos.

QUERY LOW 

Este método comprime los datos In-Memory al mínimo (a excepción de DML) y brinda como resultado el mejor rendimiento para consultas. QUERY LOW es el valor por defecto.

QUERY HIGH 

Este método comprime los datos in-memory más que QUERY LOW pero menos que CAPACITY LOW.

CAPACITY LOW 

Este método comprime los datos in-memory  más que QUERY HIGH, pero menos que CAPACITY HIGH.Se tiene como resultado un excelente rendimiento para consultas.

CAPACITY HIGH 

Este método es el que más comprime los datos in-memory y brinda como resultado buena performance en consultas.


Recomendación
: Puede utilizar Oracle Compression Advisor –DMBS_COMPRESSION es un paquete PL/SQL  que permite realizar una estimación de la tasa de compresión que puede ser usada por MEMCOMPRESS.

Listado de código 6: Usando la cláusula MEMCOMPRESS

SQL> alter table TBIM1  inmemory memcompress for capacity high;
Table altered.

SQL> alter table  MVIM_TB1 inmemory memcompress for capacity low; 
Table altered.

SQL> alter table TBIM2  inmemory memcompress for query low;
Table altered.

SQL> create table TBIM3 (n  number,v varchar2(1)) 
2   inmemory memcompress for query high; 
Table created.

SQL> select  table_name, inmemory, inmemory_compression from user_tables;

TABLE_NAME        INMEMORY     INMEMORY_COMPRESS
-------------     ------------ --------------------
TBIM1             ENABLED      FOR CAPACITY HIGH
TB1               DISABLED
MVIM_TB1          ENABLED      FOR  CAPACITY LOW
TBIM2             ENABLED      FOR  QUERY LOW 
TBIM3             ENABLED      FOR  QUERY HIGH NONE
5 rows  selected.


Prioridad
(inmemory_priority): esta cláusula especifica la prioridad de carga de datos en el área de memoria deI “IM column store”. Se puede especificar la prioridad de datos en “IM column store” con las siguientes clausulas PRIORITY (tabla 2):

Tabla 2: Prioridades de In-Memory

Prioridad (inmemory_priority)

Descripción

NONE 

Oracle Database controla en que momento los datos de la tabla son cargados en IM column store. La carga de los datos puede ser postergada  si la memoria requerida es necesitada para otras tareas. También, Oracle Database puede cargar algunas columnas , pero no otras, en el área de IM column store. NONE es el valor por defecto.

LOW 

Los datos de la tabla son cargados antes que los datos de objetos de base de datos con prioridad NONE y después que los objetos con prioridad MEDIUM, HIGH, o CRITICAL.

MEDIUM 

Los datos de la tabla son  cargados en el IM column store antes que los datos de objetos con prioridad NONE o LOW y después de los objetos con prioridad HIGH o CRITICAL.

HIGH 

Los datos de la tabla son  cargados en el IM column store antes que los datos de objetos con prioridad NONE, LOW o MEDIUM y después de los objetos con prioridad CRITICAL.

CRITICAL 

Los datos de la tabla son  cargados en el IM column store antes que los datos de objetos con prioridad NONE, LOW, HIGH o CRITICAL.


A continuación se verán algunos ejemplos del uso de la clausula PRIORITY : Listado de código 6

Listado de código 6: Usando la cláusula PRIORITY

SQL> alter table TBIM1 inmemory priority low; 
Table altered.

SQL> alter table TBIM2  inmemory priority high;
Table altered.
 
SQL> create table TBIM4 (n  number, v varchar2(1), d date)
2   inmemory memcompress for dml priority low;
Table created.
 
SQL> select table_name,  inmemory, inmemory_compression,inmemory_priority
2   from user_tables;
 
TABLE_NAME       INMEMORY    INMEMORY_COMPRESS   INMEMORY_PRIORITY
------------ ------------ --------------------  ------------------
TBIM1             ENABLED        FOR QUERY LOW                 LOW
TB1              DISABLED
MVIM_TB1          ENABLED    FOR CAPACITY  LOW                NONE
TBIM2             ENABLED        FOR QUERY LOW                HIGH
TBIM3             ENABLED      FOR  QUERY HIGH                NONE
TBIM4             ENABLED             FOR  DML                 LOW
6 rows  selected.
 

Las cláusulas DISTRIBUTE (inmemory_distribute) y DUPLICATE (inmemory_duplicate) sólo se usan con Oracle Real ApplicationCluster (RAC). Usted puede leer más sobre estas cláusulas en la próxima parte de esta serie de artículos.

Restricciones en IM
IM Column Store tiene algunas restricciones:

  • Tablas Organizadas por Indices  (IOTs) y Tablas de Cluster no pueden ser cargadas en IM Column Store.
  • Los tipos de datos LONG (obsoleto desde Oracle Database 8i) y tipo de datos Out Line LOBs también no son soportados en el IM Column store.
  • Los objetos con un tamaño menor a 64kb no son cargados en memoria.

También puede utilizar IM column store en una base de datos standby lógica pero IM Column Store no podrá ser utilizada en una instancia standby de “Active Data Guard” de liberación actual. 

Como siempre esperamos que haya sido de utilidad la informacion de este articulo y nos vemos en la proxima entrega.


Joel Pérez es un experto DBA (Oracle ACE Director, OCM Cloud Admin. & OCM11g) con más de 15 años de experiencia real en el mundo de tecnología Oracle, especializado en diseño e implementación de soluciones de: Cloud, Alta disponibilidad, Recuperación contra desastres, Upgrades, Replicación y toda área relacionada con bases de datos Oracle. Consultor Internacional con trabajos, conferencias y actividades relacionadas en más de 50 países alrededor del mundo. Habitual Orador en eventos Oracle alrededor del mundo como: OTN LAD, OTN MENA, OTN APAC y más. Joel se ha caracterizado siempre por ser un pionero en materia de tecnología Oracle desde los inicios de su carrera siendo el primer latinoamericano en ser nombrado "OTN Expert" en el año 2003, uno de los primeros Oracle ACE en el programa ACE en el año 2004, unos de los primeros OCP Cloud en el mercado global en el año 2013 y como uno de los mayores logros de su carrera, recientemente en el 2014 fue honorificado como uno de los primeros "OCM Database Cloud Administrator" del mundo. En la actualidad Joel Pérez esta radicado en el continente de Asia con base en Beijing, China llevando a cabo operaciones profesionales como “Chief Technologist & MAA, HA Arquitect” para Yunhe Enmo (Beijing) Technology Co. Ltd.
http://education.oracle.com/education/otn/JoelPerez.htm 

Mahir M. Quluzade es un Senior DBA con mas de 10 anos de experiencia en bases de datos Oracle con especial foco en "High Availability" & "Disaster Recovery Solutions (RAC, Data Guard, RMAN,…)". Mahir actualmente trabaja en el "Central Bank of the Republic of Azerbaijan". El es OCP DBA. Mahir es frecuente orador en el "Azerbaijan Oracle User Group (AZEROUG)".

Sebastián D'Alessandro es un Senior DBA con más de 12 años de experiencia en tecnología Oracle, focalizado principalmente en seguridad de base de datos, soluciones de alta disponibilidad, disaster recovery y virtualización. Actualmente desarrolla su actividad como consultor e instructor de manera independiente.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.