新机器 ado oracle,Oracle 12c: Automatic Data Optimization (ADO) | Oracle América Latina

Las compresiones Columnares son válidas sobre Storage que puedan soportar esta funcionalidad.

Una vez que se define los 3 aspectos podemos proceder a crear las políticas ADO.

Para este ejemplo creamos 2 políticas diferentes:

Política sobre ADO.EJEMPLO1

Política que se aplica con la condición de “No Modificación” después de 20 días y con compresión Row Advanced

Política sobre ADO.EJEMPLO2

Política que se aplica después de 2 días de creada la tabla y con compresión Row Advanced.

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 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.

FECHA CREACION

FECHA EVALUACION

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.

Comparamos su tamaño antes y después de la evaluación de las políticas ADO.

ANTES

DESPUES

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.

II. MOVIMIENTO DE SEGMENTOS.

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.

El procedimiento es igual indicado en el ejemplo de compresión.

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

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 para aplicar las 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, sobrepasan el 85% de uso de los tablespaces, entonces serán candidatos para moverse al servidor destino.

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 para 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.

Para nuestro ejemplo creamos políticas sobre las tablas EJEMPLO3 y EJEMPLO4.  Ambas tablas se moverán del tablespace ADOTBS al tablespace LOW_COST_STORE

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 ejecutar la evaluación y observar si las tablas se mueven al tablespace destino.

En el ejemplo de compresión 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.  Nos conectamos con el usuario ADO y lanzamos la evaluación.

Luego, revisamos si la tarea finalizo correctamente.

Finalmente, revisamos el espacio consumido por cada tablespace.

Como se puede observar, una de las tablas fue movida al tablespace LOW_COST_STORE para poder cumplir los umbrales del 20% de espacio libre y 80% de espacio usado en el tablespace ADOTBS.

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.

Tener en Cuenta

La funcionalidad ADO no requiere ningún licencia en la base de datos Oracle 12c, sin embargo los tipos de compresiones si requieren un licenciamiento aparte.

Por favor revisar los tipos de licenciamiento antes de utilizar funcionalidades de compresión.

La funcionalidad ADO solo está disponible para bases de datos Non-CDB.  Para la arquitectura Multitenant aun no se encuentra soportado.

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.  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 necesitan 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 resulta en un ahorro en costos para las empresas.

Ing. Jorge Zorrilla. Es un IT Specialist en IBM Perú e instructor de cursos oficiales de certificación Oracle. Amplia experiencia en Base de Datos Oracle y soluciones de Alta Disponibilidad & Contingencia.

Ing. Francisco Riccio. Es un IT Architect en IBM Perú e instructor de cursos oficiales de certificación Oracle. Está reconocido por Oracle como un Oracle ACE y certificado en productos de Oracle Application & Base de Datos.