Database Chapter 10 Database recovery Technology

Tenth. Database recovery Technology

This paper introduces the basic concept of transaction and the nature of transaction, and explains the recovery technique and method after the failure of database system.

A transaction is a series of database operations, the basic logical unit of a database application, and an inseparable unit of work.

Transactions and programs are two concepts, in general, a program contains multiple transactions.

Transaction processing technology mainly includes database recovery technology and concurrency control technology.

Transactions have four characteristics: atomicity (atomicity), consistency (consistency), isolation (isolation), and persistence (durability), which are referred to as ACID properties.

Atomicity: The logical working unit of a database when a transaction is made, and the operations included in the transaction are either done or not.

Consistency: The result of a transactional execution must be to change the database from one consistent state to another, so that when the database contains only the results of a successful transaction submission, the database is in a consistent state.

Isolation: The execution of one transaction cannot be disturbed by other transactions, that is, the operations within one transaction and the data used are isolated from other concurrent transactions, and the transactions performed concurrently cannot interfere with each other.

Persistence: When a transaction is committed, its changes to the data in the database should be permanent. The next operation or failure should not have any effect on its execution results.

Transactions are the basic unit of recovery and concurrency control.

Factors that may be damaged by the acid properties of the transaction are:

1) When multiple transactions are running concurrently, the operations of different transactions are executed in parallel;

2) The transaction is forcibly stopped during operation.

In the first case, the database management system must ensure that the cross-running of multiple transactions does not affect the atomicity of these transactions; in the second case, the database management system must ensure that the forced termination of the transaction has no effect on the database and other transactions. This is the responsibility of the recovery mechanism and concurrency control mechanism in the database management system.

Types of faults:

A failure within a transaction (a forced rollback using rollback, which revokes any modifications that the transaction has made to the database, so that it does not appear to be started, is called transaction revocation (undo))

System failure

Media failure (System fault is called soft fault, media fault is called hard fault)

Computer viruses

The impact of various types of failures on the database has two possibilities, one is that the database itself is destroyed, and the second is that the database is not corrupted, but the data may be incorrect, because the operation of the transaction is not properly terminated.

Recovery: Redundancy, where any part of the database is corrupted or incorrect data can be rebuilt based on redundant data stored elsewhere in the system.

The two key questions of the recovery mechanism design are: first, how to build redundant data, and secondly, how to use these redundant data to implement database recovery.

The implementation technology of recovery

Data dumps

Data dumps are the basic technique used in database recovery, where a DBA periodically copies an entire database to a tape or another disk. Dumps are time-consuming and resource-intensive and cannot be carried out frequently.

Dumps can be divided into static dumps and dynamic dumps.

A static dump is a dump operation that occurs when a transaction cannot be run in the system. Dynamic dumps are those that allow access or modification to the database during a dump, that is, dumps and user transactions can execute concurrently.

A mass is a dump of all databases at a time, and an increment is one that dumps only the data that has been updated since the last dump.

Level log file (Logging)

Log files are files that are used to record transaction-to-database update operations, and different database systems use the same log file format, mainly in two ways: log files that are recorded as units and log files in blocks of data.

Log files that are recorded as a unit include:

Beginning of each transaction (begin TRANSACTION) tag

End of each thing (commit or rollback) mark

All update actions for each thing

The contents of each log record mainly include:

Transaction ID (which transaction is indicated)

Type of operation (insert, delete, or modify)

Manipulating objects (recording internal identities)

Old value of pre-update data (this is a null value for insert operations)

The new value of the updated data (this is a null value for the delete operation)

The log file in blocks of data, including the transaction ID and the data block being updated.

The role of the log file:

Log files play a very important role in database recovery, and can be used for transactional and system failure recovery, and to assist the backup copy for media failure recovery, with the following functions:

1) Transaction failure recovery and system recovery must be using log files

2) in the dynamic dump mode must establish a log file, backup copy and log files together in order to effectively restore the database.

3) in the static dump mode, you can also create a log file.

Registering log files

To ensure that the database is recoverable, you must follow two principles when registering a log file:

1) The Order of registration is strictly based on the time sequence of concurrent transaction execution;

2) The log file must be written before the database is written.

Recovery strategy

Recovery of transactional failures

A transaction failure is the termination of a thing before it runs to the normal termination point, which is the recovery subsystem's use of the log file revocation (undo) The transaction has been modified by the database, and the recovery of the transaction failure is automatically done by the system.

Recovery of system failures

Recovery of media failures

Database Mirroring

Database mirroring capabilities: Automatically replicate the entire database or key data on another disk, as required by the DBA.

Database Chapter 10 Database recovery Technology