Introdución a ILM

Posted on por

Hoy vamos a ver una pequeña entrada para dumies que sirva de introducción a el ILM

el ILM (information cycle managemet) no es otra cosa que, como se deduce de la traducción del inglés la administración del ciclo de vida de la información, lo que en términos llanos sería el gestionar que hacemos cuando la información crece.

Oracle 12c dispone de dos mecanismos combinados que aportan muchísima potencia para tratar con este tema de arquitecturas, si queréis adentraros mas en este tipo de informacion, deberéis de buscarla en las guías de VLDB (Very Large Databases),pero aqui veremos muy por encima estos dos componentes para , al menos ser conocedores de que existen.
Estos dos componentes solo están soportados en cdb y pdb desde la 12.2

Componentes básicos de ILM

Heat Map

El HEAT MAP recopila en la vista V$HEAT_MAP_SEGMENT información en tiempo real tanto de DML como de acceso a los segmentos de los tablespaces de la base de datos. Esta información la obtiene directamente desde la memoria y es bajada regularmente mediante jobs del scheduler a las tablas que encuentran en SYSAUX.
Se activa mediante el parámetro

 ALTER SYSTEM SET HEAT_MAP=[ON|OFF]

Algo curioso es que se puede activar también a nivel de sesión.

El Heat Map es capaz de trazar la información de uso a nivel de fila y segmento, pero es una funcionalidad enfocada a tratar datos de negocio, por lo que no registra lo que ocurre en SYSTEM o SYSAUX.

Heat Map registra los datos de la siguiente manera:
• Los cambios que hacen modificaciones son registrados a nivel de fila y transmitidos a nivel de bloque.
• Los cambios a nivel de acceso son registrados a nivel de segmento.

ADO (Automatic Data Optimization)

ADO es el segundo componente que vamos a ver hoy, este componente permite a los administradores a crear políticas para hacer compresión y movimiento de datos.

Cuando creas una política la base de datos evalua periodicamente la política y lleva a cabo las tareas necesarias.(también pueden lanzarse a mano)
Las políticas de ADO se pueden especificar a nivel de segmento o fila tanto para tablas como para particiones
importante:Esta funcionalidad necesita de Oracle Advanced Compresion, por lo que es una funcionalidad que requiere de licenciamiento específico

Generando políticas de ILM

Una vez sabemos que podemos trazar la vida de los datos, y que podemos crear políticas que lo gestionen, es cuando llegamos a ver la verdadera potencia de esta funcionalidad.
Vamos a ver dos tipos de políticas bien diferenciados
• políticas que compresión
• políticas de movimiento de datos

Políticas de compresión

Las políticas de compresión cuentan con 4 parámetros
• Nivel tablespace,tabla,partición
• Tipo de Compresion
• Ámbito (cuando hacerlo)
• Clausula temporal

Tipos de compresion

Podemos contar con 4 tipos distintos de compresión.

  • ROW STORE COMPRESS BASIC: Es el básico que se usa al insertar en una tabla usando “advanced compression» (ACO) si no usas directpath, para estas se usa la cláusula ROW STORE COMPRESS BASIC.
  • ROW STORE COMPRESS ADVANCED: En versiones anteriores se llamaba OLTP compression y ha sido renombrado, hace compresión standard para indices y LOW para lob segments .
  • COLUMN STORE COMPRESS FOR QUERY LOW or HIGH: Provee Hybrid columnar compression ( HCC) y mayor grado de compression que el anterior.
    Esta no se puede aplicar a nivel ROW. Funciona bien para entornos donde el rendimiento es crítico y tenemos muchas consultas pero se esperan pocas acciones de DML.
    La compresión de los LOBS es MEDIUM.

  • COLUMN STORE COMPRESS FOR ARCHIVE LOW or HIGH: Provee de Hybrid columnar compression (or HCC) y del máximo nivel de compresion, es conveniente cuando el acceso a los datos es bajo y no se espera ninguna DML.
    Hace COLUMN STORE COMPRESS FOR ARCHIVE LOW or HIGH maps to MEDIUM compression for SecureFile LOB segments . Esta no se puede aplicar a nivel ROW

Los datos pueden ser comprimidos cuando son insertados, actualizados o cargados en una tabla desde un bulk load.

Ambito de la compresion

  • ROW: Se pueden crear basadas en fecha de modificacion
  • SEGMENT:se pueden aplicar a tablas o particiones
  • Group: Si una tabla es elegible para compresión esta compresión se aplica a todos los objetos dependientes ( Lobs,global indexes..) .Solo se aplica a tipo de segmento
  • Tablespace: Se aplica a todos los segmentos del tablespace

Ejemplos

La manera mas sencilla de verlo es viendo algunos ejemplos
Ejemplo de política aplicado a una particion sobre fila (row level compresion después de 90 días)

ALTER TABLE libros  MODIFY PARTITION narrativa 
  ILM ADD POLICY ROW STORE COMPRESS ADVANCED
 ROW 
  AFTER 90 DAYS OF NO MODIFICATION;

Ejemplo de política aplicada a nivel tablespace aplicado a a nivel segmento.

ALTER TABLESPACE DATOS1 DEFAULT
ILM ADD POLICY  ROW STORE COMPRESS ADVANCED
 SEGMENT 
AFTER 30 DAYS OF NO ACCESS;

Ejemplo de política de HCC sobre una partición a nivel segmento

ALTER TABLE libros  MODIFY PARTITION ficcion 
  ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH 
SEGMENT 
  AFTER 12 MONTHS OF NO MODIFICATION;

Políticas de movimientos de datos

Al contrario de las políticas de compresión que pueden llevarse a cabo a nivel de fila o segmento , las de movimiento solamente pueden llevarse a cabo a nivel de segmento.Esto se lleva a cabo mediante la cláusula TIER_TO


ALTER TABLE libros MODIFY PARTITION ensayo 
  ILM ADD POLICY
  TIER TO almacenamiento_barato;

¿Cómo sabe la base de datos cuando hacer este movimiento? La base de datos moverá la particion ensayo de la tabla libroscuando llegue al fullnes thresold
Hay dos parámetros que regulan las políticas de movimiento

  • TBS_PERCENT_USED : Se modfica con DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED,85)
  • TBS_PERCENT_FREE: Se modfica con DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE,25)

Cuando la partición ensayo de la tabla libros pase el umbral marcado en TBS_PERCENT_USED(85%) de ocupación se moverán los datos menos usados ( mas fríos) segmentos al tablespace almacenamiento_barato, esta operacion se detendrá cuando quede libre el umbral marcado en TBS_PERCENT_FREE, en nuestro caso un 25% libre.

En caso de haber politicas a nivel de tabla y tablespace, la de nivel tabla predomina sobre la de tablespace

Como veis, la combinación de HEAT MAP y ADO es muy potente para gestionar bases de datos muy grandes, permitiéndonos tener los datos mas accedimos el almacenamiento rápido, y los menos accedido en almacenamiento mas barato (aunque posiblemente mas lento)

Más información en la sección de documentación de Very large databases de Oracle

Deja una respuesta