11.02 ENTENDIENDO COMO LAS TRANSACCIONES GENERAN UNDO

Cuando una transacción inicia, Oracle asignara un (y solo uno) Segmento Undo. cualquier transacción solo puede estar protegida por un Segmento Undo-no es posible para Undo Data generar para una transacción  para cortarla atraves de múltiples segmentos Undo. Esto no es un problema, porque los segmentos Undo no son de tamaño fijo. Así si una transacción se las arregla para llenar su segmento Undo Oracle automáticamente agregara otro Extent al segmento, por lo que la transacción puede continuar. Es posible para transacciones multiples compartir un segmento Undo, pero en condiciones normales esto no debería ocurrir. Un problema común de ajuste con los segmentos Rollback fue estimar cuantos  segmentos rollback sería necesario para evitar la interpolación excesiva de transacciones dentro de los segmentos rollback sin crear tantos como para desaprovechar el espacio. Una característica  de la gestión de Undo es que Oracle automáticamente se generaran nuevos segmentos Undo en demanda, en un intento para asegurar que nunca es necesaria para las transacciones compartir segmentos Undo. Si Oracle se ha visto en la necesidad de ampliar sus segmentos Undo o para generar segmentos adicionales, cuando la carga de trabajo se reduce y eliminará los segmentos, de nuevo automáticamente.

EXAMEN

Ninguna transacción nunca puede abarcar múltiples segmentos Undo, pero un segmento Undo puede soportar transacciones múltiples.

Una transacción actualiza los data blocks de tablas o índices, la información necesaria para rollback de los cambios es escrita a los block del segmento Undo asignado. Todo esto sucederá en el Database Buffer Cache. Oracle garantiza absolutamente la A, para atomicidad de la prueba ACID, significando que todos los Datos Undo serán conservados hasta que la transacción sea confirmada. Si es necesario, el DBWn escribirá los blocks modificados de datos Undo el segmento Undo en los DataFiles. Por defecto, Oracle no hace, sin embargo, garantiza la C para consistencia de la prueba ACID. Oracle garantiza consistencia hasta el punto que si una consulta se realiza tiene éxito, los resultados serán consistentes con el estado de la base de datos en el momento en que la consulta inicio. Pero no garantiza que la consulta tenga éxito realmente. Esto significa que los datos Undo pueden ser clasificados como los diferentes niveles de necesidad. Active Undo es un Dato Undo que significa que pudieran ser necesarios para rollback las transacciones en progreso. Estos datos nunca pueden ser sobrescritos, hasta que la transacción se complete. En el otro extremo, Expired Undo es un dato Undo de transacciones confirmadas, que oracle no está obligado a almacenar. Estos datos pueden ser sobrescritos si Oracle necesita espacio para otra transacción activa. Unexpired Undo es una categoría intermedia; no es ni Active ni Expired: la transacción fue confirmada, pero los datos Undo pueden ser necesarios para lecturas consistentes, si hay consultas de larga duración, Oracle intentara no sobrescribir Undo Unexpired.

EXAMEN

Active Undo nunca puede ser sobrescrito, Expired Undo puede ser sobrescrito. Unexpired Undo puede ser sobrescrito, pero solo si hay escases de espacio.

El hecho que información Undo llega a ser inactiva al confirmar significa que los extents de los segmentos Undo pueden ser utilizados en forma circular. Eventualmente, la totalidad del espacio del Tablespace Undo se llenara con datos Undo, así cuando una nueva transacción inicia, o una transacción corriendo genera poco mas Undo. El segmento Undo “envolverá” alrededor, y el más viejo dato Undo dentro del serán sobrescrito. Siempre asumiendo que los datos más antiguos no es parte de una transacción sin confirmar ejecutando de gran tiempo, en cuyo caso sería necesario extender el segmento Undo en su lugar.

Con los viejos segmentos rollback gestionados manualmente, una parte critica del ajuste fue controlar que las transacciones fueron protegidas por medio del segmento roll back. Un segmento roll back podría incluso ser creado y puesto en línea específicamente para una gran transacción. Administra automáticamente segmento Undo hacen todo eso innecesario, porque usted como DBA no tiene control sobre lo que el segmento Undo protegerá, este protegerá cualquier transacción.

No se preocupe acerca de esto. Oracle hará un mejor trabajo que usted pueda. Pero si usted desea, puede todavía encontrar a que segmentos ha sido asignada cada transacción consultando las vistas V$TRANSACCTION, que se ha unido a las columnas de V$SESSION y DBA_ROLLBACK_SEGS, lo que le permite construir una completa imagen de la actividad de la transacción en su base de datos: cuantas transacciones allí están funcionando actualmente, quien la esta ejecutado, que segmento Undo están protegiendo estas transacciones, cuando inicio la transacción, y el numero de block Undo de cada transacción se ha generado. Un punto de vista relacionado con el rendimiento dinámico es V$ROLLSTAT, que proporciona información sobre el tamaño de los segmentos.

EN EL TRABAJO.

Segmentos Undo no son el mismo que segmentos RollBack, pero las vistas DBA_ROLLBACK_SEGS y V$ROLLSTAT incluyen filas de ambos sin alguna bandera para decir de qué tipo son: La convención de nombres que los distingue: Nombres de segmentos Undo son generados automáticamente y con un prefijo tal como este _SYSSMU.

La figura 11-2 muestra consultas para investigar transacciones en progreso. La primera consulta muestra que son dos transacciones actualmente. Transacción JON ha sido asignada a el segmento con SEGMENT_ID numero 7 y actualmente está utilizando 277 blocks de espacio Undo. SCOTT mucho más pequeña transacción está protegida por dos segmentos.  El segundo query muestra la información del segmento. El tamaño de cada segmento dependerá del tamaño de las transacciones que ocurren  haber sido asignado a ellos previamente. Tenga en cuenta que la combinación de la columna para DBA_ROLLBACK_SEGS es llamada USN.

Ejercicio 11-2.

Trabajar con Transacciones y Consultas Flashback.

En este ejercicio, demostrar la manera en que Datos Undo se utiliza para proporcionar aislamiento de transacción y rollback, y para implementar consulta Flashback. Utilice la tabla REGIONS en el esquema de demostración HR.

Conéctese al esquema HR con dos sesiones concurrentemente. Esto puede ser dos sesiones SQL PLUS o dos sesiones SQL Developer, o una de cada uno. La tabla que sigue enumera los pasos a seguir en cada sesión.

Demostrar el uso de consulta flashback, utilizando una sesión conectada al usuario HR.

1.                 Ajuste si formato de despliegue de hora para incluir segundos:

alter session set nls_date_format='dd-mm-yy hh24:mi:ss';

2.                 Consulte y registre la hora actual.

select sysdate from dual;

3.                 Elimine el registro insertado previamente, y confirme la eliminación:

delete from regions where region_id=100;

commit;

4.                 Consulte la tabla como era antes de eliminar el registro:

select * from regions

as of timestamp to_timestamp('time_from step_2',

'dd-mm-yy hh24:mi:ss');

El registro eliminado de región con Id 100 sera listado, ha sido recuperado de un segmento Undo. La ilustración que sigue muestra los pasos 1-4 utilizando SQL PLUS.