La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Slide 1 Control de Concurrencia y Recuperación Transacciones, propiedades ACID Control de Concurrencia. –Cronogramas en Serie. –Serialisaable/Bloqueo –La.

Presentaciones similares


Presentación del tema: "Slide 1 Control de Concurrencia y Recuperación Transacciones, propiedades ACID Control de Concurrencia. –Cronogramas en Serie. –Serialisaable/Bloqueo –La."— Transcripción de la presentación:

1 Slide 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. 1/21/2014 Lecture 7

2 Slide 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 Slide 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 Slide 4 Transacción El usuario debe indicar: –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 Slide 5 ACID Las Propiedades ACID de la Transacción AA tomicidad: 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. CC onsistencia: 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 AislamientoAislamiento : Cada transacción está aislada de otras transacciones. DD urabilidad: 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 Slide 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 Slide 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 Slide 8 Cronogramas, Cronogramas Seriales Cuál de estos cronogramas de T1,T2, y/o T3? Son seriales? T1: A+=100, B-=100 T3: A=1.06*A, B=1.06*B T1: A+=100, B-=100 T2: C=A+B T1: B-=100, A+=100 T2: C=A+B Time S1 T1: A+=100, B-=100 T3: A=1.06*A, B=1.06*B S2 S3 S4

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

10 Slide 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 Slide 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). -- SX S X ok ok no no ok ok no Lock compatibility lock on data item lock you want

12 Slide 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) time # de bloqueos Mantenidos por una Transacción T Todos los bloqueos son liberados Al final de commit o abort

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

15 Slide 15 LECTURAS SUCIAS Partiendo de una tabla de pedidos, con las siguientes filas: IDPedido Cantidad T+1Usuario1BEGIN TRAN-- T+2Usuario1DELETE PEDIDOS where IdPedido = 21 fila afectada T+3Usuario2SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT SUM(Cantidad) c FROM PEDIDOS (NOLOCK) 10 unidades T+4Usuario3SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT SUM (Cantidad) c FROM PEDIDOS -- sin resultado T+5Usuario1ROLLBACK TRAN;-- T+6Usuario2SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT SUM(Cantidad) c FROM PEDIDOS (NOLOCK) 25 unidades T+7Usuario3SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT SUM (Cantidad) c FROM PEDIDOS 25 Unidades

16 Slide 16 Lectura consistente (L.C.): Durante la ejecución de toda la T, las otras Ts 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) Control de Concurrencia en Oracle

17 Slide 17 Control de Concurrencia en Oracle Control de Concurrencia: AISLAMIENTO automático (iso/ansi sql3) Manejo de las actualizaciones evitando interferencias entre Ts SET TRANSACTON ISOLATION LEVEL [SERIAZABLE | READ COMMITED]; Dos Modos: - SERIAZABLE : secuenciable. Ts 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 Ts son visibles por T y por otras Ts, solo si las otras han hecho commit. Si Ti tiene DML que necesita bloquear filas que tiene otra T, la Ti espera.

18 Slide 18 Bloqueos de datos (locks) -Garantizan consistencia de datos (no permite cambios por otras Ts 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. Control de Concurrencia en Oracle

19 Slide 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 Slide 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 Antes de la imagen Después De la Imagen

21 Slide 21 Práctica con un log* 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? T1,A,update,100,200 T2,C,update,1000,500 T2,D,update,500,1000 T2,commit CRASH

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


Descargar ppt "Slide 1 Control de Concurrencia y Recuperación Transacciones, propiedades ACID Control de Concurrencia. –Cronogramas en Serie. –Serialisaable/Bloqueo –La."

Presentaciones similares


Anuncios Google