Tema 10 Flashcards
(14 cards)
De que s’ha d’assegurar el SGBD quan entra una transacció?
- Sempre que entra una transacció en un SGBD el sistema ha d’assegurar-se:
● que totes les operacions de la transacció acabin correctament.
● o que la transacció no tingui cap efecte sobre la BD deixant-la estar tal com
estava abans d’iniciar-se la transacció. - El SGBD no ha de permetre mai que s’apliquin sobre la base de dades algunes
operacions d’una transacció i altres no.
Motius de transaccions a mig fer
Motius que fan que quedin transaccions a mig fer:
1. Caiguda de l’ordinador. Caiguda del corrent elèctric, errada hard o soft (el SO es penja). 2.Un error de la transacció. Un error en la programació de la transacció.
3.Validacions de la transacció. A mig fer podem trobar una validació en la transacció que ens digui que no podem seguir.
4.Imposició del control de concurrència. El mètode de control de concurrència pot fer avortar una transacció a mig fer per tal d’evitar els problemes vistos anteriorment.
5.Errada del disc dur. Alguns blocs poden haver perdut les dades emmagatzemades. 6.Altres problemes catastròfics. Virus, esborrats accidentals del disc dur, incendis, inundació…
- Les errades 1,2,3 i 4 són més freqüents que les 5 i 6.
- En les quatre primeres el SGBD hauria de guardar suficient informació per
recuperar-se de l’errada. Penseu que en el moment de l’errada pot haver-hi MOLTES transaccions a mig fer (per exemple podem haver fet un INSERT i no haver actualitzat els índexs, una part de les modificacions de la transacció han quedat gravades i les altres no, …). - Les errades 5 i 6 són poc freqüents i la seva recuperació passa per disposar d’unes bones còpies de seguretat.
Què és el registre del sistema?
- Per recuperar-se de les errades que afecten a les transaccions el sistema manté un registre en el que anota totes les operacions de les transaccions que afecten als valors de la BD. Altres noms del registre: diari, dietari, “bitàcora”, journal, log, relog…
- Tipus d’entrades al registre:
● (Start_transaction, T). Per indicar que s’ha començat l’execució de la transacció T.
● (write_item, T,X, valor_vell, valor_nou). Per indicar que la transacció T ha modificat el valor
de l’element X, passant del valor_vell al valor_nou.
● (read_item, T,X). Per indicar que la transacció T ha llegir l’element X. En molts sistemes de
recuperació no fa falta guardar aquest tipus d’entrada ja que aquesta operació NO modifica
cap taula.
● (Commit, T). Per indicar que la transacció s’ha acabat correctament i que els canvis que
s’hagin produït a la BD ja es poden gravar de forma permanent.
● (abort, T). Per indicar que la transacció s’ha avortat. - Si tots els canvis a la BD es fan dintre les transaccions, recuperar-se d’una errada equival a desfer o refer les operacions de les transaccions des del registre.
Què són els punts de control?
- Un altre tipus d’entrada al registre del sistema són els punts de control (Checkpoints).
- Periòdicament s’escriuen en el registre punts de control (cada m minuts o cada t transaccions) i consisteixen en:
● Suspendre temporalment l’execució de transaccions.
● Forçar l’escriptura a disc de tots els buffers de la memòria que hagin estat modificats.
● Escriure un punt de control en el registre i forçar l’escriptura del registre a disc.
● Re-emprendre l’execució de transaccions. - En conseqüència totes les transaccions que tenen les seves entrades (Commit, T) en el registre abans d’un punt de control SEGUR que ja estan ben guardades a disc i en cas d’una caiguda del sistema no caldrà refer-les ja.
Què són els punts de confirmació d’una transacció?
- Una transacció es diu que ha arribat al seu punt de confirmació quan totes les operacions que accedeixen a la base de dades s’han executat satisfactòriament i l’efecte de totes elles s’ha gravat en el fitxer registre (log).
- Es diu que una transacció s’ha confirmat quan ja ha gravat a la BD i també ha gravat un (COMMIT,T) en el registre.
- Si es produeix un error en el sistema simplement caldrà accedir al registre des del darrer punt de control fins al final i mirar quines són les transaccions que s’han iniciat (start_transaction,T) i que no tenen el corresponent (Commit,T) o (Abort T). Aquestes transaccions són les que han quedat a mig fer i s’hauran de desfer els possibles canvis que hagin fet, tornant a deixar el valor_vell en comptes del valor_nou. Aquest procés finalitza al arribar al final del fitxer registre. No caldrà fer res amb les transaccions anteriors al darrer punt de control ja que aquest ens indica q
Com es recuperen les transaccions de les errades?
- La recuperació d’errades de les transaccions quasi sempre equival a una restauració de la BD a un estat anterior de la BD, el més proper possible al moment de l’errada (de la caiguda).
- Per tal de que això sigui possible el sistema ha de conservar (a fora de la BD) la informació de les modificacions fetes a les diferents taules. Aquestes modificacions es guarden en el fitxer registre (diari, dietari).
- Les estratègies de recuperació passen per:
● Si hi ha danys greus que afecten a gran part de la BD degut a que s’ha malmès una part del
disc dur, virus, etc., llavors la millor solució és recuperar una còpia de seguretat. Tots els SGBD disposen de mecanismes de copia de seguretat i restauració (BACKUP i RESTORE). (errades 5 i 6).
● Si la BD no presenta danys físics, però ha quedat en un estat inconsistent degut a errades no catastròfiques (errades 1 a 4) la estratègia consisteix en reversionar (invertir, tirar enrere, desfer) els canvis que van provocar la inconsistència, fins deixar la BD en un estat consistent. Per això es poden aplicar varies tècniques que veurem en aquest tema.
Gestió de pàgines i buffers
- Ja sabeu que les pàgines de la BD estan al disc, però el SGBD treballa amb elles des del buffer i fa les modificacions sobre aquestes pàgines del buffer. En aquest buffers el SGBD hi manté moltes pàgines. Quan el SGBD creu oportú (normalment quan es necessita alguna altra pàgina que ha de portar al buffer) grava a disc alguna de les pàgines del buffer que ja no necessita i que han estat modificades.
- Per això es poden utilitzar dues estratègies:
● Actualització en el lloc. O sigui “matxaca” la informació de la pàgina vella a disc, escriu a sobre en la mateixa ubicació del disc. És la que es fa servir.
● Actualització a l’ombra. Escriu la pàgina del buffer actualitzada en una ubicació diferent del
disc, guardant-se vàries versions d’una mateixa plana.
Què és l’escriptura anticipada en el registre?
- En general el valor antic d’un element de dades (registre, pàgina) abans de la seva actualització es denomina BFIM (imatge abans de l’actualització, before Image) i el valor nou AFIM (imatge després de l’actualització, after image).
- En les tècniques d’actualització en el mateix lloc, la BFIM caldrà guardar-la a disc, en el fitxer registre (dietari), abans d’escriure el nou valor, per si cal recuperar-la. O sigui, en l’actualització en el lloc, és necessari mantenir el fitxer registre (dietari) per si cal recuperar la informació que teníem abans de ser “matxacada” per la nova.
- En aquest cas les tècniques de recuperació han de garantir la gravació de la BFIM en el registre del sistema a disc, abans que la BFIM sigui “matxacada” per la AFIM. Aquest procés es diu escriptura anticipada en el registre.
- Tot això és el que explicàvem en el capítol 9, sobre la informació que tenien les tuples del registre, concretament les tuples: < (write_item, T, X, valor_vell, valor_nou)>. Si els elements són pàgines, llavors el valor vell es correspon amb la pàgina BFIM i el valor nou amb la pàgina AFIM
Explica les diferents estratègies d’actualització dels buffers
- Una vegada s’ha fet l’escriptura anticipada en el fitxer registre (dietari) de la pàgina modificada, hi ha diferents estratègies a l’hora de quan una pàgina del buffer (memòria intermèdia) es pot gravar a la BD a disc.
- Entre aquestes estratègies cal distingir:
● Mentre s’està executant la transacció. Estratègies robar/no robar. Si una pàgina del buffer
actualitzada per una transacció NO pot escriure’s a la BD al disc abans de que la transacció es confirmi es diu no robar. En cas contrari, si es permet escriure abans de que la transacció es confirmi es diu robar.
● Una vegada s’ha confirmat la transacció. Estratègies forçar/no forçar. Si totes les pàgines del buffer que han estat actualitzades per una transacció s’escriuen immediatament a disc quan la transacció es confirma es diu forçar. En cas contrari és diu no forçar.
- Els SGBD’s típics utilitzen les estratègies de robar/no forçar.
● Mentre s’està executant la transacció utilitzen la estratègia de robar. L’avantatge de robar és que evita la necessitat de tenir un espai de buffer molt gran per emmagatzemar totes les pàgines actualitzades per transaccions pendents de confirmar-se.
● Una vegada s’ha confirmat la transacció utilitzen la estratègia de no forçar. L’avantatge de no forçar és que una pàgina actualitzada d’una transacció confirmada es pot quedar al buffer, d’aquesta manera si una altra transacció necessita aquesta pàgina ens estalviem una operació de E/S.
Explica les Tècniques d’actualització diferida
- Tècniques d’actualització diferida. Mentre la transacció s’està executant utilitzen la estratègia de no robar. Actualitzen la BD en el disc després de que la transacció s’hagi confirmat. Mentre la transacció s’està executant els canvis els fa sobre les pàgines del buffer i evidentment va anotant els canvis en el fitxer registre. D’aquesta manera si una transacció falla o el sistema cau abans de confirmar-se la transacció, com que no s’haurà modificat res a la BD en el disc, no caldrà tocar res del disc, no caldrà desfer res.
- Pot ser caldrà refer, a partir del registre, l’efecte d’alguna transacció que ha acabat, que ha gravat correctament l’acabament de la transacció en el fitxer registre i que el sistema ha caigut en el moment d’anar a gravar les modificacions a la BD en el disc. Aquestes transaccions han quedat con acabades en el fitxer registre, mentre que no van tenir temps de modificar la base de dades en el disc. Les podrem refer.
- Si el SGBD utilitza tècniques d’actualització diferida, l’algorisme que utilitzarem per recuperar la BD i deixar-la en un estat consistent es el de REFER/NO DESFER.
- Actualitzen la base de dades a disc després que una transacció hagi arribat al seu de confirmació.
- Quan es confirma la transacció, primer gravem en el registre (i forcem la seva escriptura al disc) i després s’actualitza la BD. D’aquesta manera si una transacció falla abans d’arribar al seu punt de confirmació, no haurà modificat en absolut la BD i no caldrà desfer res.
- Potser serà necessari refer l’efecte d’alguna transacció confirmada que no es va arribar a guardar correctament a la Base de Dades (p. e. caiguda just després de gravar en el registre).
- Direm que per recuperar-se d’una caiguda els sistemes que fan servir actualització diferida fan servir algorismes de REFER/NO DESFER.
Què és l’algorisme de Refer/ No desfer?
- S’aplicarà en aquells sistemes que utilitzin tècniques d’actualització diferida.
- L’algorisme Refer/No desfer:
● 1er) s’ha de posicionar en el darrer punt de control del registre ja que les anotacions prèvies a aquest darrer punt de control amb tota seguretat estan ben actualitzades a la BD.
● 2on) Per cada anotació <(escriure element, T, X, valor_vell, valor_nou)> de transaccions confirmades del registre, cal que apliqui l’operació REFER, des del darrer punt de control fins al final del fitxer registre. La operació REFER simplement actualitza l’element X de la BD a disc amb el valor_nou, encara que és possible que algun ja estes bé a la Base de Dades a
disc.
- Les transaccions no confirmades des del darrer punt de control fins al final del fitxer de registre, (són les que han quedat a mig fer) caldrà tornar-les a entrar al sistema, no es podran recuperar.
Explica les tècniques d’actualització immediata
- Tècniques d’actualització immediata. Mentre la transacció s’està executant utilitzen la estratègia de robar. És possible que algunes operacions de la transacció actualitzin la BD a disc abans de que la transacció arribi al seu punt de confirmació. L’efecte d’aquestes operacions s’anota al registre i es força l’escriptura d’aquestes a disc abans de gravar-se a la BD a disc, permetent d’aquesta manera la seva recuperació.
- Si una transacció falla o el sistema cau després d’haver fet unes quantes actualitzacions, però abans de confirmar-se (abans d’acabar), serà necessari anular l’efecte d’aquestes operacions sobre la BD a disc. Caldrà reversionar (tirar enrere) les operacions fetes per tal de deixar estar la BD a disc tal com estava abans de començar la transacció. O sigui, caldrà desfer els canvis fets.
- Igual que en l’actualització diferida, pot ser caldrà refer l’efecte d’alguna transacció que ha acabat, que ha gravat correctament l’acabament de la transacció en el fitxer registre i que el sistema ha caigut en el moment d’anar a gravar les modificacions a la BD en el disc. Aquestes transaccions han quedat con acabades en el fitxer registre, mentre que el seu efecte no ha quedat registrat en la base de dades en el disc. Les podrem refer.
- Si el SGBD utilitza tècniques d’actualització immediata, l’algorisme que utilitzarem per recuperar la BD i deixar-la en un estat consistent es el de REFER/DESFER.
- Permeten que operacions d’una transacció actualitzin la base de dades a disc abans que la transacció és confirmi. Aquestes operacions (o el seu efecte) s’anoten en el fitxer de registre i es força la seva escriptura a disc abans de gravar-se a la BD a disc.
- Si una transacció falla després d’haver fet unes quantes actualitzacions però abans de confirmar-se, serà necessari reversionar-les, desfent els canvis que havien produït.
- Davant d’una caiguda serà necessari refer alguna transacció que està confirmada en el registre i que no es va acabar de gravar a la BD a disc (idem diferida). També serà necessari desfer els canvis que hagi produït una transacció que no s’hagi confirmat, però sí que hagi modificat alguna pàgina de la BD a disc.
- Direm que per recuperar-se d’una caiguda els sistemes que fan servir actualització immediata utilitzen algorismes de REFER/DESFER.
Què és l’algorisme de Refer/Desfer?
- S’aplicarà en aquells sistemes que utilitzin tècniques de recuperació immediata. L’algorisme Refer/Desfer:
● 1er) s’ha de posicionar en el darrer punt de control del registre ja que les anotacions prèvies a aquest darrer punt de control amb tota seguretat estan ben actualitzades a la BD.
● 2on) Per cada anotació <(escriure element, T, X, valor_vell, valor_nou)> de transaccions confirmades del registre, cal aplicar l’operació REFER, des del darrer punt de control fins al final del fitxer registre. La operació REFER simplement actualitza l’element X de la BD a disc amb el valor_nou, encara que és possible que algun ja estes bé a la Base de Dades a disc. Igual que amb la recuperació de l’actualització diferida.
● 3er) Per cada anotació <(escriure element, T, X, valor_vell, valor_nou)> de transaccions NO confirmades del registre, cal aplicar l’operació DESFER des del final del fitxer i fins el darrer punt de control (o sigui en ordre invers al que s’han aplicat). La operació DESFER simplement actualitza l’element X de la BD a disc amb el valor_vell, “matxacant” el valor nou que havia gravat la transacció que finalment no es va confirmar.
- Les transaccions no confirmades des del darrer punt de control fins al final del fitxer de registre, (són les que han quedat a mig fer) caldrà tornar-les a entrar al sistema, no es podran recuperar.
Explicació Còpies de Seguretat
- Aquestes tècniques que hem vist són per errades no catastròfiques i sempre hem suposat que no hem perdut el fitxer registre.
- Importància de les còpies de seguretat: de forma periòdica es fa una còpia de seguretat de la BD i del registre (en una cinta magnètica, en un altre disc, en el núvol, ..). En cas d’errada catastròfica es recupera la BD a partir de la còpia.
- Dades crítiques (banca, asseguradores,…) es guarden còpies de seguretat en ubicacions segures.
- Per evitar les pèrdues dels efectes de les transaccions fetes des de la darrera còpia de seguretat es van guardar còpies del fitxers registre (són relativament petits i no cal parar el SGBD) de forma que en cas de caiguda podem recuperar la BD a partir de la còpia de seguretat de la BD i amb la darrera còpia del registre aconseguiren reconstruir els efectes de les transaccions confirmades de la còpia de seguretat del fitxer registre, minimitzant les pèrdues.
