Rollback – Wikipedia
Quand Retour en arriere (Depuis le “Roll Back” anglais pour “Roll Back” ou “Turn Back”) dans EDP Systems Le “réinitialisation” des étapes de traitement individuelles d’une transaction. Le système est complètement attribué à l’État avant le début de la transaction.
Un retour en arrière est généralement initié en cas d’erreur si, par exemple, une étape de traitement dans la transaction en question ne peut pas être effectuée correctement. Dans le processus normal (sans situation d’erreur), les modifications apportées à la transaction sont effectuées en permanence avec un “engagement”.
Les recul jouent un rôle important, en particulier en relation avec les systèmes de base de données et d’autres systèmes transactionnels. Une transaction est une conséquence des opérations connexes sur une base de données. Une transaction peut transférer la base de données d’un état cohérent à un autre état cohérent. Les règles de cohérence d’une base de données peuvent être désactivées pendant la transaction. Afin d’assurer la cohérence de la base de données, les transactions doivent toujours être effectuées complètement ou pas du tout (voir principe acide). L’exécution incomplète d’une transaction, par ex. B. en raison d’une erreur système conduit à la rétro-retour de la transaction.
En plus de la refonte, le retour en arrière est une mesure pour la sauvegarde des données (“Mesure de récupération”). Il vise à éviter les incohérences.
Une sauvegarde complète des données n’est possible que si un protocole est effectué pour chaque transaction. Ce protocole est également appelé journal, fichier journal ou piste d’audit. En raison de l’enregistrement séquentiel (chronologique) des modifications, il existe un fichier séquentiel.
- Journal avant l’image
- Piqûre de la condition avant Le changement pour toutes les modifications des objets effectués dans une transaction
- Journal après-image
- Piqûre de la condition après Le changement pour toutes les modifications des objets effectués dans une transaction
- evtl. Points de contrôle
Structure du Journal avant l’image Dans le fichier de protocole [ Modifier | Modifier le texte source ]]
- La marque pour le début d’une transaction contient l’identification de la transaction en même temps
- Une copie de la condition avant le changement, composé d’identification et de contenu; De plus, le T-ID
- Marque pour la fin d’une transaction (avec T-ID)
- La création de l’image avant dans le fichier journal doit être effectuée avant la modification de la base de données.
- Après avoir terminé avec succès une transaction, les informations associées dans le Journal avant Image ne sont plus nécessaires, elles peuvent être supprimées ou écrasées.
- L’image avant n’est requise que pour un retour en arrière.
Structure du Journal après-image Dans le fichier de protocole [ Modifier | Modifier le texte source ]]
- La marque pour le début d’une transaction contient l’identification de la transaction en même temps
- Pour chaque objet modifié / nouvellement inséré, une copie de la condition après le changement, composé d’identification et de contenu; De plus, le T-ID
- Marque pour la fin d’une transaction (avec T-ID)
- Après avoir terminé avec succès une transaction, les informations associées doivent être conservées dans le journal après l’image.
- L’After-Image sert à restaurer les transactions complètes après une perte de données due aux erreurs matérielles ou logicielles.
Structure du Points de contrôle Dans le fichier de protocole [ Modifier | Modifier le texte source ]]
- CheckPointmarker
- Entrée pour chaque fichier ouvert, pas encore écrit
- Marque pour chaque transaction non complète (avec T-ID)
- Les points de contrôle ne sont requis que pour une récupération du système après une erreur matérielle ou logicielle (reprise après sinistre)
À Perte La base de données actuelle en est une Restauration possible comme suit:
- Le Journal avant l’image Lire à l’envers dans le fichier de protocole
- Pour chaque objet modifié, c’est-à-dire H. Chaque entrée avec l’identification de transaction correspondante, l’ancien contenu est renvoyé du fichier journal dans la base de données.
Le processus se termine en lisant la marque pour le début de la transaction correspondante.
Avec une reprise après sinistre, le système doit déterminer les points de contrôle:
- Recherchez le dernier point de contrôle, qui ne contient que des transactions ouvertes qui se terminent par un point de contrôle ultérieur
- Déterminer tous les fichiers ouverts et incontestés
- Incorporer tout après les images de transactions terminées qui n’étaient pas écrites physiquement
Avec des copies de sécurité, les données peuvent également être restaurées après une perte totale.
- Effondrement du système en raison des défauts matériels
- Effondrement du système en raison d’erreurs logicielles
- Troubles de fonctionnement inattendus, par ex. B. Échec du réseau
- Erreurs mécaniques, par ex. B. Fixations de tête dans les entraînements de plaques magnétiques
- Violence externe, par ex. B. Feu, explosion, inondation
- L’action de sabotage
Recent Comments