Introducción.
En la actualidad las empresas tienden a almacenar cada vez más información dentro de sus bases de datos.
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, 10TB, 70TB, etc.
Con bases de datos tan grandes se hace muy difícil la administración del espacio, por lo que es necesario recurrir a la 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. Consta de políticas, procesos y herramientas 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. E
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 mucha utilidad. 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. Utilizamos 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 Automatic Data Optimization - ADO que ayuda a los administradores de bases de datos a manejar de manera 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.
A continuación presentaremos los pasos para poder configurar y ejecutar de manera correcta las políticas ADO. Mostraremos ejemplos de compresión y movimiento de segmentos.
I. 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 realiza mediante el HEAT MAP.
El HEAT MAP es una nueva funcionalidad de Oracle 12c que rastrea de forma automática el uso y modificación de una fila o segmento dentro de la base de datos. Las modificaciones pueden llegar a ser rastreadas a nivel de bloque.
El HEAT MAP te ofrece una vista detallada de como se accede a la data y como los patrones de acceso van cambiando en el tiempo.
Por ejemplo el HEAT MAP puede rastrear el tipo de acceso que tiene una tabla particionada a nivel de partición.
AZUL: Para las particiones altamente modificables y seleccionables.
AMARILLO: Para las particiones altamente seleccionables y poco modificables.
ROJO: Para las particiones nada modificables y poco seleccionables.
Toda la información del HEAT MAP se almacena en el tablespace SYSAUX.
Para activar el HEAT MAP lanzamos el siguiente comando:
Paso 2: Creación de las tablas EJEMPLO1 y EJEMPLO2.
Procederemos a crear el usuario y las tablas que serán evaluadas por 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.
Procedemos a insertar datos en 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 la tabla EJEMPLO2.
Paso 4: Revisión del monitoreo de las tablas.
Con el HEAT MAP activado en el paso 1, podemos revisar las estadísticas de las actividades en las tablas.
Podemos revisar las siguientes vistas:
- DBA_HEAT_MAP_SEGMENT
- DBA_HEAT_MAP_SEG_HISTOGRAM.
En la imagen podemos observar que la vista DBA_HEAT_MAP_SEGMENT nos muestra la siguiente información:
- Fecha de la última modificación.
- Fecha de la última lectura del segmento.
- Fecha del último Full-Scan en la tabla.
- Fecha de la última consulta por índice.
En la vista DBA_HEAT_MAP_SEG_HISTOGRAM podemos revisar:
- Fecha del último monitoreo.
- Si en la tabla se ha hecho modificaciones, lecturas Full-Scan y lecturas por índices.
Paso 5: Creación de las políticas ADO.
Una vez tomadas las estadísticas, podemos proceder a crear las políticas ADO de 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:
| CONDICIÓN | DESCRIPCIÓN |
| Creación | Creación del segmento |
| No Modificación | No ejecución de DMLs o ALTERs sobre el segmento. |
| Bajo Acceso | Poco acceso a la información del segmento |
| No Acceso | La información ya no es consultada por ninguna sentencia SQL |
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:
| COMPRESIÓN | DESCRIPCIÓN |
| Row Basic | Compresión básica desde 9i |
| Row Advanced | Compresión conocida en versiones anteriores como compresión OLTP. |
| Column For Query LOW y HIGH | Muy útil cuando la información es aún consultada pero ya no modificada |
| Column For Archive LOG y HIGH | Muy útil para información que ya no se consulta y sólo se encuentra almacenada por temas regulatorios |
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.
588
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
