Rollback
As rollback (from the English "rollback" to "roll back" or "turn back") is known in computer systems, the "resetting" of the individual processing steps of a transaction . The system is completely restored to the state it was in before the transaction began.
A rollback is typically triggered in the event of an error, for example if a processing step in the relevant transaction cannot be carried out correctly. In the normal process (without an error situation) the changes to the transaction are made permanent with a " commit ".
Rollbacks play an important role especially in connection with database systems and other transactional systems. A transaction is a sequence of related operations on a database. A transaction can transfer the database from one consistent state to another consistent state. The consistency rules of a database can be switched off during the transaction . In order to guarantee the consistency of the database, transactions must always be carried out in full or not at all (see ACID principle ). The incomplete execution of a transaction, e.g. B. due to a system failure, will roll back the transaction.
In addition to the redo, the rollback is a measure for data backup ("recovery measure"). It aims to avoid inconsistencies.
Comprehensive data backup is only possible if a log is kept for every transaction. This log is also called a journal, logfile or audit trail. Because of the sequential (chronological) recording of the changes, a sequential file is recommended here.
Content of the log file (logfile)
- before-image-journal
- Logging of the status before the change for all changes to objects made in a transaction
- after-image-journal
- Logging of the status after the change for all changes to objects made in a transaction
- possibly checkpoints
Structure of the before-image-journal in the log file
- Mark for the beginning of a transaction, also contains the identification of the transaction
- for each changed / deleted object (usually: each sentence, line, tuple) a copy of the status before the change, consisting of identification and content; plus the T-ID
- Mark for the end of a transaction (with T-ID)
- The creation of the before-image in the log file must take place before the change in the database.
- After a transaction has been successfully completed, the associated information in the before-image journal is no longer required; it can be deleted or overwritten.
- The before-image is only required for a rollback.
Structure of the after-image journal in the log file
- Mark for the beginning of a transaction, also contains the identification of the transaction
- for each changed / newly inserted object a copy of the status after the change, consisting of identification and content; plus the T-ID
- Mark for the end of a transaction (with T-ID)
- After the successful completion of a transaction, the associated information must be kept in the after-image journal.
- The after-image is used to restore completed transactions after data loss due to hardware or software errors.
Structure of the checkpoints in the log file
- Checkpoint markers
- Entry for every open file that has not yet been written
- Token for each incomplete transaction (with T-ID)
- Checkpoints are only required for a system recovery after a hardware or software failure (disaster recovery)
Restoration
With loss of the current database is a recovery possible as follows:
- The before-image-journal in the log file is read backwards
- For each changed object, i. H. every entry with the corresponding transaction identification, the old content is written back from the log file to the database.
The process ends by reading the label for the start of the corresponding transaction.
In the event of a disaster recovery, the system must determine the checkpoints:
- Search for the most recent checkpoint, which only contains open transactions that have ended in a later checkpoint
- Find all open, not written files
- Incorporation of all after-images of completed transactions that were not physically written
Together with backup copies, data can also be restored after a total loss.
Causes of loss of data
- System crashes as a result of hardware defects
- System breakdowns as a result of software errors
- unexpected malfunctions, e.g. B. Power failure
- mechanical errors, e.g. B. Heads on magnetic disk drives
- external force, e.g. B. Fire, explosion, flood
- Acts of sabotage