Cap.8 Tecniche di Recovery Flashcards
Quali sono le strategie di recovery?
Se viene sottomessa una transazione, possono esserci solo due possibilità, o tutte le operazioni della transazione sono completate ed il loro effetto è registrato permanentemente nel database, oppure la transazione non ha nessun effetto né sul database né sulle altre transazioni (in caso di failure).
Effettuare un recovery (o recupero) da una transazione fallita significa ripristinare il database al più recente stato consistente appena prima del failure.
Per fare ciò, il sistema deve tener traccia dei cambiamenti causati dall’esecuzione di transazioni sui dati. Tali informazioni sono memorizzate nel system log.
Il log è strutturato come una lista di record, dove in ogni record memorizza un ID univoco della transazione e le operazioni effettuate.
Esistono varie strategie di recovery, le tipiche:
1. Se il danno è notevole, a causa di un failure catastrofico (crash di un disco), si ripristina una precedente copia di back-up da una memoria di archivio e si ricostruisce lo stato più vicino a quello corrente riapplicando (REDO) tutte le transazioni committed salvate nel log fino al momento del
failure.
2. Se, a seguito di un failure non catastrofico, il database non è danneggiato fisicamente, ma è solo in uno stato inconsistente, si effettua l’UNDO delle operazioni che hanno causato l’inconsistenza.
Quali sono le tecniche di recovery?
Concettualmente si possono distinguere due tecniche principali per il recovery da failure non catastrofici:
▪ Tecniche ad aggiornamento differito (deferred update) – Algoritmo NO-UNDO/REDO:
I dati non sono fisicamente aggiornati fino all’esecuzione del commit di una transazione. Le modifiche effettuate da una transazione sono memorizzate in un suo spazio di lavoro locale (buffer). Durante il commit, gli aggiornamenti sono salvati persistentemente prima nel log e poi nel database.
Se la transazione fallisce, non è mai necessario l’UNDO, dato che gli aggiornamenti vengono fatti prima nel buffer, può però essere necessario il REDO di alcune operazioni.
▪ Tecniche ad aggiornamento immediato (immediate update) – Algoritmo UNDO/REDO:
Il database può essere aggiornato fisicamente prima che la transazione effettui il commit. Le modifiche sono registrate prima nel log (con un force-writing) e poi sul database, permettendo comunque il recovery. Se una transazione fallisce dopo aver effettuato dei cambiamenti, ma prima del
commit, l’effetto delle sue operazioni nel database deve essere annullato, occorre quindi effettuare il rollback della transazione (UNDO), può però essere necessario il REDO di alcune operazioni.
Per quanto riguarda il recovery da failure catastrofici, la principale tecnica è quella del back-up di database. Periodicamente il database e il system log sono ricopiati su un device di memoria economico. Il system log è back-upped più di frequente, dato che la sua dimensione è notevolmente minore rispetto all’intero database. In caso di failure catastrofico, tutto il database viene ricaricato su dischi e, seguendo il system log, gli effetti delle transazioni committed vengono ripristinati.
