Oracle almacena datos de undo cuando un proceso modifica datos en una base de datos, capturando los valores existentes antes de la modificación. Esto permite revertir cambios (rollback) y soporta lecturas consistentes, flashback queries y recuperación de transacciones fallidas. El DBA monitorea el espacio en el tablespace de undo y errores como "snapshot too old", y administra la retención de undo a través de parámetros.

1. Jaime Amigo P. © 2006, Santiago - Chile
Instituto Profesional DuocUC
Escuela de Ingeniería
Tablespace de Undo

2. 2
Instituto Profesional DuocUC
Escuela de Ingeniería
Objetivos
Después de completar esta lección, deberás saber lo
siguiente:
• Monitorear y Administrar Undo
• Configurar retención Undo
• Garantizar Retención Undo
• Uso de Undo Advisor

3. 3
Instituto Profesional DuocUC
Escuela de Ingeniería
Undo Data
Datos de Undo es:
• Una copia del original, premodificación, datos
• Capturado para cada transacción que modifica datos
• Retiene al menos hasta la última transacción finalizada
• Usado para soportar:
– Operaciones de Rollback
– Lectura consistente y flashback queries
– Recuperación desde transacciones fallidas
User
Undo Data
Oracle almacena los viejos valores (undo data) cuando un proceso modifica datos en una
base de datos. Almacena los datos existentes antes que sean modificados. Capturar undo
data permite a los usuarios modificar sus MINDS (roll back). Undo también soporta lecturas
consistentes y flashback queries.
Lecturas consistentes. Si se inicia una consulta, ningún cambio bajo las tablas bajo la
consulta, afecta los resultados de la misma. Oracle provee resultados consistentes con los
datos cada vez que se inicia una consulta. Para que una lectura consistente sea exitosa, la
información original debe aún existir como información de undo. Mientras la información de
undo es retenida, Oracle puede reconstruir datos a una consulta satisfactoria de lectura
consistente.
Flashback queries fue instroducido en Oracle 9i. Permite al usuario ver como una tabla lucia
en un instante de tiempo. Dependiendo que tan atrás en el tiempo sea la consulta,
dependera el éxito o no del flashback querie.
Undo data es usado también para recuperar transacciones fallidas. Una transacción fallida
ocurre cuando una sesión de usuario finaliza anormalmente (errores de red o fallas en la
máquina cliente) antes que el usuario decida realizar una transacción de commit o rollback.
Transacciones fallidas pueden suceder cuando hay un crash de la instancia.

4. 4
Undo Data (continuación)
En el caso que una transacción falle, Oracle almacena todos los cambios realizados
por el usuario, recuperando los datos originales.
Información de Undo es retenida para todas las transacciones al menos hasta que la
última transacción finaliza por:
• Usuarios cambien su MIND (rolls back)
• Usuarios finalizan una transacción(commits)
• Término anormal de sesiones de usuarios (rolls back)
• Término normal de sesiones de usuarios con un exit (commits)
La información de Undo puede ser retenida dependiendo de la cantidad de actividad
en la base de datos y de la configuración de la misma.
El monitoreo de un tablespace de undo es diferente al de otros tablespaces. El DBA
debe tener la certeza que dispone de suficiente espacio de undo para satisfacer todo
tipo de transacciones de usuarios. Existen métodos para calcular la cantidad
adecuada de espacio de undo.

5. 5
Instituto Profesional DuocUC
Escuela de Ingeniería
Transacciones y Undo Data
• Cada transacción esta asignado a
solo un segmento de undo.
• Un segmento de undo puede servir a
más de una transacción a la vez.
Transacción
de Update
Vieja
imagen
Nueva
Imagen
Undo segment
Tabla
Transacciones y Undo Data
Cuando se inicia una transacción, ésta es asignada a un segmento de undo. A través
de la vida de la transacción, cualquier cambio hecho durante la transacción, copiara
los valores de los datos cambiados al segmento de undo. Puede ver cuáles
transacciones son asignadas al segmento de undo a través de la vista dinámica de
rendimiento v$transaction.
Los segmentos son segmentos especializados, que son automáticamente creados
por la instancia cuando necesita soporte de transacciones. Como todos los
segmentos, los segmentos de undo están construidos de extents que consisten de
bloques de datos. Los segmentos de undo crecen automáticamente, actúan como un
buffer de almacenamiento circular para ser asignado a transacciones.
Las transacciones llenan extens en los extents de segmentos de undo hasta que esta
se completa o bién, todo el espacio es consumido. Si un extent se llena y se requiere
más espacio, la transacción solicitará espacio al siguiente extent en el segmento.
Una vez que todos los extents han sido consumidos, la transacción regresa al primer
extent (sobreescribe data de undo si es necesario) o se asigna un nuevo extent al
segmento de undo (si es incapaz de reciclarse, porque la información de undo del
primer extents aun es requerida).

6. 6
Instituto Profesional DuocUC
Escuela de Ingeniería
Almacenando información de Undo
La información de undo es almacenado en segmento de
undo, los cuales estan almacenados en el tablespace de
undo. Un tablespace de undo:
• Son solo usado para segmentos de undo
• Tienen condiciones especiales de recuperación
• Pueden ser asociados solo con una instancia single y
una instancia puede solamente tener un tablespace
de undo activo a la vez
Almacenando Información de Undo
Los segmentos de Undo puede existir solo en segmentos especializados en forma de
tablespace llamados tablespace de undo. Si bien una base de datos puede tener
varios segmentos de undo, una instancia puede tener abierto solo uno.
Los segmentos de undo tiene un tipo de segmento “TYPE 2 UNDO” y siempre son
propiedad del usuario SYS. Dado que los segmentos de undo actuan como un buffer
circular, cada segmento tendrá un mínimo de dos extents. El número máximo de
extents por defecto depende del tamaño del bloque de base de datos (32,765 para
un tamaño de bloques de 8K).
El tablespace de undo es permanente, administrado localmente con asignación
automática de extents. Son administrados como cualquier otro tablespace con la
excepción de recovery. Dado que la data de undo es requerida para recuperar
transacciones fallidas (como las que ocurren cuando hay una caída de la instancia),
el tablespace de un puede ser recuerado solo mientras la instancia esta en estado
MOUNT.

7. 7
Instituto Profesional DuocUC
Escuela de Ingeniería
Monitoreando Undo
DBA
Undo normalmente requiere una pequeña administración.
Las áreas a monitorear incluyen:
• Espacio libre en el tablespace de Undo
• Errores “Snapshot too old”
Monitoreando Undo
La mayoria del tiempo undo es administrado automaticamente por la instancia con una
pequeña intervención por parte del DBA. Algunas cosas que pueden requerir intervención
del administrador incluyen:
• Insuficiente espacio para undo
• Usuarios reciben el mensaje de error ORA-01555 snapshot too old
La información de undo siempre es retenida hasta que finaliza la transacción. Esto significa
que si una cantidad extremadamente grande de datos son borrados o modificados
(operaciones de insert consume mucho menos espacio de undo porque la imagien original
del dato insertado es un valor nulo) sin confirmaciones (commit) periodicas de los cambios,
el tablespace de undo lo suficientemente grande para contener los datos originales. Suponga
un caso donde una table de 50 GB tiene que borrar todas las filas con el comando:
SQL> DELETE FROM reallybigtable;
El tablespace de undo podría requerir hacer espacio para los 50 GB originales de
información solo en caso que le usuario que ekl usuario que dio origen a la sentencia
deseara deshacerla a traves de un rollback. Cuando el tablespace de undo es sobrecedido,
el usuario recibe un mensaje de error: ORA-01650: unable to extend rollback segment

8. 8
Monitoreando Undo (continuación)
Otro psoible problema que el administrador puede encontrar con la información de
undo ocurre cuando una consulta necesita acceder información que ya ha sido
sobreescrita en undo. Esto puede suceder en la ejecución de largas consultas de
flashback. Cuando una consulta necesita un “snapshot (foto)” de datos de cierto
instante de tiempo en el pasado y la reconstrucción del snapshot requiere data de
undo que no existe, la consulta retorna el siguiente error:
ORA-01555: snapshot too old

9. 9
Instituto Profesional DuocUC
Escuela de Ingeniería
Administrando Undo
La Administration de undo debe incluir prevenir:
• Errores de espacio en tablespace de Undo
– Dimensione adecuadamente el tablespace de undo
– Asegure grandes transacciones con commit periodicos
• Errores de “Snapshot too old”
– Configure un apropiado intervalo de retención de undo
– Dimensione adecuadamente el tablespace de undo
– Considere garantizar retención de undo
DBA
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=UNDOTBS1
Administrando Undo
Oracle 10g recomienda usar adminsitración automática de undo, configurando el
parámetro de inicialización UNDO_MANAGEMENT dejandolo en AUTO. La
administración manual es soportada para compatibilidad de versiones anteriores,
pero requiere de una gran intervención del DBA.
Con administración automática de undo, el DBA administra undo a nivel de
tablespace. Para controlar el tablespace de undo, una instancia use el parámetro de
inicialización UNDO_TABLESPACE. Después de haber seleccionado el tablespace
de undo, el administrador necesita solamente proveer el espacio necesario y
configurar el intervalo de retención de undo.
Con la administración manual el DBA debe considerar:
• Dimensionar segmentos incluyendo el máximo de extents y su tamaño
• Identificar y eliminar las transacciones bloqueadas
• Crear suficientes segmentos de rollback (en modo manual los segmentos de
undo son conocidos como segmentos de rollback o rollback segments) para
manejar transacciones
• Seleccionar un tablespace para conteneer los segmentos de rollback (el
tablespace solo es usado con administración automática de undo)

10. 10
Instituto Profesional DuocUC
Escuela de Ingeniería
Configurando Retención de Undo
DBA
UNDO_RETENTION=0
La retención de undo especifica en segundos la cantidad
de información de undo confirmada a retener.
• El valor por default es 0 (automática).
• Máximo valor es 232 segundos (más que 187 años).
• Un seteo a 0 indica modo de retención automática de
undo.
Configurando Retención de Undo
La retención de undo es configurada con el parámetro de inicialización
UNDO_RETENTION. Este prámetro setea el tiempo en la cual la información de
undo expira y pued ser sobrescrita.
Administración automática de undo procurará retener información de undo hasta que
expire, pero si una transacción activa necesita espacio en el tablespace de undo, la
información confirmada (no vencida) será sobrescrita sin importar los seteos de
retención de undo que pueden hagan fallar la transacción.
Un seteo de retencíón de undo a 0 signfica que la retención será automática. En este
modo la instancia retiene tanta información como sea necesaria para satisfacer la
consulta mas grande en ejecución. Si el tablespace de undo es muy pequeño para
satisfacer las consulta mas grande en ejecución, la retención automática de undo
retiene tanto undo como sea posible usando el espacio disponible (sin extender el
undo de los datafiles) a menos que la cantidad de información retenida este por
debajo de los 900 (15 minutos). La retención automática mantiene al menos 15
minutos de información de undo permitiendo un pequeño espacio a un error.

11. 11
Configurando Retención de Undo (Continuación)
La información de undo esta dividad en 3 categorias:
• Uncommitted undo information: Soporta transacciones en ejecución y es
requerido si un usuario desae hacer un rollback o si la transacción falla.
Uncommitted undo information nunca es sobrescrita.
• Committed undo information: No es requerida para apoyar la transacción en
ejecución, pero es necesaria para satisfacer el intervalo de retención de undo.
También es conocida como información de undo no vencida. La información de
undo confirmada es retenida tanto como sea posible sin que una transacción
activa falle por carencia de espacio.
• Expired undo information: No es necesaria para apoyar transacciones en
ejecución. Es sobreescrita cuando se requiere espacio por una transacción
activa.

12. 12
Instituto Profesional DuocUC
Escuela de Ingeniería
Garantizando Retención de Undo
SQL> ALTER TABLESPACE undotbs1 RETENTION
GUARANTEE;
Tablespace altered.
SQL> SELECT contents, retention
2 FROM dba_tablespaces
3 WHERE TABLESPACE_NAME='UNDOTBS1';
CONTENTS RETENTION
--------- -----------
UNDO GUARANTEE
Información de undo confirmada será sobrescrita cuando
transacciones fallen por falta de espacio a menos que la
retención de undo este “garantizada”.
Garantizando Retención de Undo
Por defecto el comportamiento de undo sobrescribe transacciones confirmadas que
aun no han expirado si la trasancción activa falla por falta de espacio de undo. Este
comportamiento puede ser modificado para garantizar retención.
Con retención garantizada, los seteos de retención de undo se hacen cumplir aunque
ellas causen transacciones fallidas.
RETENTION GUARANTEE es una cualidad de un tablespace más que un parámetro
de inicialización. Este atributo puede ser cambiado solo a través de comandos SQL.
La sintáxis para cambiar la retención garantizada de un tablespace de undo se
muestra en la figura. El comando SQL es el siguiente:
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
La retención garantizada se aplica solo a tablespace de undo. Al tratar de setear
dicha retención a un tablespace que no es de undo, dara el siguiente resultado:
SQL> ALTER TABLESPACE example RETENTION GUARANTEE;
ERROR at line 1:
ORA-30044: 'Retention' can only specified for undo tablespace

13. 13
Instituto Profesional DuocUC
Escuela de Ingeniería
Dimensionando el Tablespace de Undo
Rango de
Consumo de Undo
Tamaño Actual
del
Tablespace
Dimensionando el Tablespace de Undo
El tablespace de undo debe ser dimensionando de manera que contenga la
información original para todas las transacciones. Haciendo click en el link de Undo
Management sobre Enterprise Manager en la página de Administración muestra un
resumen del sistema de undo incluyendo actual configuración, consumo de undo por
minuto y el tiempo de duración de la consulta mas grande durante un periodo de
tiempo dado
Los datafiles que pertenecen a un tablespace de undo pueden ser automáticamente
extendidos cuando ellos requieren más espacio libre. A diferencia de otros
tablespace, Oraclre comienda que los datafiles asociados con tablespace de undo no
tengan habilitada extensión automática. Cuando se determinan los requerimientos de
espacio de undo, usted puede habilitar extensión automática de los datafile, pero
despues que el tamaño esta adecuadamente dimensionado, se recomienda
deshabilitarlo. Al deshabilitar la extensión automática de los datafile de un tablespace
de uno se previene que un usuario consuma una gran cantidad de espacio debido a
transacciones no confirmadas (sin commit).

14. 14
Instituto Profesional DuocUC
Escuela de Ingeniería
Usando el Asesor de Undo
Usando el Asesor de Undo (Undo Advisor)
El Undo Advisor es accesado desde la página Undo Management. Esto entrega una
estimación del tamaño requerido por el tablspace de undo para satisfacer una
retención de undo dada.
Ingrese el periodo de retención deseado y haga click en el botón Update Analysis
and Graph. La sección de análisis del asesor, displiega el tamaño requerido del
tablespace para el periodo de retención deseado.
También puede hacer un click en un punto del gráfico para ver el tamaño requerido
para soportar el período seleccionado.
Después de seleccionar el periodo de retención de uno, haga click en OK para
implementar el nuevo período de retención.

15. Jaime Amigo P. © 2006, Santiago - Chile
Instituto Profesional DuocUC
Escuela de Ingeniería
Fin de la Lección