Transacciones y Concurrencia

en Oracle

Transacciones En Oracle:

Una transacción es una unidad de trabajo atomica que contiene una o más sentencias SQL

Los efectos de las transacciones pueden ser confirmados (aplicados a la BD) o retrocedidos (deshechos de la BD).

Una transacción siempre comienza con la primera sentencia SQL, no existe el comando BEGIN.

Una transacción cuando una transacción termina siempre es confirmada o retrocedida, ya se explícitamente a través de los comando COMIIT o ROLLBACK o implícitamente al ocurrir una sentencia DDL.

Sentencias Utilizadas Contiene la sintaxis de las sentencias del lenguaje de definición de

datos (Data Definition Language o DDL) como CREATE  CREATE TABLE, CREATE INDEX, CONSTRAINTS, DATATYPESTABLE, CREATE INDEX, CONSTRAINTS, DATATYPES, etc.

Las sentencias del lenguaje de manipulación de datos (Data Manipulation Language o DML) como SELECT, UPDATE, INSERT, DELETE, COMMIT, ROLLBACKSELECT, UPDATE, INSERT, DELETE, COMMIT, ROLLBACK, etc.

El uso de funciones estándar como TO_CHAR, TO_DATE, TO_NUMBER, DECODE, MONTHS_BETWEEN,INSTR, etc...

Ejemplo

UPDATE savings_accounts SET balance = balance - 500 WHERE account = 3209;

UPDATE checking_accounts SET balance = balance + 500WHERE account =3208;

INSERT INTO journal VALUES (journal_seq.NEXTVAL, '1B' 3209, 3208, 500);

COMMIT WORK;

LA TRANSACCION COMIENZA AQUI

LA TRANSACCION TERMINA AQUI

SELECT … UPDATE …

UNA NUEVA TRANSACCION COMIENZA AQUI

SENTENCIAS DE LA TRANSACCIÓN

Ejecución de Sentencias y Confirmación Que una sentencia se ejecute correctamente no

implica que la transacción a la que pertenece sea confirmada.

Todas las sentencias de una transacción pueden correr correctamente, pero sus efectos pueden ser desechos hasta que la transacción sea confirmada.

La confirmación indica que los cambios realizados durante una transacción son hechos permanentes.

En Oracle, las transacciones se confirman cuando: Se invoca explícitamente a la sentencia COMMIT. Automáticamente (implícitamente), cuando se produce

una sentencia DDL o cuando se termina la sesión con la BD.

Lo que se persigue con el uso de transacciones es por un lado contar con una transparencia adecuada de las acciones concurrentes a una base de datos y por el otro tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.

Retroceso a nivel de sentencia El retroceso a nivel de sentencia (statement level rollback)

ocurre cuando se produce un error al ejecutar una sentencia.

Su efecto es como si la sentencia nunca hubiera ocurrido. Ejemplos son:

Inserción de una clave primaria duplicada Inserción del valor nulo en un campo no nulo. Cuando existe un deadlock, se retrocede una de las sentencias

involucradas. Errores descubiertos en la etapa de parsing de la sentencia

no implica un retroceso a nivel de sentencia. El retroceso de una sentencia solo implica la perdida del

trabajo realizado por la misma. Si una sentencia DDL es retrocedida el COMMIT implícito no

es desecho.

Confirmación de Transacciones Cuando una transacción se confirma, los cambios

provocados por ellas se hacen permanentes. Antes de la confirmación ocurre los siguiente:

Oracle ha generado información para deshacer la transacción. Oracle ha generado información para rehacer la transacción. Los cambios han sido aplicados a los buffers del SGA.

Cuando la transacción se confirma, ocurre los siguiente: La transaccion se marca como finalizada y su System Change

Number (SCN) es aplicado a los registros de la tabla. El Log Writter Process (LGWR) escribe las entradas redo log del

SGA y SCN de la transacción. Este evento atómico constituye la confirmación de la transacción.

Los bloqueos de la transacción son liberados. La transacción se marca como completa.

SENTENCIAS

Las sentencias de finalización de transacción son: COMMIT: la transacción termina correctamente, se

vuelcan los datos al tablespace originaly se vacía el RBS.

ROLLBACK: se rechaza la transacción y el vacía el RBS. Cualquier cambio realizado desde que se inició la transacción se deshace, quedando la base de datos en el mismo estado que antes de iniciarse la transacción.

Ejemplo de commit Considere las siguientes sentencias:

INSERT INTO pais VALUES(‘PY’, ‘PARAGUAY’); UPDATE persona SET pais = ‘PY’ WHERE id = 1; COMMIT;

Cuando se ejecuta la sentencia COMMIT los cambios realizados en la base de datos son hechos permanentes.

Retroceso de Transacciones Retroceder (Rollback) significa deshacer todos los cambios

hechos por las sentencias de una transacción sin confirmar: Para ello Oracle hace uso del los undo tablespaces para

almacenar los valores antiguos. Los tipos de retrocesos pueden ser:

Statement Level Rollback Retroceso hasta un punto de recuperación (save point) Retroceso por pedido del usuario Retroceso debido a una terminación anormal Retroceso de todas las transacciones por terminación anormal del

sistema Retroceso de transacciones incompletas en la etapa de

recuperación del sistema. Cuando una transacción se retrocede totalmente:

Oracle deshace todos los cambios realizados utilizando los datos del undo tablespace

Oracle libera los bloqueos que mantenía la transacción. Oracle finaliza la transacción.

Ejemplo de Rollback Considere las siguientes sentencias:

INSERT INTO pais VALUES(1, ‘PY’, ‘PARAGUAY’); UPDATE persona SET pais = ‘PY’ WHERE id = 1; ROLLBACK;

Tanto los resultados de la sentencias INSERT y UPDATE son deshechos cuando se invoca a la sentencia ROLLBACK;

Punto de control (Savepoints) Es posible declarar puntos intermedios en una transacción que

permiten guardar el trabajo realizado hasta el mismo y a partir de los cuales es posible continuar cuando ocurre un fallo.

Dentro de una transacción se pueden crear los llamados “punto de control” mediante la sentencia:

Para retroceder una transacción hasta un punto de control se utiliza la sentencia ROLLBACK TO SAVEPOINT <nombre>

Cuando una transacción es retrocedida: Oracle solo deshace las sentencias realizadas luego del punto de

control. Oracle preserva el savepoint correspondiente y los savepoints

anteriores a este. Oracle libera los bloqueos obtenidos luego del savepoint y preserva

los obtenidos antes del mismo. Una transacción que se retrocede a un punto de control

permanece activa.

SAVEPOINT Nombre_punto_control;

Características Consistencia: Consistencia: Una transacción es un programa correcto

que lleva la base de datos de un estado consistente a otro con la misma característica. Gracias a esto, las transacciones no violan las reglas de integridad de una base de datos.

Aislamiento: Aislamiento: Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad).La seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado.

Atomicidad: Atomicidad: Una transacción es tratada como una unidad de operación. Por lo tanto todas las acciones de la transacción se llevan a cabo o ninguna de ellas se realiza.La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. Se efectúan todas las transacciones, pero en caso de fallas no se realiza ninguna. Una transacción debe concluir comprometida o abortada.

Durabilidad: Durabilidad: Es la propiedad de las transacciones que asegura que una vez que una transacción realiza su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos, se asegura que los resultados de una transacción sobrevivirán a fallas del sistema

Transacciones Serializables Oracle solo permite que las transacciones serializables

realicen cambios solo si se puede comprobar que estos sean consistentes con un planificación secuencial.

Cuando una transacción serializable intenta modificar una fila ya modificada por otra transacción posterior confirmada Oracle genera un error: ORA-08177: Cannot serialize access for this transaction La sentencia es entonces retrocedida pero la transacción no.

Cuando ocurre el error de serialización se puede: Confirmar la transacción para guardar el trabajo hecho. Ejecutar sentencias correctivas (ROLLBACK TO SAVEPOINT). Deshacer la transacción (ROLLBACK)

Transacciones Serializables

Elección del nivel de aislamiento Read Commited

Cuando el sistema debe ser capaz de procesar rápidamente múltiples transacciones.

Cuando la posibilidad de que dos transacciones modifiquen los mismos datos sea casi nula.

Cuando las transacciones no sean afectadas por lecturas no repetibles y lecturas fantasmas.

Serializable Cuando la probabilidad de que dos transacciones

modifiquen las mismas filas sea baja. Cuando las transacciones son afectadas por lecturas no

repetibles y lecturas fantasmas. No apto para transacciones largas, pues pueden ocurrir

problemas de secuencialidad.

Bloqueos en Oracle Oracle provee concurrencia e integridad de datos

entre transacciones concurrentes a través de bloqueos.

Como los mecanismos de control de concurrencia de Oracle están ligados a mecanismo de bloqueos, Oracle proporciona y administra automáticamente mecanismos del bloqueos

En Oracle existen bloqueos implícitos para las sentencias SQL, así los usuarios (casi) no necesitan bloquear explícitamente los datos.

Estos mecanismos automáticos ocurren al más bajo nivel del restrictividad (a nivel de filas) garantizándose integridad de datos y alta concurrencia.

Bloqueos en Oracle Para un entorno multiusuario, Oracle utiliza dos modos

de bloqueo: Bloqueo Exclusivo (Exclusive Lock)

Este bloqueo se obtiene al modificar los datos. Solo la transacción que obtiene este bloqueo puede alterar

los datos, otras transacciones quedan bloqueadas. Bloqueo Compartido (Share Lock)

Permite que múltiples transacción puedan leer simultáneamente los datos pero evita el acceso concurrente de escritores.

Un bloqueo adquirido por una transacción es mantenido hasta que esta finalice.

Los bloqueos adquiridos luego de un SAVEPOINT son liberados cuando la transacción es retrocedida hasta el mismo.

Deadlocks Oracle detecta Deadlocks y los resuelve retrocediendo

una de las sentencias involucradas, la que pertenece a la transacción que detecta el deadlock.

Bloqueos explícitosSQL > LOCK TABLE <tabla> IN <lockmode> MODE [NOWAIT]

MODOS: ROW SHARE (RS)

Permite acceso concurrente a la tabla bloqueada (consultas y actualizaciones en filas no bloqueadas).

Impide que otros usuarios bloqueen la tabla completa en modo EXCLUSIVE.

ROW EXCLUSIVE (RX) Existen Filas bloqueadas en modo exclusivo Permite acceso concurrente a la tabla bloqueada (consultas y

actualizaciones en filas no bloqueadas). Impide que la tabla se bloquee en modo SHARE, SHARE EXCLUSIVE y

EXCLUSIVE. SHARE (S)

Permite consultas concurrentes Se pausa cualquier intento de modificación desde otra transacción Sirve para tener una versión estable, que no puede modificarse, de los

datos mientras alguien tenga un bloqueo SHARE. Otras transacciones no pueden bloquear ROW EXCLUSIVE ni EXCLUSIVE.

Bloqueos explícitos SQL > LOCK TABLE <tabla> IN <lockmode> MODE [NOWAIT]

MODOS: SHARE ROW EXCLUSIVE (SRX)

Permite que otras transacciones lean la tabla Sólo la transacción que posee el lock puede modificar la tabla Se impide que otras transacciones bloqueen SHARE Sólo una transacción puede tener SHARE ROW EXCLUSIVE sobre un

tabla No permite que se cambie el tipo de bloqueo sobre la tabla.

EXCLUSIVE (X) Permite querys sobre la tabla bloqueada Prohibe cualquier otra actividad sobre la tabla (actualizaciones, otros

bloqueos, etc.) Sólo una transacción puede tener un bloqueo EXCLUSIVE.

Bloqueos Explícitos

SENTENCIABloqueo de

filasBloqueo de

la TablaImplicito

SELECT ... FROM table No No No

INSERT INTO table … Si RX Si

UPDATE table ... Si RX Si

DELETE FROM table ... Si RX Si

SELECT ... FOR UPDATE Si RS Si

LOCK TABLE <tabla> IN ...

  ROW SHARE MODE No RS No

  ROW EXCLUSIVE MODE No RX No

  SHARE MODE No S No

  SHARE EXCLUSIVE MODE No SRX No

  EXCLUSIVE MODE No X No