Resolve the concept of DB2 database Restoration

DB2 database recoveryWhat is it like? If you are a beginner, the following content will help you a lot. Then let me lead youDB2 database recoveryWorld.

Recovery scenario

You will never know when your system will encounter a disaster or fault. Therefore, it is best to prepare early, not only to prevent data from being affected by external factors, but also to prevent internal users from inadvertently damaging your database with incorrect information.

Have you backed up your database? Can you restore all the transactions that have been executed until the last second?

To minimize data loss, a recovery policy is required to ensure that the policy is feasible and to be continuously tested. You should consider the following recovery scenarios:

Recovery Policy

To develop a recovery policy, you should ask yourself the following questions:

Transactions

A unit of work (UOW), also known as a transaction, consists of one or more SQL statements, and finally a COMMIT or ROLLBACK statement. All the statements in this UOW are considered as a unit to ensure data consistency. For example, a customer tries to transfer $100 from a savings account to a check account. In this case, UOW is like this:

DELETE 100 dollars from SAVINGS account

INSERT 100 dollars to CHECKING account

COMMIT

If these statements are not treated as a unit, you can imagine what will happen if a hardware fault occurs after the DELETE statement or before the INSERT statement: the customer will lose $100. However, if these statements are treated as a unit, this will not happen. DB2 will know that this unit is not completed (COMMIT), so it will roll back all the changes made in the previous statement and return the affected rows to the status before the start of the transaction.

No statement is used to identify the start of a transaction. The statement after COMMIT or ROLLBACK starts a new transaction.

Recovery Type

Let's familiarize ourselves with the concepts of recovery types. DB2 allows the following types of recovery:

1. Emergency Recovery

Uncommitted transactions are undone (rolled back) to restore the database in an inconsistent state to a consistent state. Consider the example in the previous screen again. If a power failure occurs before the COMMIT statement, DB2 will first roll back the INSERT statement and then roll back the DELETE statement when DB2 restarts and accesses the database next time. (The order of rollback statements is the opposite to that of the statements that were originally executed .)

　 2. Version recovery

Allows you to use a BACKUP image obtained from the BACKUP command to restore the database of the previous version. The recovered database contains information about the status of the database when the BACKUP command is executed. If a new activity is executed after the backup, the information will be lost.

　 3. Roll Back and restore

This type of recovery combines complete database backup and log files, thus expanding version recovery. Before using a backup as the benchmark, you must first store the backup and then apply the log on the backup. This process allows you to restore the database or tablespace to a specific time point. Archive logging must be enabled for rollback and recovery. Archive logging is discussed in the log record type.
 

Summary:

1. When restoring the DB2 remote DB2 database, you must first create the corresponding directories, data file directories, log directories, and archive log directories.

2. When you need to view logs when an operation fails, try to view the old logs as much as possible because it takes more time to view logs in real time.