uni
Il gestore dell’affidabilità gestisce l’esecuzione dei comandi transazionali:

start transaction (B, begin)
commit work (C)
rollback work (A, abort)
e le operazioni di ripristino (recovery) dopo i guasti:
ripresa a caldo (warm restart)
ripresa a freddo (cold restart)
assicura atomicità e durabilità e usa il log: un archivio permanente che registra le operazioni svolte.
Architettura del Gestore di Affidabilità:

graph TB
    A1(Gestore dei\nmetodi d'accesso)
    A2(Gestore delle\ntransazioni)
    B1(Gestore della\naffidabilità)
    C1(Gestore del\nbuffer)
    D1(Gestore della\nmemoria secondaria)
    E1(BD\nLog)

    A1 -->|fix, unfix| B1
    A2 -->|begin, commit, abort| B1
    B1 -->|fix, unfix, force\npagine BD e log| C1
    C1 -->|read, write| D1
    D1 --> E1

Per capire l’affidabilità è necessario capire la persistenza nelle memoria:

memoria centrale: non persistente, informazione distrutta da qualsiasi guasto.
memoria di massa: persistente, sopravvive ai guasti di sistema ma può danneggiarsi l’unità di memorizzazione.
memoria stabile: questa è una astrazione, è memoria di massa che viene salvaguardata attraverso la ridondanza.

Log

Questo è un file sequenziale gestito dal gestore di affidabilità scritto in memoria stabile che riporta tutte le operazioni in ordine.
Un record nel Log sono operazioni delle transazioni (begin, update, commit ecc), un record di sistema invece contiene i dump e i checkpoint.
Esempio di Log:

begin transaction : $B (T_{1})$
$w [A]$ con $A = 50$ : $I (T_{1}, A, 50)$
$w [A]$ con $A = 20$ : $U (T_{1}, A, 50, 20)$
$r [A]$ con $A = 20$ : nessuna modifica
commit : $C (T_{1})$

Regole di modifica del Log

Regola Write-Ahead-Log:
- si scrive la parte BS (before state: i valori originali prima della modifica) dei record del log prima di effettuare la corrispondente operazione sul database.
- consente di disfare le azioni già memorizzate di transazioni senza commit, con UNDO
Regola Commit-Precedenza:
- si scrive la parte AS (after state) dei record di log prima del commit
- consente di rifare le azioni di una transazione con commit i cui dati non sono stati scritti in memoria di massa, con REDO

Backup

Il Log serve a ricostruire le operazione e CK e DUMP servono ad evitare che la ricostruzione parta da zero.

Checkpoint

Il checkpoint registra la situazione attuale e le transazioni attive in quell’istante, ha lo scopo duale di confermare che le altre transazioni sono o finite oppure non iniziate, per tutte le transazioni che hanno invece effettuato il commit i dati possono essere trasferiti in memoria di massa.
Questa è la modalità più semplice di checkpoint:

si sospende l’accettazione delle operazioni di commit o abort da parte delle transazioni
si forza la scrittura in memoria di massa dei dati modificati da transazioni che hanno fato il commit
si forza la scrittura nel log di un record contenente gli identificatori delle transazioni attive.
Così facendo garantiamo la persistenza delle transazioni che hanno eseguito il commit.

Dump

Il Dump esegue una copia completa di riserva del Database, un _backup.
Viene solitamente prodotta mentre il sistema non è operativo e viene salvato in memoria stabile.
Un record di Dump nel log indica il momento in cui il dump è stato effettuato.

Esito di una transazione

L’esito di una transazione è determinato irrevocabilmente quando viene scritto il record di commit nel logo in modo sincrono, con una force.
Qualsiasi guasto prima di tale istante porta ad un UNDO di tutte le azioni per ricostruire lo stato del database prima della transazione.
Un guasto successivo invece non deve avere conseguenze: lo stato finale del database deve essere ricostruito, con REDO se necessario.
I record di abort possono essere scritti in modo asincrono.

UNDO e REDO

UNDO di una azione su un oggetto $O$ :

update, delete: copiare il valore BS nell’oggetto $O$
insert: eliminare $O$
REDO:
isnert, update: copiare il valore AS nell’oggetto $O$
delete: eliminare $O$
Idempotenza di UNDO e REDO:

$u n d o (u n d o (A)) = u n d o (A)$
$re d o (re d o (A)) = re d o (A)$

Quando scrivere nella Base di Dati

Modalità Immediata

In questa modalità il Database contiene i valori AS provenienti da transazioni senza commit, richiede quindi UNDO delle operazioni di transazioni senza commit al momento del guasto, però non richiede REDO.\

Modalità Differita

In questa modalità il database non contiene valori AS provenienti da transazioni senza commit, in caso di abort non occorre quindi fare nulla (non serve UNDO). Richiede il REDO.
Questa modalità non viene molto utilizzata perché è meno efficiente (anche se favorisce il recovery), poiché si assume che i guasti siano abbastanza rari.

Modalità Mista

Qui la scrittura può avvenire in entrambe le modalità precedenti, richiede quindi sia il UNDO che REDO.

Guasti

Guasti Soft: errori software o caduta di tensione

si perde memoria centrale
non si perde memoria secondaria (database)
non si perde memoria stabile (il log)
si effettua quindi un warm restart (ripresa a caldo)
Guasti Hard: errori dei dispositivi di memoria secondaria
si perde memoria centrale e secondaria
non si perde memoria stabile
si effettua quindi un cold restart (ripresa a freddo)
La perdita del Log invece è considerato un evento catastrofico e quindi non è definita alcuna strategia di recupero.

Modello Fail-Stop

In questo modello l’individuazione di un guasto forza l’arresto completo delle transazioni e il riavvio del sistema operativo, al termine di questa procedura il buffer è vuoto ma le transazioni possono ripartire.

Processo di Restart

L’obiettivo del restart è classificare le transazioni in:

completate, quindi con tutti i dati in memoria stabile
in commit ma non necessariamente completate (possono necessitare di REDO)
senza commit, quindi vanno annullate con UNDO
Il Gestore dell’Affidabilità, al restart del sistema, legge su un file di RESTART (contenuto nel Log) l’indirizzo dell’ultimo checkpoint e prepara due file: UNDO list con gli identificatori delle transazioni attive, REDO list vuoto. Nessun utente è attivo durante un RESTART

Ripresa a Caldo

Questa si rende necessaria al presentarsi di un guasto soft ed è divisa in 4 fasi:

trovare ultimo checkpoint ripercorrendo il log a ritroso
costruire le liste UNDO (transazioni attive ma non committed prima del guasto) e REDO
ripercorrere il Log al contrario (rollback) fino alla più vecchia azione delle transazioni nella lista UNDO e REDO, ripristinando tutte le azioni delle transazioni in UNDO
ripercorrere il Log in avanti (rollforward) rifacendo tutte le azioni delle transazioni in REDO

Ripresa a Freddo

Necessaria quando si presenta un guasto hard:

cerchiamo il record di dump più recente nel Log e si ripristina la parte di dati deteriorata
si seguono le operazioni registrate nel log fino all’istante del guasto
si esegue una ripresa a caldo.

🪴 Quartz 4.0

Explorer

Gestione dell'Affidabilità

Log