SGBD - Récupération de données

Crash Recovery

Le SGBD est un système très complexe avec des centaines de transactions exécutées chaque seconde. La durabilité et la robustesse d'un SGBD dépendent de son architecture complexe et de son matériel et logiciel système sous-jacents. S'il échoue ou tombe en panne au cours des transactions, il est prévu que le système suivra une sorte d'algorithme ou de techniques pour récupérer les données perdues.

Classification des échecs

Pour voir où le problème est survenu, nous généralisons un échec en différentes catégories, comme suit -

Échec de la transaction

Une transaction doit abandonner lorsqu'elle échoue à s'exécuter ou lorsqu'elle atteint un point d'où elle ne peut pas aller plus loin. C'est ce qu'on appelle l'échec de transaction où seules quelques transactions ou processus sont endommagés.

Les raisons d'un échec de transaction peuvent être -

Logical errors - Lorsqu'une transaction ne peut pas se terminer en raison d'une erreur de code ou d'une condition d'erreur interne.
System errors- Où le système de base de données lui-même met fin à une transaction active parce que le SGBD n'est pas en mesure de l'exécuter, ou il doit s'arrêter en raison d'une condition du système. Par exemple, en cas de blocage ou d'indisponibilité des ressources, le système abandonne une transaction active.

Crash du système

Il existe des problèmes - externes au système - qui peuvent provoquer l'arrêt brutal du système et provoquer une panne du système. Par exemple, des interruptions de l'alimentation électrique peuvent entraîner la défaillance du matériel ou du logiciel sous-jacent.

Les exemples peuvent inclure des erreurs du système d'exploitation.

Panne de disque

Au début de l'évolution de la technologie, c'était un problème courant où les disques durs ou les unités de stockage tombaient fréquemment en panne.

Les pannes de disque incluent la formation de secteurs défectueux, l'inaccessibilité du disque, la panne de la tête de disque ou toute autre panne, qui détruit tout ou partie du stockage sur disque.

Structure de stockage

Nous avons déjà décrit le système de stockage. En bref, la structure de stockage peut être divisée en deux catégories -

Volatile storage- Comme son nom l'indique, un stockage volatile ne peut pas survivre aux pannes du système. Les périphériques de stockage volatils sont placés très près du CPU; normalement, ils sont intégrés au chipset lui-même. Par exemple, la mémoire principale et la mémoire cache sont des exemples de stockage volatile. Ils sont rapides mais ne peuvent stocker qu'une petite quantité d'informations.
Non-volatile storage- Ces mémoires sont conçues pour survivre aux pannes du système. Leur capacité de stockage de données est énorme, mais leur accessibilité est plus lente. Les exemples peuvent inclure les disques durs, les bandes magnétiques, la mémoire flash et la RAM non volatile (avec batterie de secours).

Récupération et atomicité

Lorsqu'un système tombe en panne, il peut y avoir plusieurs transactions en cours d'exécution et divers fichiers ouverts pour qu'ils puissent modifier les éléments de données. Les transactions sont faites de diverses opérations, qui sont de nature atomique. Mais selon les propriétés ACID du SGBD, l'atomicité des transactions dans leur ensemble doit être maintenue, c'est-à-dire que toutes les opérations sont exécutées ou aucune.

Lorsqu'un SGBD se remet d'un crash, il doit conserver les éléments suivants:

Il devrait vérifier les états de toutes les transactions qui étaient en cours d'exécution.
Une transaction peut être au milieu d'une opération; le SGBD doit garantir l'atomicité de la transaction dans ce cas.
Il doit vérifier si la transaction peut être terminée maintenant ou si elle doit être annulée.
Aucune transaction ne serait autorisée à laisser le SGBD dans un état incohérent.

Il existe deux types de techniques, qui peuvent aider un SGBD à récupérer et à maintenir l'atomicité d'une transaction -

Tenir à jour les journaux de chaque transaction et les écrire sur un stockage stable avant de modifier réellement la base de données.
Maintenir la pagination des clichés instantanés, où les modifications sont effectuées sur une mémoire volatile, et plus tard, la base de données réelle est mise à jour.

Récupération basée sur le journal

Le journal est une séquence d'enregistrements, qui conserve les enregistrements des actions effectuées par une transaction. Il est important que les journaux soient écrits avant la modification réelle et stockés sur un support de stockage stable, qui est à sécurité intégrée.

La récupération basée sur le journal fonctionne comme suit -

Le fichier journal est conservé sur un support de stockage stable.
Lorsqu'une transaction entre dans le système et démarre son exécution, elle écrit un journal à son sujet.

<T_n, Start>

Lorsque la transaction modifie un élément X, elle écrit les journaux comme suit -

<T_n, X, V₁, V₂>

Il lit T _n a changé la valeur de X, de V ₁ à V ₂ .

Lorsque la transaction se termine, il enregistre -

<T_n, commit>

La base de données peut être modifiée en utilisant deux approches -

Deferred database modification - Tous les journaux sont écrits sur le stockage stable et la base de données est mise à jour lorsqu'une transaction est validée.
Immediate database modification- Chaque journal suit une modification réelle de la base de données. Autrement dit, la base de données est modifiée immédiatement après chaque opération.

Récupération avec des transactions simultanées

Lorsque plusieurs transactions sont exécutées en parallèle, les journaux sont entrelacés. Au moment de la récupération, il deviendrait difficile pour le système de récupération de revenir en arrière sur tous les journaux, puis de commencer la récupération. Pour faciliter cette situation, la plupart des SGBD modernes utilisent le concept de «points de contrôle».

Point de contrôle

La conservation et la maintenance des journaux en temps réel et dans un environnement réel peuvent remplir tout l'espace mémoire disponible dans le système. Au fil du temps, le fichier journal peut devenir trop volumineux pour être manipulé. Checkpoint est un mécanisme dans lequel tous les journaux précédents sont supprimés du système et stockés en permanence sur un disque de stockage. Checkpoint déclare un point avant lequel le SGBD était dans un état cohérent et toutes les transactions ont été validées.

Récupération

Lorsqu'un système avec des transactions simultanées tombe en panne et se rétablit, il se comporte de la manière suivante:

Le système de récupération lit les journaux à rebours de la fin au dernier point de contrôle.
Il maintient deux listes, une liste d'annulation et une liste refaite.
Si le système de récupération voit un journal avec <T _n , Start> et <T _n , Commit> ou simplement <T _n , Commit>, il place la transaction dans la redo-list.
Si le système de récupération voit un journal avec <T _n , Start> mais aucun journal de validation ou d'abandon trouvé, il place la transaction dans la liste d'annulation.

Toutes les transactions de la liste d'annulation sont ensuite annulées et leurs journaux sont supprimés. Toutes les transactions de la redo-list et leurs journaux précédents sont supprimés puis refaits avant d'enregistrer leurs journaux.