SAVEPOINT

Rollback de Cambios hasta un Marcador 

Puede crear un marcador en la transacción actual mediante la sentencia SAVEPOINT, que divide la transacción de secciones más pequeñas. Entonces, puede desechar los cambios pendientes hasta ese marcador mediante la sentencia ROLLBACK TO SAVEPOINT.

Si crea un segundo punto de grabación con el mismo nombre que uno anterior, se suprime ese punto de grabación anterior.

• Cree un marcador en una transacción actual utilizando la sentencia SAVEPOINT. 
• Haga rollback hasta ese marcador mediante la sentencia ROLLBACK TO SAVEPOINT. 

Se produce una validación automática en las siguientes circunstancias:

• Se emite una sentencia DDL
• Se emite una sentencia DCL
• Salida normal de iSQL*Plus, sin emitir explícitamente sentencias COMMIT o ROLLBACK

Se produce un rollback automático tras una terminación anormal de iSQL*Plus o un fallo del sistema.

Nota: Hay un tercer comando disponible en iSQL*Plus. El comando AUTOCOMMIT se puede activar y desactivar. Si se activa, cada sentencia DML individual se valida en cuanto se ejecuta. No puede hacer rollback en los cambios. Si se desactiva, la sentencia COMMIT aún se puede emitir explícitamente. Además, la sentencia COMMIT se emite al emitirse una sentencia DDL o al salir de iSQL*Plus. 

Validación de Cambios 

Todos los cambios de datos realizados durante la transacción son temporales hasta la validación de la transacción. 

El estado de los datos antes de que se emitan las sentencias COMMIT o ROLLBACK se puede describir así: 

Las operaciones de manipulación de datos afectan principalmente al buffer de la base de datos; por lo tanto, se puede recuperar el estado anterior de los datos. 

El usuario actual puede revisar los resultados de las operaciones de manipulación de datos consultando las tablas. 

Los demás usuarios no pueden ver los resultados de las operaciones de manipulación de datos realizadas por el usuario actual. Oracle Server instituye la consistencia de lectura para garantizar que cada usuario vea los datos como existían en el momento de la última validación. 

Las filas afectadas están bloqueadas; los demás usuarios no pueden cambiar los datos dentro de las filas afectadas. 

Consistencia de Lectura 
Los usuarios de bases de datos acceden a la base de datos de dos formas:

• Operaciones de lectura (sentencia SELECT) 
• Operaciones de escritura (sentencias INSERT, UPDATE, DELETE) 

Necesita la consistencia de lectura para que se produzca lo siguiente:

• Se garantiza una visualización consistente de los datos al lector y al escritor de base de datos. 
• Los lectores no ven los datos que están en proceso de cambio. 
• Se garantiza a los escritores que los cambios en la base de datos se realizan de forma consistente. 
• Los cambios que realiza un escritor no molestan ni entran en conflicto con los que realice otro escritor. 

El objetivo de la consistencia de datos es que cada usuario vea los datos tal como existían en el momento de la última validación, antes de iniciarse una operación DML.

• La consistencia de lectura garantiza una visualización consistente de los datos en todo momento. 
• Los cambios realizados por un usuario no entran en conflicto con los realizados por otro. 
• La consistencia de datos garantiza que en los mismos datos: 
• Los lectores no tienen que esperar a los escritores
• Los escritores no tienen que esperar a los lectores

Implementación de la Consistencia de Lectura 

La consistencia de lectura es una implementación automática. Mantiene una copia parcial de la base de datos en segmentos de deshacer. La imagen de lectura consistente se crea a partir de datos validados de la tabla y datos antiguos que se están cambiando y aún no se han validado del segmento de deshacer. 

Al realizarse una operación de inserción, actualización o supresión en la base de datos Oracle Server lleva a cabo una copia de los datos antes de que se cambien y los escribe en un segmento de deshacer. 

Todos los lectores, excepto el que emitió en cambio, aún ven la base de datos tal como existía antes de que se iniciaran los cambios; ven la “instantánea” del segmento de deshacer de los datos. 

Antes de la validación de los cambios en la base de datos, sólo el usuario que está modificando los datos ve la base de datos con las modificaciones. Los demás ven la instantánea del segmento de deshacer. Esto garantiza que los lectores de los datos lean datos consistentes que no se estén cambiando actualmente. 

Al validarse una sentencia DML, el cambio realizado en la base de datos se hace visible para cualquiera que emita una sentencia de selección después de realizada la validación. El espacio ocupado por los datos antiguos del archivo de segmento de deshacer se libera para su reutilización. 

Si se hace rollback en la transacción, se deshacen los cambios. 

• La versión original y más antigua de los datos en el segmento de deshacer se vuelve a escribir en la tabla. 
• Todos los usuarios ven la base de datos tal como existía antes del inicio de la transacción.