Oracle Live

01/06/2016

CAP 9.- Information Lifecycle Management

Filed under: 1z0-060,Certificaciones — mogukiller @ 11:01 am

ILM gestiona el ciclo de vida de los datos de una empresa. En este capítulo se exponen las mejores de ILM en la version 12c.

Para entender ILM dentro de las bases de datos, tenemos que entender que el almacenamiento no es infinito y tiene asociado un coste. Por lo que se tendra que tener un mecanismo que gestione la historificación de los datos mas antiguos asi como el almacenamiento en discos mas lentos y por lo tanto mas baratos. Entre los mecanismos mas conocidos de ILM estan el particionamiento, la compresion. Es decir segun se vayan haciendo los datos de las particiones mas viejas, las podemos mover a discos mas lentos con un nivel de compresión mayor.

Entre las mejoras de ILM en la 12c tenemos:

1.- Automatic Data Optimization

ADO lleva un registro de los cambios que se producen a nivel de base de datos y elabora mapas de calor. Donde se consideran a los datos como frios, aquellos que se acceden muy rara vez y calientes a los que se acceder frecuentemente. Este seguimiento de los cambios se puede realizar a nivel de fila, segmento o tablespace. Atendiendo a los gradientes de calor se puden definir los niveles de compresión.

ADO puede realizar de forma automática operacion de moviento de datos entre discos lentos o rapidos.

Existen 4 categorias en las que se pueden clasificar los datos y 4 niveles de compresion a utilizar:

  • Active data: Datos activos y muy accedidos. Se puede utilizar Advance Row Compression
  • Frequenly access data: No se actualizan mucho pero se acceden a menudo. Se puede utilizar High Compression.
  • Unfrequenly access data: Ni se actualizan ni se acceden. Se puede utilizar High Compression y moverlo a un disco mas lento.
  • Datos historicos: Se mantienen estos datos por politicas de la empresa. Se puede utilizar Archive Compresion.

Para utilizar ADO tenemos que seguir estos pasos:

  1. Habilitamos los mapas de calor. Se realiza con el parametro heat_map a ON, este parametros se puede modificar también a nivel de sesión. Una vez habilitado la base de datos comenzará a coger estadísticas del acceso de los objetos y sus cambios. Los mapas de calor obtienen la informacion de las modificaciones de un datos se realizan a nivel de bloque, mientras que las estadisticas del acceso a los datos se obtiene a nivel de segmento.
  2. Creamos las politicas de gestion. Es decir definir las condiciones que dispararán una acción. Se pueden definir politicas a nivel de fila, segmento o tablespace. En una politica tenemos que definir el periodo de visualización y la acción a ejecutar despues de ese periodo. Para crear un ADO policy se utiliza como clausulas en CREATE TABLE o ALTER TABLE. Cuando se crea un ADO policy hay que definir los eventos a registrar por ese politica. Estos pueden ser:
    • Low or no data access.
    • No DML on a segment.
    • Object or row creation.
    • Tablespace lleno.

    Una vez definida las condiciones tenemos que definir las acciones a realizar, que bien pueden ser mover a discos mas lentos o compresión de los datos.
    El nivel de ejecucion puede ser:

    • ROW: Sobre politicas basadas en el acceso a los datos.
    • SEGMENTS: Sobre tablas y particiones.
    • GROUP: Sobre un conjunto de objetos dependientes.
    • TABLESPACE: Aplicado a todos los objetos de un tablespace.

    Para crear ADO policies con acciones de compresión se puede elegir entre los siguientes tipos.

    • ROW STORAGE COMPRESS BASIC or ADVANCE: Para comprimir filas que son insertadas y modificadas. ADVANCE se usa para aquellos registros insertados por Direct Path.
    • COLUMN STORAGE COMPRESS FOR QUERY LOW or HIGH: Ofrece un nivel de compresión mayor que el anterior. También llamada Columnar Compression o HCC se utiliza para datos que se acceden con frecuencia pero que a penas se modifican.
    • COLUMN STORAGE COMPRESS FOR ARCHIVE LOW or HIGH: Ofrece un nivel de compresion mayor que los dos anteriores y es aconsejable para datos que rara vez se acceden.

    Para crear ADO policies basadas en el movimiento de datos a discos mas baratos. Este tipo de politicas unicamente se puede aplicar a nivel de segmento. El movimiento de datos se realiza cuando en el tablespace donde se almacena la tabla esta lleno. Una vez se mueva ese objeto su ADO policy se desactiva.

  3. Visualizamos los resultados en las vistas DBA_ILMPOLICIES, DBA_ILMDATAMOVEMENTPOLICIES, DBA_ILM_EVALUATIONDETAILS y  DBA_ILMRESOULTS.
  4. Validamos que se han movido correctamente los segmentos usando la tabla COMPRESSION_STATS$.

ADO no esta soportado en entornos Multitenant.

Se pueden definir varias politicas ADO sobre el mismo segmento. Con la unica condicion que todas las politicas tienen que estar basadas en la misma estadistica. Por ejemplo que no se hay accedido o que no se haya modificado.

Si tengo politicas definidas a nivel de tabla y a nivel de tablespace. La politica a nivel de tabla sobrescribie a la del tablespace.

Las politicas definidas son evaluadas cada 15 min por el MMON, y a nivel de segmento se evaluan cada noche por un job automatico.

El paquete que gestiona las politicas ADO es DBMS_ILM.

Para habilitar o deshabilitar las politicas ADO en un objeto utilizaremos la clausula DISABLE POLICIE <nombre> dentro del ALTER del objeto.

Para favorecer la aplicación de politicas ADO, la versión 12c permite mover dbf online, mientras se estan ejecutando operaciones de DML y DDL sobre los objetos de ese dbf.

2.- Movimientos de datos Online

En la 12c podemos mover datafiles online mientras se estan realizando operaciones DML o DDL sobre los objetos del datafile.

Tambien se pueden hacer operaciones de move, split, merge de particiones y subparticiones de una tabla online. Durante este tipo de operaciones ser realiza automaticamente el mantenimiento de los indices locales y globales, tendremos que indicar en la sentencia la clausula UPDATE INDEX ONLINE.

3.- In database Archiving

Como hemos comentado en el primer punto, uno de los retos de un DBA es como gestionar los datos que ya no se acceden. Una de las opcines que tenemos es comprimir esos datos. Entre las opciones de compresion que tenemos es Hybrid Columnar Compression (HCC). Este tipo tiene un factor de compresión de entre el 15% al 50%. Requiere de la utilizacion de Exadata o ZFS. En HCC los datos se almacenan en columnas.

In database archiving nos permite mantener en la misma base de datos los datos operacionales y los historicos. Limitando el acceso a las aplicaciones unicamente a los datos operacionales. Mientras que los datos historicos estan comprimidos con HCC. Los datos se marcan como historicos a nivel de fila. A nivel de session podemos habilitar el acceso a los datos historicos.

Para habilitar In-database Archiving se hace añadiendo la clausula ROW ARCHIVEL en el CREATE TABLE de la tabla. Se genera una columna oculta en la tabla, ORA_ARCHIVE_STATE, los valores que puede adquirir esta tabla son 0 o 1. Donde 0 son los valores productivos y 1 los historicos.

4.- Temporal Validate

Con esta nueva funcionabilidad podemos hacer que las filas sean visibles o no a la aplicacion atendiendo a dimensiones de tiempo definidas por nosotros. Para activar esta funcionavilidad tenemos que utilizar la clausula PERIOD FOR column_name (start_time, end_time) en la sentencia de CREATE TABLE. Adicionalmente en la tabla hay que crear dos columnas start_time, end_time de tipo date.

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: