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. 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.

Ejemplo LA TRANSACCION COMIENZA AQUI UPDATE savings_accounts SET balance = balance - 500 WHERE account = 3209; UPDATE checking_accounts SET balance = balance + 500 WHERE account =3208; INSERT INTO journal VALUES (journal_seq.NEXTVAL, '1B' 3209, 3208, 500); COMMIT WORK; SENTENCIAS DE LA TRANSACCIÓN LA TRANSACCION TERMINA AQUI UNA NUEVA TRANSACCION COMIENZA AQUI SELECT … UPDATE …

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.

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.

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. Para establecer un punto de control se utiliza la sentencia SAVEPOINT <nombre>. 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.

Niveles de aislamiento Existen tres fenómenos a ser prevenidos entre transacciones ejecutándose concurrentemente: Lectura Sucias (Dirty Reads): Una transacción lee datos de otra transacción que no se ha confirmado. Lecturas No repetibles (Nonrepeatable Reads): una transacción repite una lectura y encuentra que los datos han sidos modificados o eliminados por otra transacción. Lecturas Fantasmas (Phantoms Reads): Una transacción reejecuta un consulta y encuentra que otra transacción ha insertado datos adicionales. En base a estos fenómenos, el estándar SQL92 define cuatro niveles de aislamiento que difieren en el impacto sobre la productividad en el procesamiento de transacciones. Nvl. de Aislam. Lectura Sucia Lect. No Repetible Lect. Fantasma Lect. Sin Conf. Posible Lect. Conf. No Posible Lect. Repetible * Serializable *

Control de Concurrencia Multiversión Oracle proporciona automáticamente consistencia de lectura a una sola consulta, de manera que se obtienen datos de un solo punto en el tiempo. (statement- level read consistency ) Oracle también proporciona consistencia de lectura para todas las consultas de una transacción. (transaction- level read consistency ) Para esto, Oracle utiliza la información de los segmentos de rollback.

Consistencia de Lectura Consistencia de Lectura a Nivel de Sentencia Oracle asegura (automáticamente) que todos los datos que lee una consulta provienen del momento en que esta se inicia. De esta forma, las consultas no son afectadas por lecturas sucias y cambios provocados por otras transacciones que confirman. En este nivel se evitan las lecturas sucias, pero no las lecturas no repetibles y las lecturas fantasmas. Consistencia de Lectura a Nivel de Transacción En este nivel, Oracle asegura que todas la consultas solo observaran datos que existían solo al momento en que la transacción ha comenzado. En este nivel se evitan las lecturas sucias, lecturas no repetibles y las lecturas fantasmas.

Niveles de aislamiento de Oracle Read Commited Nivel por defecto. Consistencia de lectura a nivel de sentencia. Las transacciones pueden ser afectadas por lecturas no repetibles y lecturas fantasmas. Serializable Solo se observan cambios que fueron confirmados al momento que la transacción empieza. No se experimentan lecturas no repetibles ni lecturas fantasmas. Read-Only Solo se observan cambios que fueron confirmados al momento que la transacción empieza. No están permitidas sentencias INSERT, UPDATE y DELETE.

Niveles de aislamiento de Oracle El nivel de aislamiento de una transacción puede ser establecido (solo) al inicio de esta usando una de estas sentencias: SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET TRANSACTION READ ONLY; El nivel de aislamiento para una sesión puede ser establecido a través de estas sentencias: ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE; ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED; ALTER SESSION SET ISOLATION_LEVEL READ ONLY;

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ícitos SQL > 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 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 SENTENCIA Bloqueo de filas Bloqueo de la Tabla Implicito SELECT ... FROM table No INSERT INTO table … Si RX UPDATE table ... DELETE FROM table ... SELECT ... FOR UPDATE RS LOCK TABLE <tabla> IN ...   ROW SHARE MODE ROW EXCLUSIVE MODE SHARE MODE S SHARE EXCLUSIVE MODE SRX EXCLUSIVE MODE X