bloqueos

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. 04/27/23 Lecture 7

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.

TransacciónTransferir $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

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

Las Propiedades ACIDACID de la Transacción

• AAtomicidad: 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.

• CConsistencia: 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.

• DDurabilidad: 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.

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.

Cronogramas en Serie

• Consideren estas transacciones:

T1: BEGIN A+=100, B-=100 END //Deposito, retiroT2: BEGIN C = A+B END //Calcular balanceT3: 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.

Cronogramas, Cronogramas Seriales• Cuál de estos cronogramas de T1,T2, y/o T3? Son seriales?

T1: A+=100, B-=100T3: 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

TimeS1

T1: A+=100, B-=100 T3: A=1.06*A, B=1.06*B

S2

S3

S4

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.

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”

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 conseguirUna transacción, debe esperar (en cola).

-- S X

--

S

X

ok

ok

ok no no

ok ok

ok no

Lock compatibility

lock on data item

lock

you

wan

t

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 bloqueosMantenidos por una

Transacción T

Todos los bloqueosson liberadosAl final de commit o abort

0

21

43

5

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.

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.

LECTURAS SUCIASPartiendo de una tabla de pedidos, con las siguientes filas:IDPedido Cantidad1 10.2 15 .

T+1 Usuario1 BEGIN TRAN --

T+2 Usuario1 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 Usuario1 ROLLBACK TRAN; --

T+6 Usuario2 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT SUM(Cantidad) c FROM PEDIDOS (NOLOCK)

25 unidades

T+7 Usuario3 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT SUM (Cantidad) c FROM PEDIDOS

25Unidades

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)

Control de Concurrencia en Oracle

Control de Concurrencia en OracleControl 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.

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 SHAREEXCLUSIVE (X) No permite ningún otro lock.

Control de Concurrencia en Oracle

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.

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

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,200T2,C,update,1000,500T2,D,update,500,1000T2,commitCRASH

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

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.

bloqueos

Documents

Transcript of bloqueos