Alejandro Trujillo, Información y Tecnologías Ecuador

Oracle, Microsoft, Administración, y algo más

Gestionando UNDO

Los datos UNDO no son más que una copia de los datos originales antes de aplicar una sentencia DML (Insert, Update, Delete o Merge) y que son utilizados para Operaciones de Rollback, Lecturas Consistentes, Flashback Queries y Recuperación de transacciones fallidas.
 

Undo Tablespaces y Undo Segments

La información UNDO es almacenada en UNDO SEGMENTS y estos a su vez en UNDO TABLESPACES. Los Undo Segments pueden existir en solamente en el Undo Tablespace. (Pueden existir algunos Undo Tablespaces pero solamente uno será el activo en cualquier momento). Los Undo Segments no son de tamaño fijo por lo que si un Undo Segment se llena, Oracle añadirá automáticamente otro Extent. Además Oracle generará automáticamente nuevos Undo Segmens “On demand”. Los Undo Tablespaces deben ser permanentes (Permanent), manejados localmente (Locally Managed) y con Asignación de Extensión Automática (Automatic Extent Allocation). Además un Undo Tablespace (Si es que está activo) no puede puesto fuera de línea (Offline), ni Solo-Lectura (Read-Only) ni ser eliminado, pero pueden añadirse, mover o cambiar el tamaño de los Datafiles.

Segmentos Undo y Transacciones

Cuando una transacción empieza Oracle automáticamente asigna SOLO UN Undo Segment. La información necesaria para hacer un Rollback de la sentencia DML es escrita en los bloques asignados al Segmento Undo. Los datos almacenados aquí son retenidos hasta que se aplique COMMIT; en este estado los datos UNDO están en estado ACTIVE (Que indica que la información almacenada hace referencia a una transacción no finalizada y por ende no puede ser eliminada). Esta etapa garantiza la característica de ATOMICIDAD del modelo ACID de las transacciones.
Si otra sesión hace una lectura de los datos que están siendo actualizados por otra sesión (la transacción aún está activa) Oracle redirecciona la búsqueda a los Undo Segments garantizando la consistencia de datos. Cuando esto sucede se dice que los datos de Undo están en estado UNEXPIRED (Utilizado para lecturas consistentes y Flashback). Esto garantiza a propiedad de CONSISTENCIA del modelo ACID.

Cuando una transacción ha finalizado, automáticamente los datos de Undo pasan a un estado EXPIRED que implica que Oracle puede sobreescribir sobre dichos bloques ya que es información que ya no se necesita para lecturas consistentes y además ha pasado el tiempo suficiente para ejecutar Flashback.
Hay que tener en cuenta que Oracle trabaja en “Circular Fashion”, es decir que cuando los Undo Segments están en un estado EXPIRE y una nueva transacción empieza o alguna transacción que está en ejecución necesita más Undo Segments, los datos más antiguos serán sobrescritos. Oracle asumirá que los Undo Segments catalogados como EXPIRE no son parte de una transacción larga a la que aún no se aplica COMMIT. Si se ve ese caso será necesario extender el tamaño de los Undo Segments.

Errores con UNDO

Si una transacción se queda sin espacio de Undo (porque ya no habrá espacio libre Undo tablespace para extender el Undo Segment) entonces a la sentencia que causó el problema se aplicará automáticamente un Rollback pero el resto de la transacción se mantendría intacta en estado UNCOMMIT. Esto se da si el Undo Tablespace se llena de datos tipo UNEXPIRED UNDO. (ORA-30036)
Otro problema se da cuando una consulta hace una consulta a un block que fue cambiado por otra sesión. Cuando la consulta es redireccionada al Undo Segment respectivo para obtener la versión pre-actualizada y encuentra que el Block ha sido sobreescrito (porque estaba en estado EXPIRED) se obtiene el error “Snapshot Too Old” (ORA-1555)

Para solucionar estos problemas se deben aplicar dos sencillos criterios: Se debe tener suficiente espacio de Undo para permitir que todas las transacciones continúen; y debe haber suficiente Undo Data para que todas las consultas se ejecuten con éxito.

Para prevenir errores relacionados con UNDO es necesario tener en cuenta:

  • Aplicar el tamaño del UNDO Tablespace apropiadamente
  • Asegurarse que a las transacciones largas se apliquen COMMITs periódicamente
  • Configurar apropiadamente el intervalo de retención de UNDO
  • Considerar garantizar UNDO Retention (mediante el parámetro UNDO_RETENTION)

octubre 8, 2008 - Posted by | Oracle | , , ,

Aún no hay comentarios.

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

A %d blogueros les gusta esto: