11.03 GESTIONAR UNDO

Una características importante de los Segmentos UNDO es que son gestionado automáticamente, pero debe estableces los limites que Oracle va a gestionar. Después de considerar la naturaleza y el volumen de la actividad en su base de datos, se establece ciertos parámetros de la instancia y ajusta el tamaño de su Tablespace UNDO con el fin de alcanzar sus objetivos.

Condiciones de Error relacionados a UNDO.

Los principios son simples, primero, siempre debe haber suficiente espacio UNDO disponible para permitir  a todas las transacciones continuar, y segundo lugar, siempre debe ser suficiente  datos UNDO disponibles para todas las consultas para tener éxito. El primer principio requiere que su Tablespace UNDO debe ser lo suficientemente grande para acomodar el peor de los casos para demando Undo. Se debe tener suficiente espacio asignado para el el uso máximo de Datos Undo Activos generados por la carga de trabajo de transacciones. Tenga en cuenta que esto podría no ser  el mayor numero de transacciones concurrentes; podría ser que durante el funcionamiento normal tiene muchas transacciones pequeñas, pero el total de Undo que generan  puede ser menor que el generado  por un trabajo  por lote de fin de mes. el segundo principio requiere que haya espacio adicional en el Tablespace Undo para almacenar Datos Undo caducado que puede ser necesario para la consistencia de lectura.

Si una transacción se queda sin espacio UNDO, esta fallara con el error ORA-30036, “no se puede extender el segmento en el Tablespace Undo”. La declaración que origina el proble es hecha Roll Back, pero el resto de las transacciones se mantiene intactas y sin confirmar (uncommitted). El algoritmo que asigna espacio en el Tablespace Undo para segmentos Undo significa que esta condición de error solo se levantara si el Tablespace Undo está completamente lleno de Datos Undo Activos.

Si una consulta encuentra un Block que ha sido cambiado desde que comenzó la consulta, irá al segmento Undo a buscar la versión preupdate de los datos. Si, cuando va al segmento Undo, ese pedazo de Datos Undo ha sido sobrescrito, la consulta fallara en la lectura consistente con un famoso error ORA-1555 “snapshot too old”.

Si el tablespace Undo es insuficiente para el volumen de transacciones y la duración de las consultas, Oracle tiene la opción: ya sea que las transacciones de éxito y el riesgo de querys fallando con ORA-1555 o querys teniendo éxito y el riesgo de transacciones fallando con ORA-30036. El comportamiento por defecto es permitir que las transacciones tengan éxito para que puedan sobrescribir el Undo Expridado.

If the undo tablespace is undersized for the transaction volume and the length of queries, Oracle has a choice: either let transactions succeed and risk queries failing with ORA-1555 or let queries succeed and risk transactions failing with ORA- 30036. The default behavior is to let the transactions succeed, to allow them to overwrite unexpired undo.

Examen

Si una sentencia DML se queda sin espacio undo, la porción de ella que había tenido éxito será hecha rollback. El resto de la transacción se mantiene intacta y sin confirmar (uncommitted).

Parámetros para la Gestión de Undo y Garantizar la Retención.

Hay tres parámetros para controlar Undo: UNDO_MANAGEMENT, UNDO_TABLESPACE y UNDO_RETENTION.

UNDO_MANAGEMENT por defecto es AUTO con la versión 11g. Es posible establecerlo este a MANUAL, lo que significa que Oracle no utilizara segmentos Undo en todo.  Esto es para compatibilidad atrás, y si se utiliza esto, usted tendrá que hace una vasta cantidad de trabajo de crear y ajustar Segmentos RollBack, no lo hagas. Oracle Corporación recomienda configurar este parámetro a AUTO, apara habilitar el uso de Segmentos Undo. Este parámetro es Estático, esto significa que si es cambiado el cambio no surtirá efecto hasta que la instancia sea reiniciada. Los otros parámetros son dinámicos-puedan ser cambiados mientras la instancia está corriendo.

Si usted está usando UNDO_MANAGEMENT=AUTO usted también debe especificar UNDO_TABLESPACE. Este parámetro nomina un Tablespace, que debe haber sido creado como un Tablespace Undo, como los tablespace undo Activos. Todos los Segmentos Undo dentro del serán  traídos en línea (es decir disponible para su uso) de forma automática.

Por último, UNDO_RETENTION, establece en segundo, es generalmente opcional.  Especifica el objetivo para mantener inactivo Datos Undo y determina cuando se clasifica como expirado algo que no ha expirado. Si, por ejemplo, su larga consulta en ejecución es de treinta minutos, se establece el parámetro a 1800. Oracle intentara mantener todos los Datos Undo por al menos 1800 segundo y su consulta por lo tanto nuca fallara con ORA-1555. Si embargo, si no se establece este parámetro, o se establece en cero, Oracle todavía mantendrá los datos por largo tiempo mientras pueda.  El algoritmo de control que expiro los Datos Undo se seobrescribe primero siempre elige a sobrescribir el pedazo mas antiguo, UNDO_RETENTION es siempre el máximo permitido por el tamaño del Tablesapce.

The algorithm controlling which expired undo data is overwritten first will always choose to overwrite the oldest bit of data; therefore, UNDO_RETENTION is always at the maximum allowed by the size of the tablespace.

En el Trabajo

Algunas consultas pueden ser muy largas ejecutándose en realidad.  Consultas de varios días no son desconocidos. Usted necesitara un tablespace Undo de tamaño de Jupiter si se va ha ejecutar este tipo de consulta con éxito durante procesamiento norma.  Es posible que desee considerar limitar la carga de trabajo DML durante los recorridos largosinformes.

Donde el parámetro UNDO_RETENTION no es opcional es si ha configurado Undo para garantizar la retención (Guarantedd Undo Retention). El modo por defecto de operación para Undo es que Oracle favorece transacciones encima de consultas. Si el tamaño del Tablespace Undo es tal que una elección tiene que ser hecha entre la posibilidad  que una consulta falle con ORA-1555 y la certeza  de una transacción con ORA-30036, Oracle optara por permitir a la transacción continuar sobrescribiendo datos Undo que una consulta que podría necesitar. En otras palabras, la retención de Undo solo es un objetivo que oracle va a tratar de lograr. Pero puede haber circunstancias cuando consultas exitosas son consideradas más importantes que una transacción exitosa. Un ejemplo podría ser la facturación de fin de mes para obtener las utilidades, cuando podría ser aceptable para operaciones de riesgo de ser bloqueado por algunas horas mientras el reporte se está generando. Otro cso es si usted está haciendo uso de consultas flashback, que se basan en datos Undo.

Garantizar Undo Retention, significa que datos Undo nunca serán sobrescritos hasta el momento especificado por la retención de Undo haya pasado. Esta habilitado en el tablespace level. Este atributo puede ser especificado en el tiempo de creación del tablespace, o un tablespace undo puede ser modificado posteriormente para habilitarlo. Una vez que active un tablespace undo para el cual se ha especificado la garantía de retención. Todas las consultas se realizan correctamente, siempre que termine dentro del tiempo de Undo Retention; usted nunca tendrá errores “snapshot errors old” de nuevo. La desventaja es que la transacciones pueden fallar por falta de espacio Undo.

Si el parámetro UNDO_RETENTION ha sido establecido, y los datafiles que conforman el Tablespace Undo son establecidos a Autoextend, entonces Oracle incrementara el tamaño de los datafiles automáticamente si es necesario para mantener el Undo Retention. Esta combinación de garantizar Undo Retention y autoextend de datafiles significa que transacciones y consultas siempre serán exitosas-asiminedo que tiene suficiente espacio en disco. Si no la autoextension fallara.

Una base de datos podría tener un tablespace utilizado para operaciones normales donde undo retention no es garantizado y otro será usado durante el reporte de fin de mes donde la retencion  esta garantizada, tales sistemas pueden ser configurados asi,

Dimensionando y Monitoreo de Tablespace Undo

El tablespace debe ser lo suficientemente granda para almacenar  el peor caso de todos Undos generados por las transacciones concurrentes, que serán Undo Active, además de suficiente Undo Unexpired para satisfacer las consultas grandes en ejecución. En un entorno avanzado, es posible agregar espacion para permitir consultas flashback también. El algoritmo es simple: calcular la velocidad a la que se está siendo generando Undo en su hora pico y multiplicar por la duración de su consulta más larga. Hay una vista V$UNDOSTAT que le dice todo lo que necesita saber. También hay un asesor con el Database Control que presentara información de una manera inmediata y comprensible.

La figura 11-4 muestra la ventana de Gestión de Undo del Database Control. Para alcanzar esto, tomar la ficha server de la página principal de su base de datos, luego el Link Automatic Undo Management en la seccion Database Configuration.

La seccion de Configuracion de la pantalla muestra que el Tablespace Undo actualmente que está en uso es llamado UNDO1 y es de 100MB de tamaño, pero los datafiles para el tablesapce son autoextensibles. Haciendo su datafiles undo autoextensibles asegura que transacciones nunca se quedaran sin espacio, pero  Oracle no los extiende simplemente para cumplir con el objetivo UNDO_RETENTION, por lo que es todavía posible para una consulta a fallar con "snapshot too old". Sin embargo no debe confiar en la capacidad de autoextend. Su tablespace debería estar en el tamaño correcto para iniciar. El botón Change Tablespace emite un comando ALTER SYSTEM para activar un tablespace undo alternativo.

Más información dada en la ficha System Activity, mostrada en el Figura 11-5, dice que su pico de generación de Undo fue solo 1664KB por minuto, y la consulta más larga  fue de 25 minutos. El mínimo tamaño del Tablespace Undo será absolutamente seguro para prevenir errores, debería ser en kilobytes.

1664 * 25 = 40265

Que es algo más de 40M, Si el tamaño actual fuera menos, esto sería señalado en la sección de Undo Advisor. No ha habido errores en las transacciones causada por la falta de undospace, y no errores de consulta por falta de datos de deshacer.

Flashback Query.

Flashback query puede imponer exigencias adicionales sobre el Sistema Undo. Flashback query es un servicio que permite a los usuarios ver la base de datos como fue en un momento en el pasado. Hay varios metodos de realizar consultas flashback query, pero el mas simple es una sentencia SELECT con una clausula AS OF por ejemplo:

select * from scott.emp as of timestamp (systimestamp - 1/1440);

Esta declaración regresara todas las filas en la tabla SCOTT.EMP de hace 10 minutos. Las filas que se han eliminado se verán, filas que  se han insertado no se verán, y las filas que se han actualizado se verán con sus valores antiguos. Este es el caso si o no las sentencias DML han sido confirmadas. Para ejecutar una consulta flashback query, datos Undo son utilizados para hacer roll back todos los cambios: Las filas que han sido eliminadas son extraídas desde los segmentos undo e insertar de regreso en el resultado; filas que han sido insertadas son eliminadas del conjunto de resultados.

Esta sentencia trata de ver la taba como lo fue hace un día:

select * from scott.emp as of timestamp (systimestamp - 1);

La primera sentencia es probable tenga exito-esta segunda sentencia probablemente falle con un “snapshot too old” error. El fallo será porque los Datos Undo necesarios para reconstruir la versión de la tabla que fue de hace un día han sido sobrescritos.

Escenarios y Soluciones

A veces usuarios cometen errores terribles. Eliminar datos, hacer actualizaciones inapropiadas, se hacen dos veces las cosas no una vez, y asi sucesivamente ¿Que consideraciones deben ser tomadas para corregir estos errores?

Existen varios enfoques para la corrección de errores del usuario. El más drástico es una "recuperación incompleta", que pone la base de datos al estado en que se encontraba antes del error, pero esto va a perder todo el trabajo realizado posteriormente y puede tardar un tiempo (long) tiempo. Un "flashback de base de datos" tiene el mismo resultado, pero será mucho más rápido. Una consulta de flashback a menudo la mejor solución, pero tendrás que ser rápido, o los datos de deshacer se han expirado.

Como se puede asegurar que ninguna consulta nunca fallara por problemas de undo.

Vas a tener que trabajar el tiempo de la consulta es el mas largo. En cuanto a la columna MAXQUERYLEN de la vista $UNDOSTAT ayudara. Establecer el parámetro UNDO_RETENTION por lo menos a este valor. A continuación. Establezca a autoextent los datafiles Undo Tablespace y habilite RETENTION GUARANTEE para el tablespace. Pero recuerde que esto plantea la posibilidad de llenar el espacio en disco, que puede tener resultados desastrosos. Usted debe controlar la situación.

Flashback query puede ser una herramienta valiosa. Por ejemplo, si debido a algún error una eliminación ha ocurrido en algún momento de la ultima hora, este comando reversa mediante la inserción todas las filas eliminadas de regreso a la tabla.

insert into scott.emp

(select from * scott.emp as of timestamp (systimestamp – 1/24)

minus

select * from scott.emp);

Si el flashback  query es probablemente que se usado, entonces el sistema Undo debe estar configurado para manejar, al establecer el parametro UNDO_RETENTION a un valor apropiado. Si desea que la capacidad de flash back query de un día, se debe establecer a 86400 segundos. El tablespace undo debe ser del tamaño adecuado. Entonces para estar seguros del éxito. O bien permitir la extension automatica para los datafiles del tablespace undo o habilitar la retention guarantee para el tablaspace.

Creando y Gestionando Tablespace Undo.

Hasta ahora la gestión  de datafiles se refiere, un tablespace undo es lo mismo como cualquier tablepace: archivos pueden ser agregados, ajustados de tamaño, tomados online y offline, movido o renombrado. Pero no es posible especificar cualquier opción de almacenamiento: usted no puede especificar automatic segment space management, usted no puede especificar un uniform extent size. Para crear un tablespace utilice la palabra UNDO:

CREATE UNDO TABLESPACE tablespace_name

DATAFILE datafile_name SIZE size

[ RETENTION NOGUARANTEE | GUARANTEE ] ;

Por default, el tablespace no garantiza undo retention. Esta características pueden ser pueden ser especificadas en el momento de creación del tablespace o establecerlas posteriormente.

ALTER TABLESPACE tablespace_name

retention [ GUARANTEE | NOGUARANTEE ] ;

no es posible crear segmentos en un tablespace undo, con excepción que los segmentos undo que serán creados automáticamente. Inicialmente, habrá un pool de 10 segmentos undo creados en un tablespace undo. Mas serán creados si hay mas  de diez transacciones concurrentes. Oracle monitora la velocidad de transacciones concurrentes y ajusta el numero de segmentos necesarios.

No importa cuantos tablespace undo pueda haber en una base de datos,  en general solo uno estará en uso a la vez. Los segmentos Undo en este tablespace tendrán un estatus online (lo que significa que esta disponible para su uso); los segmentos en cualquier otro tablespace tendrá estatus offline, lo que significa que no serán utilizados. Si el tablespace undo es cambiado, todos los segmentos undo en el viejo tablespace serán hechos offline, y los del nuevo tablespace undo seran hechos online. Hay dos excepciones para esto:

•                     En una base de datos RAC, cada instancia que abre las base de datos debe tener su propio tablespace undo. Esto puede ser controlado con el ajuste del parametro UNDO_TABLESPACE a un valor diferente para cada instancia. Cada instancia aportara su propios segmentos undo en linea.

•                     Si el tablespace undo es cambiado mediante el parametro UNDO_TABLESPACE, cualquier segmento en el tablespace que estaba soportando una transacción en el momento del cambio permanecerá online hasta que la transacción finalice.

Examen.

Salvo especifique en tiempo de creación en la clausula del Datafile, el datafile de un tablespace undo no se establecerá a autoextend. Pero si su base de datos es creada con el DBCA, permitirá la extensión automática del datafile del tablespace undo con un maximo de ilimitado. Extension automática puede ser habilitada o des habilitada en cualquier momento ya que puede ser de cualquier archivo de datos.

Ejercicio 11-3

Trabajr con Tablespace Undo.

In this exercise, you will create an undo tablespace with Database Control, and then verify the configuration with SQL*Plus.

1. Connect to your instance as user SYSTEM with Database Control.

2. From the Server tab, in the Storage section take the Tablespaces link.

3. Click Create.

4. Enter UNDO2 as the tablespace name, and set the radio buttons for Locally Managed, Undo, and Read Write.

5. At the bottom of the screen, click Add to specify a datafile.

6. Enter UNDO2-01.DBF as the File Name, leave everything else on default, and click Continue.

7. On the Create Tablespace screen, click Show SQL, and study the statement used to create your undo tablespace. Click Return to return to the Create Tablespace screen, and click OK to create the tablespace.

8. Connect to your instance as user SYSTEM with SQL*Plus.

9. Run this query, which will return one row for each tablespace in your database: select tablespace_name,contents,retention from dba_tablespaces;

Note that your new tablespace has contents UNDO, meaning that it can only be used for undo segments, and that retention is NOGUARANTEE.

10. Run this query, which will return one row for each rollback or undo segment in your database:

select tablespace_name, segment_name, status from dba_rollback_segs;

Note that a number of undo segments have been created automatically in your new undo tablespace, but that they are all offline.

11. Adjust your instance to use the new undo tablespace. Use a SCOPE clause to ensure that the change will not be permanent:

alter system set undo_tablespace=undo2 scope=memory;

12. Rerun the query from Step 9. You will see that the undo segments in the new tablespace have bee brought online, and those in the previously active undo tablespace are offline.

Dentro del Examen.

La base de datos oracle implementa atomicidad, aislamiento y lecturas consistentes de transacciones a través del uso del segmento undo. Los viejos segmentos rollback(y un segmento rollback siempre existirá, utilizando cuando se crea la base de datos) pueden ser todavía utilizados, pero esto es muy mala practica.

Segmentos undo son creados automáticamente en un tablespace undo: un tablespace no puede contener otro tipo de objeto. La base de datos crea segmentos undo sobre demanda, tratando de coincidir el numero de segmentos  con el numero de transacciones concurrentes. Cada segmento se expande cuando sea necesario  para dar cabida a su transacción. Como DBA todo lo que necesita es asegurar que e tablespace undo es suficientemente grande para la carga de trabajo.

La gestión  automática  del mecanismo undo por default a favor de querys. Si un tablespace undo es insuficiente, transacciones continuaran incluso hasta que se tiene que sobrescribir undo expirado, por lo tanto correr el riesgo de fracaso con el error ora-1555 “snapshot too old”. Este comportamiento  puede ser modificado para garantizar qie las consultas tengan éxito, tal vez el riesgo de fallo de transacciones.

Monitorear el uso de Undo es simple atraves del database control undo advisor o mediante la vista v$undostat.

Resumen de Certificación.

Undo data se genera para permitir la atomicidad de transacciones, consistencia en lectura y aislamiento de transacciones. La base de datos oracle garantiza la integridad transaccional absoluta, pero no necesariamente una coherencia de lectura. Si el sistema undo no es apropiadamente configurado, las consultas pueden fallar debido a la falta de datos undo, pero si una consulta tiene éxito sera coherente.

Este comportamiento puede ser modificado, permitiendo la RETENTION GUARANTEE, aunque esto pueda significar que transacciones fallen. Datos undo son almacenados en un tablespace undo contiene segmentos undo gestionados y creados automáticamente. Puede haber más de un tablespaces de deshacer en una base de datos, pero sólo uno estará en uso en un momento dado, esto es controlado por un parámetro de instancia dinámica, UNDO_TABLESPACE.

Dos minutos.

Explicando el Propósito de Undo

·                    Todas las sentencias DML generan Datos Undo.

·                    Datos Undo son utilizados para hacer Rollback a transacciones y aislamiento y para proporcionar lecturas consistentes y también para consultas Flashback.

·                    Gestión automática de Undo utilizando Segmentos Undo es por defecto con la versión 11g.

Entender como las Transacciones Generan Undo.

·                    Datos Undo siempre serán mantenidos hasta que la transacción que los genero sea completada con un COMMIT o un ROLLBACK. Esto es Undo Activo.

·                    Datos Undo serán retenidos por un periodo después de convertirse en Inactivo para satisfacer cualquier requisito de lectura consistente  de consultas largar.

·                    Undo Expirado son datos que ya no se necesitan para lecturas consistentes y puede ser sobrescrito en cualquier momento como espacio reutilizado en segmentos Undo.

Gestionar Undo.

·                    Una instancia utilizara segmentos undo en un tablespace undo.

·                    Mas tablespace undo puede existir, pero solo uno será utilizado a la vez.

·                    El tablespace undo deberá ser grande para almacenar el promedio máximo de undo generado y la consulta mas grande.

·                    Datafiles de Tablespace son datafiles como cualquier otro.