Control de Concurrencia y Recuperación

Presentación del tema: "Control de Concurrencia y Recuperación"— Transcripción de la presentación:

1 Control de Concurrencia y Recuperación
Transacciones, propiedades ACID Control de Concurrencia. Cronogramas en Serie. Serialisaable/Bloqueo La teoría Conflictos de serializable Gráficos de precedencia El mundo real Bloqueo Bloqueo estricto de dos fases. Deadlock Niveles de bloqueo Recuperación tras bloqueo ACID: Atomicidad y Durabilidad Recuperación de Errores Solución: Escribir a través de logs - Write Ahead Logging (WAL) Reglas de atomicidad y durabilidad Usando WAL para manejar cancelación. CS3/586 Some slides copied from R. Ramakrishnan, with permission. Others © 2009 Len Shapiro /24/ Lecture 7

2 Transacción Control de concurrencia y recuperación de errores se basan en el concepto transacción. Una transacción es un conjunto de declaraciones SQL del usuario.

3 Transacción Transferir $100 de una cuenta a otra: BEGIN transaction
read balance de la primera cuenta add $100 a la balance de cuenta write balance a la primera cuenta read balance de la segunda cuenta verify balance para ver si contiene al menos $100 Si no, ABORT transacción subtract $100 de la segunda cuenta write balance a la segunda cuenta COMMIT transaction

4 Transacción El usuario debe indicar: además Begin transaction
read/write/modify statements combinadas con otras declaraciones de lenguajes de programación como verify además commit - satisfecho or abort – cancelar el trabajo

5 Las Propiedades ACID de la Transacción
Atomicidad: Una transacción se hace toda o nadad Que pasa si el SO colapsa después de que los $100 se depositaron en la primera cuenta? El administrador de recuperción del DBMS debe asegurar que los $100 se retiren de la primera cuenta. Consistencia: Si la BD inicia en un estado consistente debe asegurarse de que después siga en ese estado. El programador debe asegurarse que todos los programas sean consistentes Aislamiento: Cada transacción está aislada de otras transacciones. Durabilidad: Si la transacción se confirma los cambios a la BD persisten (los cambios son permanentes) Que pasa si el SO colapsa antes que los retiros se escriban en discos? El administrador de recuperación por lo menos debe escribirse en el archivo de log.

6 Concurrencia Aislamiento es un problema que ocurre cuando múltiples usuario acceden a los mismos datos. Porqué la concurrencia es necesaria? Las Aplicaciones la requieren Mejor uso de recursos: Mientras que una transacción lea el disco otra puede usar el CPU.

7 Cronogramas en Serie Consideren estas transacciones:
T1: BEGIN A+=100, B-=100 END //Deposito, retiro T2: BEGIN C = A+B END //Calcular balance T3: BEGIN A =1.06*A, B=1.06*B //Dar el interes Definición: Un cronograma de transacciones son acciones intercaladas de manera que el order se mantenga Definición: Un cronograma de transacciones es serial cuando ocurre una a otra.

8 Cronogramas, Cronogramas Seriales
Cuál de estos cronogramas de T1,T2, y/o T3? Son seriales? Time S1 T1: A+=100, B-=100 T3: A=1.06*A, B=1.06*B S2 T1: A+=100, B-=100 T3: A=1.06*A, B=1.06*B S3 T1: A+=100, B-=100 T2: C=A+B S1: A schedule of T1 and T3. Also a Serial schedule. S2: A schedule of T1 and T3. Not a serial schedule. S3: A Schedule of T1 and T2. Not a serial schedule. S4: Not a schedule because T1 is not in the correct order. S4 T1: B-=100, A+=100 T2: C=A+B

9 Concurrencia Permitible
Queremos permitir cronogramas intercalado como S2&S3, (caso contrario el DBMS será muy lento) (sistema por lotes). S2 parece good. Cualquier DBMS podría permitir S2. Que está mal con S3? Cualquier DBMS prohibirá S3. S2 is good because S2 leaves the database in the same state as does S1, because you can perform the green actions in any order and get the same result. S3 is bad because the Auditor C will read a false balance. C will find an extra $100 in A's account.

10 Bloqueos: Usados por la mayoría de los DBMSs para Hacer cumpler serialibilidad
Transacciones deben conseguir un bloqueo – antes de escribir o actualizar datos Hay dos tipos de bloqueos: compartidos (shared) (S) and exclusivos (X) Para leer un registro tu debes conseguir un bloqueo S Para escribir (modificar o eliminar) un registro tu DEBES conseguir una bloqueo X “lock manager”

11 Como trabajan los bloqueos
Si un objeto tiene un bloqueo S, nuevas transacciones pueden conseguir bloqueos S pero no bloqueos X. Si un objeto tiene un bloqueo X, ninguna Otra transacción puede tener otro bloqueo (S o X) en ese objeto. Si una transacción no puede conseguir Una transacción, debe esperar (en cola). lock on data item -- S X ok ok no no ok no lock you want Lock compatibility

12 Protocolo de Bloqueo en 2 Fases
2PL es una forma de administrar bloqueos durante una transacción T consigue bloqueos (S y X) de manera gradual según se necesite. T mantiene todos los bloqueos hasta el final de la transacción (confirmación / cancelación) Todos los bloqueos son liberados Al final de commit o abort 5 # de bloqueos Mantenidos por una Transacción T 4 3 2 1 time 

13 2PL garantiza seriabilidad
Prueba: un cronogrma estricto 2PL es equivalente a un cronograma en serie en el cual cada transacción se ejecuta al momento de su confirmación Es enorme: Una propiedad de cada transacción (S2PL) implica una propiedad de cada conjunto de transacciones (serialisable) DBMS usan S2PL para asegurar seriabilidad.

14 Niveles de Aislamiento*
Los desarrolladores pueden escojer que nivel de aislamiento (protección) usar … Hay cuatro niveles definidos: “READ UNCOMMITTED” (Lectura no Confirmada) – permite lecturas sucias, no repeatable, y “fantasmas” “READ COMMITTED*” (Lecturas Confirmadas) – permiten lecturas no repetibles y fantasmas. “REPEATABLE READ” (Lecturas repetibles) – permiten fantasmas “SERIALIZABLE*” (Serializable)– aislamiento completo. Dirty read: read a data item that might subsequently be rolled back Unrepeatable read: read an item twice during a transaction and get different results, even though the transaction did not change the value of the data item Phantom: retrive a collection of objects twice in a transaction and get different results even though the transaction did not change any of the data

15 LECTURAS SUCIAS Partiendo de una tabla de pedidos, con las siguientes filas: IDPedido Cantidad 15 . T+1 Usuario1 BEGIN TRAN -- T+2 DELETE PEDIDOS where IdPedido = 2 1 fila afectada T+3 Usuario2 SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  SELECT SUM(Cantidad) c  FROM PEDIDOS (NOLOCK) 10 unidades T+4 Usuario3 SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  SELECT SUM (Cantidad) c FROM PEDIDOS -- sin resultado T+5 ROLLBACK TRAN; T+6 25 T+7 Unidades

16 Control de Concurrencia en Oracle
Lectura consistente (L.C.): Durante la ejecución de toda la T, las otras T’s ven el contenido de la BD congelado, con los valores que tenía al comienzo de la T, - A nivel de transacción: SET TRANSACTON READ ONLY; esa T solo lee, no modifica, agiliza BD Solo ve las actualizaciones que estaban confirmadas cuando empezó T. A nivel instrucción: (por defecto en oracle) SET TRANSACTON READ WRITE; . Consistencia de Lectura Tres situaciones: 1.- L.C. implícita (nivel instrucción): se mantiene dentro de la instrucción SELECT… 2.- Sin L.C.: SELECT… (se ve y modifica entre las dos consultas) SELECT… 3.- L.C. explícita : COMMIT; (inicia T) SET TRANSACTON READ ONLY; (debe ser 1ª instr en T) SELECT count (*) from cliente; SELECT count (*) from invierte; COMMIT; (termina la T de read only)

17 Control de Concurrencia en Oracle
Control de Concurrencia: AISLAMIENTO automático (iso/ansi sql3) Manejo de las actualizaciones evitando interferencias entre T’s SET TRANSACTON ISOLATION LEVEL [SERIAZABLE | READ COMMITED]; Dos Modos: - SERIAZABLE : secuenciable. T’s no pierden actualizaciones --ver a) en sección 1.2--, se garantizan lecturas repetibles --ver d) en sección 1.2--, no hay registros fantasma y tampoco resumen incorrecto. Porque las modificaciones hechas por T solo la ve T. Si Ti actualiza algún recurso que actualizó Tj y está sin confirmar, entonces Ti aborta. - READ COMMITED : (por defecto) Lectura Consistente. La T no tiene lecturas repetibles. Modificaciones hechas por T y otras T’s son visibles por T y por otras T’s, solo si las otras han hecho commit. Si Ti tiene DML que necesita bloquear filas que tiene otra T, la Ti espera.

18 Control de Concurrencia en Oracle
Bloqueos de datos (locks) -Garantizan consistencia de datos (no permite cambios por otras T’s mientras se lee/actualiza) -Garantiza integridad (datos y estructuras correctas) -Se mantienen hasta un commit/rollback o desbloqueo explícito -Usos: -Para controlar los accesos y actualizaciones concurrentes -Reservar un tabla para toda la transacción -Lecturas repetidas en bucles. Bloqueos automáticos: los pone el SGBD a nivel de fila Bloqueos explícitos: los pone el programador LOCK TABLE mitabla IN XXXX MODE [NOWAIT] ; XXXX puede ser: SHARE (S) Lectura concurrente . Permite otros locks SHARE EXCLUSIVE (X) No permite ningún otro lock.

19 El Problema de Recuperación de Administrador
Sea la transacción $100 depositados en A, luego $100 se retira de B Problema de recuperación: SO colapsa después de un depósito El deposito ha sido escrita al disco El Banco pierde $100 Se viola la atomicidad SO colapsa después de ser confirmada Ni depósito ni retiros se escriben al disco. Transacciones se confirman pero no pasan. Se viola la Durabilidad.

20 Solución Write Ahead Log (WAL) para administrar recuperación en abortos(y abortos también). WAL debe estar en un disco separado de los datos. Un registro log se escribe para cada insert, update, delete, begin-trans, commit, abort y checkpoint. Un registro de log contiene <XID, ID of the DB record, action, old data, new data> Antes de la imagen Después De la Imagen

21 Práctica con un log* What did each transaction do before the crash?
T1,A,update,100,200 T2,C,update,1000,500 T2,D,update,500,1000 T2,commit CRASH What did each transaction do before the crash? After the crash, what should the recovery manager do to ensure that each transaction is atomic? Which WAL rule guarantees that your solution (UNDO)will work? After the crash, what should the recovery manager do to ensure that each transaction is durable? Which WAL rule guarantees that your solution (REDO) will work? What did each transaction do before the crash? T1 wrote 200 to A. Then T2 wrote 500 to C. Then T2 wrote 1000 to D. Then T2 committed. After the crash, what should the recovery manager do to ensure that each transaction is atomic? It should UNDO (roll back) each transaction that has not committed. In this case, it must UNDO T1. Which WAL rule guarantees that your solution (UNDO)will work? The Atomic rule. After the crash, what should the recovery manager do to ensure that each transaction is durable? It should REDO the actions of all committed transactions. In this case, it should write 500 to C and write 1000 to D Which WAL rule guarantees that your solution (REDO) will work? The durability rule.

22 Recuperación Real es más complicada
Hemos ignorado mayores complejidades como: Administrar aborts normales, algunos de los cuales progresarían al momento de colapsar Administrando inserts y deletes Soportando multiples niveles de bloqueo Administrando actualizaciones para estructuras tio árbol B+ cuando las páginas colapsan. Administrando colapson en medio de la recuperación

23 ARIES En 1990s, C. Mohan de IBM propuso un algoritmo relativamente simple llamado ARIES* ARIES difiere de otros modelos simples de algunas maneras. Rehace cada actualizar, no los las transacciones confirmadas. Sorpresivamente simplifica el algoritmo. Registra undos durante la recuperación. Esto administra colapsos durante la recuperación.