Control de Concurrència i Recuperació en Bases de Dades

Control de concurrència

Les interferències entre transaccions trenquen les propietats d'aïllament i definitivitat. Si tenim dues o més transaccions actuant sobre la mateixa pàgina, tupla, etc., de la base de dades (BD) coincidint en el temps, es podrien veure operacions fallides i errors.

Principals interferències

• 1) Doble actualització o actualització perduda: interferència que es pot produir quan les dues transaccions estan actualitzant dades.
• 2) Lectura de valors no confirmats: quan es llegeix una dada modificada per una transacció que encara no ha confirmat.
• 3) Lectura no repetible: quan hi ha una transacció consultant les dades i, entremig, una segona transacció les modifica.

La unitat de dades amb què es treballa és una pàgina (sector de disc); n'hi ha que permeten treballar amb tuples (augmenta el nivell de concurrència) o amb una taula (disminueix el nivell de concurrència).

La majoria de SGBD permeten que les transaccions puguin escollir el nivell d'aïllament amb què volen treballar (quines interferències permeten i quines no). El nivell d'aïllament pot ser:

• Actualització perduda: Read Uncommitted, Read Committed, Repeatable Read, Serializable.
• Lectura de valors no confirmats: Read Committed, Repeatable Read, Serializable.
• Lectura no repetible: Repeatable Read, Serializable.
• Informació fantasma: Serializable.

Gestió de reserves

Funcionament del gestor de reserves (nivell serialitzable):

• A) Si una transacció vol llegir o escriure en una pàgina que ningú utilitza, el gestor li fa una reserva i deixa continuar la transacció.
• B) Si una transacció vol llegir una pàgina que altres transaccions estan utilitzant però només per a lectura, el gestor de reserves li fa una reserva i deixa continuar la transacció.
• C) Si una transacció vol escriure en una pàgina utilitzada, la posa en cua fins que les altres acabin.
• D) Si una transacció vol llegir una pàgina que s'està actualitzant, la posa en cua fins que aquesta s'hagi actualitzat.

Modalitats de reserves

• Exclusiva (X): utilitzada per a pàgines que es volen modificar o escriure.
• Compartida (S): per a pàgines que només es volen consultar.

Es compta de 3 en 3 sense tenir en compte el lock. El graf d'espera mostra gràficament les reserves de les pàgines realitzades per les transaccions.

Protocol de reserva en dues fases

Consisteix en el fet que les transaccions van fent les reserves de les pàgines a mesura que les necessiten i s'alliberen (unlock) les reserves totes juntes en el moment de finalitzar la transacció (commit o rollback). Si s'utilitza aquest protocol, no es produeixen les interferències abans esmentades.

Recuperacions

El gestor de recuperacions ha de garantir que es satisfan les propietats d'atomicitat i definitivitat de les transaccions.

Atomicitat

Propietat que garanteix que no es guardaran els canvis d'una operació cancel·lada. Pot ser cancel·lada per:

• a) Acaba amb rollback.
• b) El gestor de reserves l'ha cancel·lada.
• c) Es produeix un error en el programa que conté la transacció.
• d) Es produeix una caiguda del sistema.

Definitivitat

Garanteix que no es perdin els canvis produïts per transaccions que han confirmat (han acabat amb commit).

Mecanismes de seguretat

Hi ha dos mecanismes per assegurar l'atomicitat i la definitivitat:

• Restauració: per poder desfer tots els canvis de les transaccions no confirmades i assegurar que no es perdin.
• Reconstrucció: reconstruir la BD per si hi ha una fallida o destrucció del disc.

El dietari és on el gestor va guardant informació addicional sobre les actualitzacions produïdes, com commits i rollbacks.

Gestors especialitzats

• Gestor de restauracions: quan hi ha una fallida, el gestor de restauracions ha de desfer tots els canvis produïts per transaccions cancel·lades (rollback). I haurà de refer canvis per a les transaccions finalitzades amb commit que podrien no haver-se guardat al disc.
• Gestor de reconstruccions: quan una part de la BD ha quedat inaccessible, s'ha de reconstruir. Periòdicament, l'administrador fa còpies de seguretat i, d'altra banda, es va guardant al dietari. Quan es reconstrueix, es parteix de l'última còpia de seguretat i s'apliquen les imatges després que es troben al dietari de totes les actualitzacions realitzades per transaccions finalitzades amb commit des de l'última còpia de seguretat.