Les pannes
Une BD[1] est parfois soumise à des défaillances qui entraînent une perturbation, voire un arrêt, de son fonctionnement.
On peut distinguer deux types de défaillances :
Les défaillances système
ou défaillances douces (soft crash), par exemple une coupure de courant ou une panne réseau. Ces défaillances affectent toutes les transactions en cours de traitement, mais pas la BD au sens de son espace de stockage physique.
Les défaillances des supports
ou défaillances dures (hard crash), typiquement le disque dur sur lequel est stockée la BD. Ces défaillances affectent également les transactions en cours (par rupture des accès aux enregistrements de la BD), mais également les données elles-mêmes.
Remarque : Annulation des transactions non terminées
Remarque : Ré-exécution des transactions terminées avec succès
Au moment de la panne certaines transactions étaient peut-être terminées avec succès (COMMIT) mais non encore (ou seulement partiellement) enregistrées dans la BD (en mémoire volatile, tampon, etc.). Lorsque le système redémarre il doit commencer par rejouer ces transactions, qui assurent un état cohérent de la BD plus avancé.
Cette reprise des transactions après COMMIT est indispensable dans la mesure où c'est bien l'instruction COMMIT qui assure la fin de la transaction et donc la durabilité. Sans cette gestion, toute transaction pourrait être remise en cause.
Remarque : Unité de reprise
Les transactions sont des unités de travail, et donc également de reprise.
Remarque : Défaillance des supports
Tandis que la gestion de transactions et de journal permet de gérer les défaillances systèmes, les défaillances des supports ne pourront pas toujours être gérés par ces seuls mécanismes.
Il faudra leur adjoindre des procédures de sauvegarde et de restauration de la BD pour être capable au pire de revenir dans un état antérieur cohérent et au mieux de réparer complètement la BD (cas de la réplication en temps réel par exemple).