Protezione dai guasti (basi di dati)
In informatica, in particolare parlando di basi di dati, con il termine di protezione dai guasti si intendono tutte quelle procedure attuate al fine di mantenere il database il più possibile integro a fronte di possibili malfunzionamenti.
Tipi di malfunzionamento modifica
Transaction Abort modifica
Il Transaction Abort è un'interruzione di una transazione che non comporta la perdita di dati né in memoria temporanea né in memoria permanente. Questo malfunzionamento è causato da una situazione prevista (come una violazione di vincoli di integrità o un tentativo di accesso a dati di cui non abbiamo i privilegi) ed è correttamente rilevata dal Transaction Manager.
Comportamento a fronte di Transaction Abort modifica
Un Transaction Abort viene gestito con l'uso dei Log (vedi log manager).
Per ogni azione eseguita da una transazione, il data manager provvede a salvare sia il nuovo stato del database, sia un Log dell'azione eseguita che ha portato il vecchio stato nel nuovo. Il Log, comparato con il nuovo stato, ci fornisce la Before Image del database.
Per ogni azione abortita, si effettua un rollback. La gestione del rollback avviene dapprima scrivendo sul Log un abort record (contenente l'ID della transazione che l'ha causato). In seguito vengono disfatte tutte le operazioni precedentemente eseguite dalla transazione che ha causato l'abort.
Protocollo Write Ahead Log modifica
Il protocollo Write Ahead Log prevede che, se una transazione deve essere disfatta, sia indispensabile che la before image sia salvata nel Log ‘'prima'’ che le relative modifiche sul database vengano rese permanenti.
System Abort modifica
Il System Abort è un'interruzione di transazioni attive dovuta a un'anomalia hardware o software dell'unità centrale o di una periferica (ad esempio un blackout). Si assume che il contenuto della memoria permanente sopravviva mentre quello nella memoria temporanea venga perso.
Comportamento a fronte di System Abort modifica
Una transazione si può dire terminata solo quando viene memorizzato sul Log il relativo commit record. Solo in questo caso i suoi lock possono essere rilasciati e la transazone è completamente terminata.
In caso di System Abort, il recovery manager attiva la procedura di Restart. Questa procedura serve a portare la base di dati ad uno stato consistente, effettuando l'operazione di UnDo di tutte le transazioni attive all'atto del guasto. Queste ultime sono riconoscibili dal fatto che non hanno un commit record nel Log.
Politica dell'update ritardato modifica
Politica applicata da DBMS che non permettono l'operazione UnDo (ad esempio Ingres). L'after image di una pagina non viene memorizzata subito nel database ma solo nel Log.
L'esecuzione del commit avviene scrivendo il commit record sul Log e, solo in seguito, copiando l'after image sulla base di dati.
Con questa politica si migliorano le prestazioni del sistema nel caso di frequenti Transaction e System Abort, incorrendo però in una maggiore complessità dei commit.
System Crash modifica
Il System Crash è un'anomalia che danneggia la memoria permanente del sistema.
Comportamento a fronte di System Crash modifica
L'unica modo in cui sia possibile effettuare il recovery da una situazione di System Crash è nel caso in cui sia integro il Log. A tal scopo il Log viene sempre mantenuto in duplice copia.
Bibliografia modifica
- Paolo Ciaccia, Dario Mario, Lezioni di basi di dati, 2013, Editrice Esculapio, ISBN 978-8874887187
