Oracle 12c : Automatic Data Optimization (ADO) Parte I

En la actualidad las empresas tienden a almacenar cada vez más información dentro de sus bases de datos.  Eso se debe a que cada día se van encontrando nuevas fuentes de información que permiten a los altos ejecutivos tomar mejores decisiones sobre como optimizar la productividad de las empresas.

Por ejemplo, hoy en día, es importante saber todo sobre los clientes.  No sólo saber los datos del cliente, sino también es importante saber su opinión, a qué sector pertenecen, el tipo de consumo que tienen, las ofertas que más consumen, etc. Así, cada día las variables van aumentando y en consecuencia la cantidad de información que se puede obtener y almacenar.

Como administradores de bases de datos, siempre hemos tenido el reto de tratar de almacenar la mayor cantidad de información que las empresas necesitan y al mismo tiempo optimizar el espacio consumido dentro de las bases de datos para poder reducir costos de infraestructura.

Muchos de nosotros hemos tenido que lidiar con bases de datos de 1TB, 5TB, 10TB. En mi experiencia personal, con bases de datos de hasta 70TB. Con bases de datos tan grandes se hace muy difícil la administración del espacio, por lo que es necesario recurrir a una estrategia ILM.

ILM - Information Lifecycle Management.

ILM es una estrategia eficiente que te permite administrar de manera óptima la información del negocio a lo largo de su ciclo de vida.  Ésta consta de políticas, de procesos y de herramientas que se utilizan para poder alinear el valor de la información a una infraestructura de TI adecuada y rentable; desde el momento en que la información es generada hasta su disposición final.

Una de las formas de poder implementar ILM es definir un ciclo de vida para la información en la base de datos.  El más recomendado es el ciclo de vida de 4 etapas:

1ra Etapa - Data Activa: En esta etapa la información ha sido recientemente ingresada a la base de datos y es altamente consultada y modificada.

2da Etapa - Data Consulta: En esta etapa la información sigue siendo altamente consultada pero ya no es modificada.

3ra Etapa - Data Antigua: En esta etapa la información tiene ya bastante tiempo almacenada y es poco consultada.

4ta Etapa - Data Expirada: En esta etapa la información ya no es de utilidad debido a su antigüedad. Sin embargo se debe mantener almacenada por exigencia de los organismos reguladores propios de cada país.

En este gráfico se puede apreciar las etapas por las que pasa la información y el volumen de datos que ocupa cada etapa.

Para poder manejar de manera correcta el ciclo de vida de la información tenemos que apoyarnos en procesos manuales creados por los administradores de bases de datos utilizando funcionalidades como particionamiento, transport tablespace, online redefinition, entre otros.

La versión Oracle 12c ha llegado con muchos cambios y nuevas funcionalidades. Una de ellas es el Automatic Data Optimization - ADO que ayuda a los administradores de bases de datos a poder manejar de manera más automática el ciclo de vida de la información.

Automatic Data Optimization – ADO.

ADO es una nueva opción de Oracle 12c que consiste en la creación de políticas para comprimir y/o mover un segmento dependiendo de su actividad dentro la base de datos. Las políticas son evaluadas y ejecutadas sin intervención manual del DBA.

Dentro de la funcionalidad ADO tenemos dos actividades: compresión de segmentos y movimiento de segmentos. A continuación presentaremos los pasos para poder configurar y ejecutar de manera correcta las políticas ADO, mostrando ejemplos de ambas actividades:

COMPRESIÓN DE SEGMENTOS.

Primero mostraremos un ejemplo de cómo se configura las políticas ADO de compresión de segmentos:

Paso 1: Activar el monitoreo.

Para que ADO pueda evaluar la actividad de la información en la base de datos, es necesario activar su monitoreo.  El monitoreo de la actividad se basa en un HEAT MAP que te permite rastrear actividades como:

- Acceso a nivel de segmento.

- Modificación a nivel del bloque y segmento.

Estas estadísticas son almacenadas de manera permanente en el tablespace SYSAUX.

Para activar el monitoreo lanzamos el siguiente comando:

Paso 2: Creación de las tablas EJEMPLO1 y 2.

Procederemos a crear el esquema y las tablas que serán evaluadas en las políticas ADO.  Para efectos del ejemplo le daremos al usuario el rol DBA.

Paso 3: Inserción, consulta y modificación de las tablas EJEMPLO1 y 2.

Procedemos a insertar datos a cada tabla para que se pueda apreciar la compresión. Además de realizar acciones sobre cada tabla.

Tener en cuenta que en la tabla EJEMPLO1 se ingresarán más datos que en EJEMPLO2.

Paso 4: Revisión del monitoreo de las tablas EJEMPLO1 y 2.

Ya que activamos el HEAT MAP en el paso 1, podemos observar las estadísticas de la actividad de las tablas.  Revisemos las siguientes vistas:

• DBA_HEAT_MAP_SEGMENT
• DBA_HEAT_MAP_SEG_HISTOGRAM

Como se observa en la imagen, la base de datos ha guardado la fecha del último full scan que se ha realizado a las tablas. El HEAT MAP también almacena la fecha de la última modificación y de la última lectura del segmento.

Paso 5: Creación de las políticas ADO.

Una vez tomadas las estadísticas, podemos proceder a crear las políticas ADO para la compresión.

Para poder crear una política se debe tener en cuenta 3 aspectos:

1. ¿Que condición debe de darse para aplicar la política? 

 Se puede elegir entre las siguientes condiciones:

-        Creación: Creación del segmento.

-        No Modificación: Que no se hayan ejecutado DML sobre las filas o ALTER sobre el segmento.

-        Bajo Acceso: Poco acceso a la información del segmento.

-        No Acceso: Que la información ya no es consultada por ninguna sentencia SQL.

La métrica de bajo acceso al segmento se basa en las estadísticas de full_scan, modificación de datos y lookup_scan; las cuales se les asigna un peso dependiendo del tipo de compresión que se define en la política.

2. ¿Cuánto tiempo debe de pasar después de que se dio la condición? 

Debemos definir la cantidad de días, meses o años que debe de pasar después que se ha presentado la condición definida en el punto1.

3. ¿Qué tipo de compresión se va a aplicar?

Se puede aplicar los siguientes tipos de compresión:

-        Row Basic: Compresión básica desde 9i.

-        Row Advanced: Compresión conocida anteriormente como compresión OLTP.

-        Column For Query LOW y HIGH: Compresión Columnar de mayor nivel que las anteriores. Muy útil cuando la información es aún consultada pero ya no modificada.

-        Column For Archive LOG y HIGH: Compresión Columnar, es el mayor nivel de compresión.  Muy útil para información que ya no se consulta y sólo se encuentra almacenada por temas regulatorios.

Para este ejemplo definiremos la compresión Row Advance ya que las compresiones columnares necesitan de un Storage especial.

Existe un aspecto más a tomar en cuenta, y es definir sobre qué objeto se validará la política ADO.  Los objetos pueden ser:

- Fila.

- Segmento.

- Segmento y LOBs.

- Segmentos en un tablespace.

Para el objetivo de este ejemplo y este artículo, tomaremos como base sólo las políticas sobre segmentos.

Una vez definidos cada aspecto, procedemos a crear una política a cada tabla EJEMPLO.

Política de No Modificación.

Política desde la Creación.

Es posible revisar las políticas creadas consultando las vistas DBA_ILMPOLICIES y DBA_ILMDATAMOVEMENTPOLICIES.

Antes de evaluar las políticas revisamos el peso de cada tabla.

Paso 6: Evaluación de las políticas ADO.

Para poder evaluar la primera política modificaremos el HEAT MAP ingresando una fecha de modificación de más de 20 días atrás.  Este paso es sólo para demostrar el funcionamiento de las políticas, no debe aplicarse en bases de datos de producción.

Debido a que la consulta hecha inicialmente en la tabla EJEMPLO1 aún está en memoria, procedemos a reiniciar la base de datos para limpiar todas las estadísticas en memoria y sólo quedarnos con las estadísticas sembradas.

Observamos la definición sembrada en el HEAT MAP.

Para poder evaluar la segunda política, esperaremos 2 días para que la política pueda hacer efecto.

Por defecto, las políticas sobre segmentos son evaluadas durante la ventana de mantenimiento de la base de datos.  Otra forma de evaluar las políticas es mediante el paquete DBMS_ILM de la siguiente manera:

Una vez finalizada la evaluación, podemos ver si la tarea finalizó correctamente consultando la vista DBA_ILMTASKS.

También podemos verificar qué acciones se tomaron sobre las tablas durante la evaluación.

Se consulta la vista DBA_ILMEVALUATIONDETAILS.

Paso 7: Revisión de resultados.

Finalmente revisamos si las tablas se han comprimido comparando su tamaño antes y después de la evaluación de las políticas ADO.

ANTES

DESPUÉS

Como se puede apreciar ambas tablas han sido comprimidas después de la evaluación de las políticas ADO.  Una tabla pesa más que la otra debido a la cantidad de registros que tienen ambas tablas.

En el siguiente articulo seguiré explicando las diferentes configuraciones que tiene ADO.

Espero les sirva.