Protezione dai guasti (basi di dati)

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.

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.

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.

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.

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 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.

Il System Crash è un'anomalia che danneggia la memoria permanente del sistema.

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.

• Paolo Ciaccia, Dario Mario, Lezioni di basi di dati, 2013, Editrice Esculapio, ISBN 978-8874887187

• Base di dati
• Database management system
• Gestore di transazioni
• Lock manager
• Data manager

  Portale Informatica

  Portale Ingegneria