The DB2 database on the AIX host in a production environment of the company, due to the misoperation of the developer, caused an important table to be deleted and needs to be restored. For security, operations cannot be performed on the database in the production environment, and it needs to be placed in the test environment for recovery.
I asked the developer, the time when the watch was deleted was around 8:30 pm on May 31st, it is now 10:50 pm, and more than two hours have passed since the accident happened. According to the requirements of the security level Recovery within an hour. Recovery in this situation is a typical rollforward recovery, which requires the use of a full database backup combined with the log, and then restores the database or selected tablespace to a specific point in time. If all log files are available from the time of backup until the time of the failure, recovery to any point in time covered on the log is possible.
First of all, I checked the backup of the database. There was a full backup last Sunday. All logs from the full backup to the point of failure were intact. I was finally relieved.
Next, find an AIX computer in the test environment with the same version of the DB2 database in the production environment, and transfer the complete database backup and corresponding logs. (Note: Different database versions have different physical log formats. It is easy to report SQL2547 errors during recovery, so the log cannot be rolled forward.) For complete backups and logs transferred from the production environment to the test environment, you should pay attention to modifying the attributes of the files. master and permissions to avoid unread errors.
1. Restoring a full backup
AIX computer that uses SECURE CRT to enter the test environment
$ db2 connect to banoab (the test environment and the production environment have the same database name)
Database Connection Information
Database server = DB2/AIX64 9.1.7
SQL authorization ID = DB2INST1
Local database alias = BANOAB
$ db2 force applications all (kill all application connections)
DB20000I The FORCE APPLICATION command completed successfully.
DB21024I This command is asynchronous and may not be effective immediately.
$ db2 drop db banoab (remove test environment library)
DB20000I The DROP DATABASE command completed successfully.
(Restore the full backup repository from the location where the production repository is stored)
$ db2 restore db banoab from /backup taken at 20130526190620 to /home/db2inst1
DB20000I The RESTORE DATABASE command completed successfully.
2. Roll forward the log to a specified time point
$ db2 connect to banoab
SQL1117N A connection to or activation of database "BANOAB" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019
Connect to the restored library, prompting you to roll forward the log, and then roll forward the database to the point in time before the deletion
/backup/logs is the storage directory for the production library logs
$ db2 "rollforward db banoab to 2013-05-31-20.00.00.000000 using local time and complete overflow log path (/backup/logs)"
Rollforward Status
Input database alias = banoab
Number of nodes have returned status = 1
Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0001593.LOG - S0001683.LOG
Last committed transaction = 2013-05-31-20.00.00.000000 Local
DB20000I The ROLLFORWARD command completed successfully.
前滚日志成功，告知开发人员进行检查
过了一会，开发人员反馈说没有查到数据，仍然是删除后的状态。
这回有点纳闷了，怎么可能会没有，时间已过去了半个小时，真是让人着急啊
心里有点怀疑，会不会是两个小机的时间不一致啊，因为前滚时用的是local time
立即检查两个小机的时间
Sun Jun 4 15:43:47 BEIST 2013 （生产机时间）
Sun Jun 4 15:44:01 CDT 2013 （测试机时间）
注意红色部分，BEIST和CDT并不是同一个时区，BEIST与CDT之间相差8个小时。因为时区的不一致导致时间不统一，所以出现了问题。
那么怎么把AIX的CDT时间显示方法改为BEIST呢？方法如下
smitty => System Environments => Change / Show Date and Time
=> Change Time Zone Using User Inputted Values
然后修改成这样：
Standard Time ID(only alpahabets) [BEIST]
* Standard Time Offset from CUT([+|-]HH:MM:SS) [-8]
Day Light Savings Time ID(only alpahabets) [] --注意这里为空
然后再重新恢复一次
$ db2 force applications all
DB20000I The FORCE APPLICATION command completed successfully.
DB21024I This command is asynchronous and may not be effective immediately.
$ db2 drop db banoab
DB20000I The DROP DATABASE command completed successfully.
$ db2 restore db banzub from /backup taken at 20130526190620 to /home/db2inst1
DB20000I The RESTORE DATABASE command completed successfully.
$ id - db2inst
uid=301(db2inst1) gid=301(db2grp1) groups=1(staff)
$ db2 connect to banoab
SQL1117N A connection to or activation of database "BANOAB" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019
$ db2 "rollforward db banoab to 2013-05-31-20.00.00.000000 using local time and complete overflow log path (/backup/logs)"
Rollforward Status
Input database alias = banoab
Number of nodes have returned status = 1
Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0001593.LOG - S0001679.LOG
Last committed transaction = 2013-05-31-20.00.00.000000 Local
DB20000I The ROLLFORWARD command completed successfully.
再检查，果然数据有了，表也恢复了，一切OK
总结：做数据恢复时，一定要冷静沉着，遇到问题要会分析，懂技术并分析到位才能力克困难。
附：DB2数据库备份恢复的概念和知识点
备份类型：脱机备份（也称冷备份或离线备份）、联机备份（也称热备份或在线备份）、完全备份、增量备份（也称累积备份）、差异备份
数据库备份文件结构
恢复类型：崩溃恢复、版本恢复、前滚恢复（任意时间点恢复，恢复到最近时间点）
恢复情形：完全恢复、不完全恢复
手动恢复数据库的顺序
日志类型：循环日志（默认）、归档日志（活动日志、在线归档日志、离线归档日志）
日志类型与恢复类型：循环日志只支持崩溃恢复和版本恢复，归档日志支持所有类型的恢复
凡是联机备份产生的备份集在恢复时都需要使用归档日志，归档日志方式是是允许用户执行前滚（rollforward）恢复的唯一方法。
前滚的时间要在最小恢复时间点之后，最后的事务提交时间点之前。