Database Principles Chapter 10---Database Recovery Technology

1. Basic concepts of business

Affairs

The so-called transaction is a user-defined sequence of database operations. These operations are either all done or not done, which is an indivisible unit of work.

The start and end of the transaction can be displayed and controlled by the user. If the user does not display the defined transaction, the database management system automatically divides the transaction according to the default regulations.
There are generally three statements for defining transactions in SQL:

-- 开启事务
BEGIN TRANSACTION;
-- 事务提交
COMMIT
-- 事务回滚
ROLLBACK

Transaction characteristics ACID

Transaction has four characteristics: Atomicity, Consistency, Isolation, Durability

Atomicity

A transaction is the logical unit of work of the database. The operations included in the transaction are either all done or not done (attention status: either success or failure, there is no partial success status).

consistency

Consistency also means that the operations included in the transaction either succeed or fail. This looks the same as atomicity. But the difference between consistency and atomicity is that consistency focuses on the visibility of data. The data in the intermediate state is invisible to the outside, and only the data in the initial state and the final state is visible to the outside. For example, if A wants to transfer 100 from the bank to B, the atomicity is about whether the entire operation is executed correctly and successfully, while the consistency is about whether the account A is successfully deducted, whether the account B is successfully credited, and the account A should be the same as the account. B is consistent.

Isolation

The execution of a transaction cannot be interfered by other transactions.

Persistent

Persistence is also called permanent, which means that once a transaction is committed, the changes to the data in the database will be permanent.

2. Types of failure

Although various measures have been taken in the database system to prevent the security and integrity of the data from being destroyed, and to ensure the correct execution of concurrent events. But some failures are inevitable. The possible faults in the database can be roughly divided into the following categories.

• Internal failure of the transaction: The internal failure of the transaction is unexpected and cannot be handled by the application program, such as operation overflow, concurrent transaction, etc.
• System failure: System failure refers to any event that causes the system to stop functioning, causing the system to restart
• Media failure: System failure is called soft failure, and media failure is called hard failure (hard disk damage, magnetic field interference, etc.).
• computer virus

3. Recovery realization technology

The two key issues involved in the recovery mechanism are: how to create redundant data, and how to use these redundant data to achieve database recovery. The most commonly used techniques for creating redundant data are data dumping and registering log files .

Data dump

Data dump is the process by which the database administrator regularly backs up the entire database. These backed-up data are called backup copies or backup copies.
Dump can be divided into static storage and dynamic storage.

• Static storage is a dump operation when there are no running transactions in the system, and a complete copy of the data can be obtained.
• Data can be modified during dynamic storage, that is, dumping and user transactions can be performed concurrently. There is no guarantee that the data obtained is accurate and valid.

The two methods of data storage can be performed in two ways respectively:

Mass dump: dump all databases each time
Incremental dump: dump only the updated data after the last dump,
mass dump and incremental dump Comparison
From the perspective of recovery, it is often more convenient to use backup copies obtained from massive dumps for recovery.
If the database is large and transaction processing is very frequent, the incremental dump method is more practical and effective.

Registration log file

1. Format and content of log files

The log file is used to record the update operation of the transaction to the database. The log file format used by different databases is not exactly the same. Before it there are two formats: in recording units of log files and the data block in units of log files .

The content that needs to be registered in the log file based on the record includes:

• Start mark of each transaction (BEGIN TRANSACTION)
• The end of each transaction (COMMIT or ROLLBACK)
• All update operations of each transaction
  are treated as a log record in the log file.

The content of each log record includes the following:

• Transaction ID (indicating which transaction is)
• Operation type (insert, delete or modify)
• Operation object (record ID, Block NO.)
• The old value of the data before the update (for insert operations, this is a null value)
• The new value of the updated data (for delete operations, this item is empty)

---

For the log file with data block as the unit, it includes: transaction identifier and updated data block

2. The role of log files

Logs can be used for transaction failure recovery and system failure recovery in data recovery. Specific functions:

• Transaction failure recovery and system failure recovery must use log files.
• In the dynamic dump mode, a log file must be established, and the backup copy and the log file can be combined to effectively restore the database.
• Logs can also be used in static dumps to ensure that the data is restored to the correct state at a certain moment.

3. Registration log files

To ensure that the database is recoverable, two rules must be followed when registering log files:

• The order of registration strictly follows the time sequence of concurrent transaction execution.
• The log file must be written first, followed by the database

Why do we need to write the log first and then write the database?
Because writing to the log and writing to the database are two different operations, a failure may occur between these two operations, that is, only one of the two operations is completed. That is, the database is written first, but the log is not written. In this case, the modification cannot be restored later.

4. Recovery strategy

When a failure occurs while the system is running, you need to use copy and log recovery, but it should be noted that different failure recovery strategies and methods are different.

Transaction failure recovery

This kind of failure means that the transaction is stopped before it runs to the normal end. At this time, the recovery subsystem should use the log file to undo the modifications that the transaction has made to the database.
The recovery steps are:

• Scan the log in the reverse direction to find the update operation of the transaction
• Do the following operations on the updated value: insert operation -> delete insert data, modify operation -> replace the post value with the modified value before, delete operation -> insert operation.
• Until you read the mark corresponding to the beginning of the transaction

System failure recovery

There are two reasons for the inconsistent state of the database due to system failure: one is that the data has been written into the database by the unfinished transaction, and the other is that the data update by the committed transaction may still be left in the cache. The solution is to undo the transactions that were not completed when the failure occurred and redo the completed transactions.
Recovery steps:

• Scan the log forward to find out the transactions that have been committed before the failure occurs, record their identifiers in the redo queue, find out the transactions that have not been completed when the failure occurs, and identify the record cancellation queue
• Cancel each transaction in the cancel queue
• Redo each transaction from the left queue

Media failure recovery

After a media failure occurs, the physical data and log data files on the disk are destroyed. This is the most serious type of failure. The recovery method is to reinstall the database and then redo the completed transactions.

5. Recovery technology with checkpoint

The recovery subsystem using log technology must search the log to determine which transactions need to be redone and which need to be undone, which will waste a lot of time. To solve this problem introduces checkpoint record , recording an increase of the checkpoint file a new start, and to allow dynamic recovery subsystem to maintain a log during the log in the log file.

The checkpoint record includes:

• Establish a list of all tasks being executed at the time of checkpoint
• The address of the most recent log record of these transactions

The method of dynamically maintaining the log is to periodically perform the operations of establishing checkpoints and saving the database status. Specific steps are as follows:

• Write all log records in the current log buffer to the log file of the disk
• Write a checkpoint record in the log file
• Write all data records in the current data buffer to the disk database
• The address of the checkpoint recorded in the log file is written into a restarted file. The
  recovery subsystem can set checkpoints regularly or irregularly, or set checkpoints according to certain rules to save the database state.

Subsystem recovery strategy:

• Commit the transaction before the checkpoint. In this case, the data has been written to the database and no processing
• Commit between the checkpoint and the system failure. In this case, the database may not be written into the database in the buffer and needs to be redone.
• If the transaction has not been submitted at the time of the failure, the transaction will be cancelled.

The undo log is used to record the state before the transaction starts and is used for rollback operations when the transaction fails; the redo log records the state after the transaction is executed, and is used to restore the data updated by the successful transaction that has not been written to the data file.

The system uses the checkpoint method to restore the steps:

• Find the address of the last checkpoint recorded in the log file from the restart file, and find the record of the last checkpoint in the log file by changing the address.
• The checkpoint record gets the active-list of all the transactions in execution at the time the checkpoint is established. Establish two transaction queues
  -UNDO-LIST
  -REDO-
  LIST temporarily put ACTIVE-LIST into UNDO-LIST queue, REDO queue is temporarily empty.
• Scan the log file forward from the checkpoint until the end of the log file
  -if there is a newly started transaction Ti, temporarily put Ti in the UNDO-LIST queue
  -if there is a committed transaction Tj, move Tj from the UNDO-LIST queue to REDO -LIST queue; until the end of the log file
• Perform UNDO operations on each transaction in UNDO-LIST, and perform REDO operations on each transaction in REDO-LIST

Advantages of using checkpoints: shorten the scan log time to improve recovery efficiency

6. Database mirroring

Database mirroring is a good solution to media failure, that is, preparing multiple hard disks and using database mirroring to back up data from one hard disk to multiple hard disks in real time.