Experience in restoring the DB2 database

Today, we will describe some practical operations of the DB2 database recovery experience. We just started the DB2 database recovery test a few days ago, and we can't think of it so quickly. So whenever you find that a technology may be used, but you haven't done it yet, you must start it immediately. Maybe it will be used that day.

That afternoon, I suddenly received a call from the Project Manager, saying that a table in the production database was deleted by the Engineer and expected to be restored in the test environment. At that time, I first felt that there was not enough space for the test environment. The total space allocated by the tablespace in the production database is less than GB. However, the space used is less than 50 GB. At that time, I suspected that DB2's recovery should be similar to oracle's rman recovery, which directly performs physical recovery. Restore the tablespace directly. Therefore, a space of about GB is required.

The test environment certainly does not have such a large space, but it is not completely certain. Try to restore it. An error is reported. After reading it, it means that a path does not have the permission to read and write data. After reading it carefully, it is the path where the tablespace files in the production database are stored. The original DB2 recovery can only be restored to the original path. Create a file system. Again, an error is reported. If the log directory does not exist, create a file system and restore it. An error is also reported. This time it is the directory for archiving logs, and then it is created and restored.

 
 

  
  
DB2 RESTORE db abc FROM /DB2/data/bk taken at 20100517000001 
 
 

The results show that some tablespaces have not been restored successfully, but the overall DB2 database has been restored successfully.

Copy the required archived logs to the (/DB2/data/bk/log/) directory for rollback.

 
 

  
  
DB2 "rollforward db abc to end of logs and stop overflow log path(/DB2/data/bk/log/)" 
 
 

Error

 
 

  
  
SQL1218N There are no pages currently available in bufferpool "". 
 
 

I think it should be a problem in the recovery process. Check the DB2 log. The log is too large to be viewed. Therefore, you can restore the log and monitor the log output in real time. It is found that the error of holding a disk full when restoring some tablespaces. The problem should be located, that is, the disk space is insufficient. However, the disk space in the test environment cannot be GB. What should I do?

In the end, there is no way. On the magnetic array of the production database, a GB nfs is built for the test environment, and then the DB2 database is restored. An error is reported during the process, that is, the usage of the tablespace exceeds the threshold, because the usage of some tablespaces is 100%, and you do not know whether the tablespaces are useful ........

It took about an hour to recover GB of data. Roll back again and still report an error

 
 

  
  
SQL1218N There are no pages currently available in bufferpool "". 
 
 

Strange! I searched the internet and some people encountered the same problem. Recommended Parameter Modification

 
 

  
  
DB2set DB2_OVERRIDE_BPF=1000， 
 
 

Then restart DB2,

Indeed, DB2 can log on successfully even if the rollback is successful.

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.