Transacciones y Concurrencia en Oracle

1. Transacciones y Concurrencia en Oracle

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

3. Ejemplo LA TRANSACCION COMIENZA AQUI • 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; SENTENCIAS DE LA TRANSACCIÓN LA TRANSACCION TERMINA AQUI UNA NUEVA TRANSACCION COMIENZA AQUI • SELECT … • UPDATE …

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

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

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

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

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

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

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

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

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

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

14. Niveles de aislamiento de Oracle

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

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

17. Transacciones Serializables

18. Elección del nivel de aislamiento • ReadCommited • 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.

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

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

21. Deadlocks • Oracle detecta Deadlocks y los resuelve retrocediendo una de las sentencias involucradas, la que pertenece a la transacción que detecta el deadlock.

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

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

24. Bloqueos Explícitos