DBMS - Recupero dati

Crash Recovery

Il DBMS è un sistema estremamente complesso con centinaia di transazioni eseguite ogni secondo. La durata e la robustezza di un DBMS dipendono dalla sua architettura complessa e dal suo hardware e software di sistema sottostante. Se fallisce o si arresta in modo anomalo durante le transazioni, ci si aspetta che il sistema segua una sorta di algoritmo o tecniche per recuperare i dati persi.

Classificazione dei guasti

Per vedere dove si è verificato il problema, generalizziamo un errore in varie categorie, come segue:

Transazione fallita

Una transazione deve interrompersi quando non viene eseguita o quando raggiunge un punto da cui non può andare oltre. Questo è chiamato errore di transazione in cui solo poche transazioni o processi sono danneggiati.

I motivi di un errore di transazione potrebbero essere:

  • Logical errors - Quando una transazione non può essere completata perché presenta un errore di codice o una condizione di errore interno.

  • System errors- Dove il sistema di database stesso termina una transazione attiva perché il DBMS non è in grado di eseguirla o deve arrestarsi a causa di alcune condizioni del sistema. Ad esempio, in caso di deadlock o indisponibilità di risorse, il sistema interrompe una transazione attiva.

Crash di sistema

Ci sono problemi, esterni al sistema, che possono causare l'arresto improvviso del sistema e causare l'arresto anomalo del sistema. Ad esempio, le interruzioni dell'alimentazione possono causare il guasto dell'hardware o del software sottostante.

Gli esempi possono includere errori del sistema operativo.

Errore del disco

Agli albori dell'evoluzione tecnologica, era un problema comune in cui le unità disco rigido o le unità di archiviazione si guastano frequentemente.

I guasti del disco includono la formazione di settori danneggiati, l'irraggiungibilità del disco, l'arresto anomalo della testina del disco o qualsiasi altro guasto, che distrugge tutta o una parte della memoria del disco.

Struttura di stoccaggio

Abbiamo già descritto il sistema di archiviazione. In breve, la struttura di stoccaggio può essere suddivisa in due categorie:

  • Volatile storage- Come suggerisce il nome, una memoria volatile non può sopravvivere ai crash di sistema. I dispositivi di archiviazione volatile sono posizionati molto vicino alla CPU; normalmente sono incorporati nel chipset stesso. Ad esempio, la memoria principale e la memoria cache sono esempi di archiviazione volatile. Sono veloci ma possono memorizzare solo una piccola quantità di informazioni.

  • Non-volatile storage- Questi ricordi sono fatti per sopravvivere ai crash del sistema. Sono enormi nella capacità di archiviazione dei dati, ma più lenti nell'accessibilità. Gli esempi possono includere dischi rigidi, nastri magnetici, memoria flash e RAM non volatile (con backup della batteria).

Recupero e atomicità

Quando un sistema si arresta in modo anomalo, potrebbero essere eseguite diverse transazioni e vari file aperti per modificare gli elementi di dati. Le transazioni sono fatte di varie operazioni, che sono di natura atomica. Ma secondo le proprietà ACID del DBMS, l'atomicità delle transazioni nel suo complesso deve essere mantenuta, ovvero tutte le operazioni vengono eseguite o nessuna.

Quando un DBMS si riprende da un arresto anomalo, dovrebbe mantenere quanto segue:

  • Dovrebbe controllare lo stato di tutte le transazioni che erano in esecuzione.

  • Una transazione potrebbe essere nel mezzo di un'operazione; il DBMS deve garantire l'atomicità della transazione in questo caso.

  • Dovrebbe verificare se la transazione può essere completata ora o se deve essere annullata.

  • A nessuna transazione sarebbe consentito lasciare il DBMS in uno stato incoerente.

Esistono due tipi di tecniche che possono aiutare un DBMS a recuperare e mantenere l'atomicità di una transazione:

  • Mantenere i log di ogni transazione e scriverli su una memoria stabile prima di modificare effettivamente il database.

  • Mantenendo lo shadow paging, dove le modifiche vengono apportate su una memoria volatile, e successivamente, il database effettivo viene aggiornato.

Ripristino basato su log

Il registro è una sequenza di record, che conserva i record delle azioni eseguite da una transazione. È importante che i log vengano scritti prima dell'effettiva modifica e archiviati su un supporto di memorizzazione stabile, a prova di errore.

Il ripristino basato su log funziona come segue:

  • Il file di registro viene conservato su un supporto di memorizzazione stabile.

  • Quando una transazione entra nel sistema e inizia l'esecuzione, scrive un log su di essa.

<Tn, Start>

  • Quando la transazione modifica un elemento X, scrive i log come segue:

<Tn, X, V1, V2>

Si legge che T n ha cambiato il valore di X, da V 1 a V 2 .

  • Quando la transazione termina, registra -
<Tn, commit>

Il database può essere modificato utilizzando due approcci:

  • Deferred database modification - Tutti i log vengono scritti nella memoria stabile e il database viene aggiornato quando viene eseguito il commit di una transazione.

  • Immediate database modification- Ogni registro segue un'effettiva modifica del database. Cioè, il database viene modificato immediatamente dopo ogni operazione.

Recupero con transazioni simultanee

Quando più di una transazione viene eseguita in parallelo, i log vengono intercalati. Al momento del ripristino, sarebbe diventato difficile per il sistema di ripristino eseguire il backtrack di tutti i registri e quindi avviare il ripristino. Per facilitare questa situazione, la maggior parte dei moderni DBMS utilizza il concetto di "checkpoint".

Checkpoint

Conservare e mantenere i log in tempo reale e in un ambiente reale può riempire tutto lo spazio di memoria disponibile nel sistema. Con il passare del tempo, il file di registro potrebbe diventare troppo grande per essere gestito. Checkpoint è un meccanismo in cui tutti i registri precedenti vengono rimossi dal sistema e archiviati in modo permanente in un disco di archiviazione. Checkpoint dichiara un punto prima del quale il DBMS era in uno stato coerente e tutte le transazioni sono state salvate.

Recupero

Quando un sistema con transazioni simultanee si arresta in modo anomalo e si ripristina, si comporta nel modo seguente:

  • Il sistema di ripristino legge i log all'indietro dalla fine all'ultimo checkpoint.

  • Mantiene due elenchi, un elenco di annullamento e un elenco di ripristino.

  • Se il sistema di ripristino vede un log con <T n , Start> e <T n , Commit> o semplicemente <T n , Commit>, inserisce la transazione nell'elenco redo.

  • Se il sistema di ripristino vede un log con <T n , Start> ma non viene trovato alcun log di commit o interruzione, inserisce la transazione nell'elenco di annullamento.

Tutte le transazioni nell'elenco di annullamento vengono quindi annullate ei relativi registri vengono rimossi. Tutte le transazioni nell'elenco di ripristino e i relativi registri precedenti vengono rimossi e quindi ripristinati prima di salvare i registri.