【技术维新 践行精彩】DB2数据库指定时间点恢复实战解析
公司一生产环境AIX主机上的DB2数据库，由于开发人员的误操作，造成一个重要表的被删除，需要进行恢复。为了安全，不能在生产环境的数据库上进行操作，需要放到测试环境进行恢复。
问了一下开发人员，表被删除的时间为5月31日下午8点30分左右，现在已是晚间10点50分了，距离事故发生时间点已过去两个多小时，根据安全等级规定需要在一个小时内进行恢复。这种状况的恢复是典型的前滚恢复，需要使用完整的数据库备份和日志相结合，然后将数据库或者被选择的表空间恢复到某个特定时间点。如果从备份时刻起到发生故障时的所有日志文件都可以获得的话，则可以恢复到日志上涵盖到的任意时间点。
首先检查了一下数据库的备份情况，上周日有一个完整备份，从完整备份到故障点的所有日志都完好的存在，心里总算松了一口气。
接下来在测试环境找一台与生产环境DB2数据库版本一致的AIX小机，把完整数据库备份和相应日志传输过来。（注：不同的数据库版本，物理日志格式不一样，在做恢复的时候容易报SQL2547错误，从而不能前滚日志）从生产环境传输到测试环境的完整备份和日志，大家要注意修改文件的属主和权限，以避免无法读取的错误。
一、进行完整备份的恢复
使用SECURE CRT进入测试环境的AIX小机
$ db2 connect to banoab (测试环境和生产环境的数据库名是一样的)
Database Connection Information
Database server = DB2/AIX64 9.1.7
SQL authorization ID = DB2INST1
Local database alias = BANOAB
$ 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 banoab from /backup taken at 20130526190620 to /home/db2inst1
DB20000I The RESTORE DATABASE command completed successfully.
二、前滚日志到指定时间点
$ db2 connect to banoab
SQL1117N A connection to or activation of database "BANOAB" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019
连接还原后的库，提示需要前滚日志，接下来将数据库前滚至删除前的那个时间点
/backup/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）恢复的唯一方法。
前滚的时间要在最小恢复时间点之后，最后的事务提交时间点之前。
本文出自 “狂奔的蜗牛” 博客，谢绝转载！