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

Continuando con la nueva funcionalidad Automatic Data Optimization. En este segundo ejemplo mostraremos cómo funcionan las políticas ADO para mover un segmento de un tablespace a otro.

Paso 1: Activar el monitoreo.

La activación es igual que en el artículo anterior.  Puedes acceder al articulo desde el link:
Oracle 12c : Automatic Data Optimization (ADO) Parte I

Paso 2: Creación de las tablas EJEMPLO3 y 4.

Para este ejemplo crearemos 2 tablas EJEMPLO3 y EJEMPLO4 y utilizaremos dos tablespaces, uno será el origen (ADOTBS) y el otro el destino (LOW_COST_STORE).

Paso 3: Configuración de los umbrales de uso de tablespaces.

Las políticas de movimiento ADO se basan sobre la cantidad del espacio disponible en el tablespaces donde se encuentra el segmento.  En Oracle 12c existen umbrales definidos por defecto que sirven como base para poder aplicar políticas ADO de movimiento.

Estos umbrales pueden ser consultados desde la vista DBA_ILMPARAMETERS.

Como se observa los umbrales definidos por defecto son 85% de espacio usado y 25% de espacio libre.  Eso quiere decir que si los segmentos, con políticas ADO de movimiento definidas sobrepasan el 85% de uso de los tablespaces, entonces serán candidatos para aplicar las políticas de movimiento definidas.

Cuando son aplicadas las políticas de movimiento, se procede a mover todos los segmentos necesarios al tablespace destino, hasta llegar a cumplir los umbrales definidos en el tablespace origen. 

Para este caso llegar a 25% de espacio libre en el tablespace origen.

En el gráfico podemos apreciar como se ha movido la tabla T1 hasta tener el tablespace origen con 25% libre.  El orden de los segmentos a moverse dependerá de la cantidad de actividad que hayan tenido en el tiempo.

Es posible configurar los umbrales con valores distintos. Para eso utilizamos el paquete DBMS_ILM_ADMIN.

Para nuestro ejemplo cambiaremos el umbral del espacio libre a 20% y el umbral de espacio usado a 80%.

Paso 4: Definición de las políticas ADO.

Una vez definidos los umbrales de uso de los tablespaces, procedemos a definir las políticas ADO de movimiento en los segmentos.

Revisamos cuánto porcentaje de espacio ocupan las dos tablas en el tablespace ADOTBS.

Siendo las únicas tablas en el tablespace ADOTBS y con un 10% de espacio libre, ambos segmentos son candidatos para ser movidos al tablespace destino LOW_COST_STORE.

Paso 5: Evaluación de las Políticas ADO.

Una vez definidas las políticas procedemos a lanzar la evaluación y observar si las tablas se mueven al tablespace destino.

En el ejemplo anterior utilizamos la opción SCOPE_DATABASE donde se evalúan todas las políticas de la base de datos.  Para este ejemplo utilizaremos la opción SCOPE_SCHEMA que sólo evalúa las políticas del esquema al que estamos conectados.

Para eso nos conectaremos con el usuario ADO y lanzaremos la evaluación.

Luego, revisamos si la tarea finalizo correctamente.

Ahora, revisamos el espacio consumido por cada tablespace.

Como se puede observar, una de las tablas fue movida para poder cumplir los umbrales de 20% de espacio libre y 80% de espacio usado en el tablespace ADOTBS.  La tabla elegida fue movida al tablespaces LOW_COST_STORE de acuerdo a la política definida en el paso 4.

Verificaremos qué tabla fue la que se movió.

Como observamos, la tabla que se movió fue EJEMPLO3; eso se debe a que en el paso 2 nosotros creamos y seleccionamos primero la tabla EJEMPLO3 por lo que se define como la de mayor tiempo de inactividad.

Conclusiones.

Como hemos podido observar, en los ejemplos presentados, las políticas ADO nos permiten comprimir segmentos dependiendo de su actividad y mover segmentos dependiendo de cuanto espacio ocupan en un tablespace.   Inclusive es posible combinar las políticas de compresión con las políticas de movimiento para poder hacer más completa la administración del ciclo de vida de la información.

Gracias a la funcionalidad ADO, los administradores de base de datos ya no necesitaran invertir tiempo en tareas manuales como mover segmentos a Storage más económicos o comprimir la información que ya no se modifica.  De esa manera, no sólo se optimiza el tiempo que le dedica el administrador a las bases de datos, sino que además se optimiza de manera automática el espacio utilizado en la base de datos, lo que -en consecuencia- resulta en un ahorro en costos para las empresas.

Espero les pueda servir.