Gestión de UNDO

Cada vez que una transacción se ejecuta, Oracle le asigna un segmento UNDO, no es posible que una transacción esté asignado a múltiples segmentos undo, pero si es posible que varias transacciónes estén asignadas en un mismo segmento undo. Si una transacción llena un segmento undo, Oracle añadirá automáticamente otro extent al segmento.

Oracle creará tantos segmentos undo como se necesite, de igual forma cuando no sean necesarios los eliminará.

Cada vez que esta transacción actualiza la información de algún bloque de datos ya sea de tablas o índices, escribe en los bloques del segmento UNDO que se asignó al principio, con la información necesaria para poder realizar un ROLLBACK en el caso de que fuera necesario.

Si el tablespaces UNDO estuviera completamente lleno de datos deshacer y se iniciase una transacción, Oracle está obligado a asignarle un segmento UNDO, pero al no haber disponibles realizará una de las siguientes operaciones.

Localizar los datos más viejos que ya estén confirmados (ya no son necesarios) y asignárselo. Si no existe datos confirmados para poderlos asignar, extenderá un segmento UNDO para podérselo asignar. Por lo tanto la gestión de los segmentos UNDO se realiza de forma automática. El trabajo del DBA es:

• Averiguar la naturaleza y volumen de la actividad de la Base de Datos.

• Dar valor a ciertos parámetros de la instancia según los límites calculados.

• Ajustar el tamaño del tablespace UNDO, según las máximas previsiones.

Los datos undo pueden ser clasificados en 3 tipos:

• Datos undo Activos: Los datos undo podrían ser necesarios para deshacer una transacción en progreso. Estos datos nunca pueden ser sobrescritos, hasta que la transacción se complete con un COMMIT o un ROCKBACK.

• Datos Undo Expirados: Son datos undo de transacciónes que ya han realizado un COMMIT, por lo que los datos ya están en el disco y no son necesarios mantenerlos. Estos datos pueden ser sobrescritos si Oracle necesita el espacio para otra transacción activa.

• Datos Undo Inexpirados: Estos datos no están ni activos ni expirados, la transacción ha realizado un commit, pero los datos undo podrían ser necesario para una posible lectura. Puede ser sobrescrito si hay escases de espacio libre en el segmento undo.

Para saber que segmento ha sido asignado a cada transacción, se puede consultar la vista V$TRANSACTION que tiene columnas de unión con la vista V$SESSION y DBA_ROLLBACK_SEGS.

La vista V$ROLLSTAT, da información en el tamaño de los segmentos. En el DBA_ROLLBACK_SEGS para distinguir un segmento rollback de un segmento undo, se mira el prefijo _SYSMU que son puesto al nombre de segmentos undo. Parámetros para manejar undo y garantía de retención.

Hay 3 parámetros para controlar el undo:

• UNDO_MANAGEMENT: Por defecto esta en AUTO, si se pone en MANUAL Oracle no usara segmentos undo en absoluto. El parámetro es estático por lo que es obligatorio reiniciar la instancia para que su modificación se haga efectiva.

• UNDO_TABLESPACE: Cuando UNDO_MANAGEMENT está configurado a AUTO, hay que indicar que tablespace undo va a utilizar y para ello hay que informar el parámetro

• UNDO_TABLESPACE: El tablespace tiene que ser creado como tablespace undo, no puede asignarse un tablespace de datos.

• UNDO_RETENTION: El valor que se indica en este parámetro son los segundos que Oracle va a intentar dejar almacenados los datos undo antes de pasarlos a expirado o inexpirado. Si no se fija este parámetro, o está a cero, Oracle siempre intentará dejar almacenados estos datos todo el tiempo que se pueda. Esto es importante porque con el comando Flashback, podemos deshacer una operación DML de forma rápida usando estos datos undo, por lo que cuanto más tiempo estén almacenados más se podrá retroceder los cambios usando el undo.

Aunque este parámetro esté configurado, si al crear el tablespace undo no se garantiza la retención, Oracle no respetará este tiempo de garantía si necesita espacio para otras transacciónes:

• ALTER TABLESPACE nombre_tablespace RETENTION GUARANTEE

La garantía de undo retention, significa que los datos undo nunca serán sobrescritos hasta el tiempo indicado en el UNDO_RETENTION.

Este atributo puede ser especificado en el tiempo de creación del tablespace, o habilitarlo después. Una vez que está activado el tablespace undo para que la garantía de retención se cumpla, todas las consultas completaran con éxito, a condición de que ellas terminen dentro del tiempo de UNDO_RETENTION, nunca se producirá “foto demasiado vieja”. La desventaja es que las transacciónes pueden fallar por falta de espacio undo.

Si el parámetro UNDO_RETENTION ha sido fijado y el archivo que forma el tablespace undo es configurado como autoextend, entonces Oracle aumentará el tamaño del archivo de datos automáticamente si es necesario, si no fallará.

Cuando se crea un tablespace undo los ficheros de datos por defecto no serán autoextend. Pero si la base de datos es creada con DBCA, el tablespace undo será autoextend por defecto, con tamaño máximo ilimitado.

No es posible crear segmentos en tablespaces undo, se crean automáticamente. Un tablespace undo es creado con 10 segmentos undo. Si hace falta será añadidos más de forma automática.

Una base de datos puede tener muchos tablespace undo, pero solo uno puede ser utilizado (online), lo demás estarán offline. Hay dos excepciones a esto:

• En una base de datos RAC, cada instancia que abre una base de datos debe tener su propio tablespace undo. Esto puede ser controlado fijando el parámetro UNDO_TABLESPACE a un valor diferente para cada instancia. Cada instancia tendrá el undo segment online.

• Si un tablespace undo es cambiado por el parámetro UNDO_TABLESPACE, cualquier segmento en el tablespace antiguo que apoyaban una transacción en el momento del cambio estará en línea hasta que la transacción finalice.

Flashback Query: Una consulta flashback permite que usuarios vean la base de datos en un estado pasado. Hay varios métodos para hacer una consulta de flashback, uno de ellos es con SELECT … AS OF.

Para ver una tabla hace 1 minuto:

• SELECT * FROM SCOTT.EMP AS OF TIMESTAMP (SYSTIMESTAMP -1/1440)

Para ver una tabla hace un día:

• SELECT * FROM SCOTT.EMP AS OF TIMESTAMP (SYSTIMESTAMP -1)

Para recuperar los datos borrado hace una hora:

• INSERT INTO SCOTT.EMP (SELECT FROM *SCOTT.EMP AS OF TIMESTAMP (SYSTIMESTAMP -1/24)MINUSSELECT * FROM SCOOT.EMP)

No hay que olvidar que los datos undo deben seguir en el