Rollback (data management)

As a rollback ( from the English " rollback " for " roll back " or " turn back " ) is referred to in computerized systems, the " reset " of the individual processing steps of a transaction. The system is characterized completely returned to the state before the transaction began.

A rollback is typically triggered in the event of an error, for example, if a processing step in the transaction in question can not be performed correctly. In the normal course (without error situation ) be made permanent with a " commit " the changes of the transaction.

Rollbacks play an important role, especially in the context of database systems and other transactional systems. A transaction is a sequence of related operations here on a database. In this case, a transaction can transfer the database from one consistent state to another consistent state. During the transaction, the consistency rules in a database can be switched off. To ensure the consistency of the data base, transactions must always be executed completely or not (see ACID principle ). The incomplete execution of a transaction, for example, due to a system error, leads to rollback the transaction.

The rollback is next to the Redo an action for backup ( " recovery action"). It aims to avoid inconsistencies.

A full backup is possible only if for each transaction log is kept. This protocol is also called Journal, logfile or audit trail. Because of the sequential ( chronological ) record of changes here offers a sequential file.

Contents of the log file ( logfile )

Structure of the before -image journal in the log file

  • Mark for the beginning of a transaction, at the same time contains identification of the transaction
  • For each altered / deleted object (usually: every sentence, line, tuple ) a copy of the state before the change, consisting of identification and content; to the T-ID
  • Brand for the end of a transaction ( T- ID)

Structure of the after- image -journal in the log file

  • Mark for the beginning of a transaction, at the same time contains identification of the transaction
  • For each modified / newly inserted object is a copy of the state after the change, consisting of identification and content; to the T-ID
  • Brand for the end of a transaction ( T- ID)

Structure of the checkpoints in the log file

  • Checkpoint marker
  • Entry for each that is not yet written file
  • Mark for each non- completed transaction ( T- ID)

Restoration

If you lose the current data base recovery is possible as follows:

  • The before -image journal in the log file is read backwards
  • For each modified object, that is, each entry with the appropriate transaction identification, the old contents of the log file is written back to the database.

The process terminates itself by reading the mark for the beginning of the transaction.

In a disaster recovery, the system must determine the checkpoints:

  • Search for the most recent checkpoint, which contains only open transactions that are completed in a later checkpoint
  • Determine all open, non- written files
  • Incorporation of all after -images of completed transactions that have not been physically written

Together with backup data may also be prepared by a total loss again.

Causes for the loss of data

  • System failures due to hardware failure
  • System failures due to software errors
  • Unexpected equipment failure, for example, power failure
  • Mechanical failures, such as head bouncing in magnetic disk drives
  • External forces, such as fire, explosion, flood
  • Sabotage actions
Commit (data management) Deadlock
24626
de