Commit y Rollback SQL Developer

SQL Developer establece COMMITs automáticos implícitos. Este COMMIT se cancela de forma subconsciente y automática en las siguientes situaciones.

(1) SQL Developer se cierra normalmente, sin instrucción COMMIT o ROLLBACK. En este caso, se envía un COMMIT antes de que finalice el programa. Sin embargo, esto no sucede en el caso de una falla del sistema de la PC o una terminación anormal de SQL Developer. Aquí hay un ROLLBACK.

(2) La emisión de una declaración DDL (lenguaje de definición de datos) también da como resultado un COMMIT automático. Las declaraciones DDL incluyen CREATE, DROP, ALTER, TRUNCATE, COMMENT y RENAME

(3) La emisión de una declaración DCL (lenguaje de control de datos) da como resultado un COMMIT automático. Las declaraciones DCL incluyen GRANT y REVOKE.

COMPROMISO VS ROLLBACK

Un COMMIT guarda los cambios de datos en la base de datos, sobrescribiendo el estado de los datos anteriores. A partir de este momento, todos los usuarios pueden ver los resultados. Además, se levanta el bloqueo de las células afectadas. Esto es coherente con «escribir sólo escribir en espera» (consulte Consistencia de lectura). Además, se eliminan todos los SAVEPOINTS.

Un ROLLBACK, por otro lado, descarta cualquier cambio no guardado, haciendo el estado anterior usando el espacio de tabla UNDO. Además, las líneas bloqueadas afectadas se vuelven a liberar.

Si las declaraciones individuales de DML (lenguaje de manipulación de datos) fallan, solo se revertirá esa declaración. Esto se hace con un SAVEPOINT implícito. Así es como se implementa un INSERT de la siguiente manera.

(1) SAVEPOINT before_insert;

(2) INSERT INTO <schema>.<Table> VALUES (…)

(3a) sin error: RELEASE SAVEPOINT (solo es posible en MySQL).

(3b) Error: ROLLBACK TO SAVEPOINT before_insert;

PUNTO DE GUARDADO

Un SAVEPOINT solo se puede lanzar con COMMIT o ROLLBACK en ORACLE. De lo contrario, SAVEPOINT permanece. SAVEPOINTS puede anularse simplemente creando el mismo SAVEPOINT nuevamente.

SAVEPOINT name;

La consistencia de lectura asegura una vista de datos consistente y constante. Se aplican las siguientes reglas:

• Escribe, espera a que escriba
• Las lecturas no esperan a las escrituras. Las celdas bloqueadas se toman del espacio de tabla UNDO
• Las escrituras no esperan a las operaciones de lectura.
• Las operaciones de lectura tampoco esperan a las operaciones de lectura.

PARA ACTUALIZAR

Otra posibilidad es bloquear las células afectadas por adelantado. Esto se hace con la instrucción FOR UPDATE. Si las celdas afectadas ya están bloqueadas por otro usuario, la base de datos espera para ejecutar la instrucción SELECT. El bloqueo solo puede cancelarse mediante COMMIT o ROLLBACK.

Un ejemplo:

SELECT emp_name 
FROM emp 
WHERE empno = 12345 
FOR UPDATE;

La instrucción FOR UPDATE bloquea todas las filas afectadas de una o más tablas. Más específicamente, puede haber un FOR UPDATE OF que solo bloquea el valor afectado de las columnas. Esto permite que otras tablas (por ejemplo, que son necesarias para JOINS pero no se actualizarán) se dejen desbloqueadas para otros usuarios.

SELECT emp_name 
FROM emp 
JOIN dept USING (deptid) 
WHERE deptname = 'xyz' 
FOR UPDATE of emp_name;

El ejemplo anterior no bloquea la tabla de deuda. También en la tabla emp, todos los demás campos no están bloqueados y se pueden actualizar. Esto se puede probar mediante transacciones autónomas:

PRAGMA AUTONOMOUS_TRANSACTION;