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）恢复的唯一方法。

 

前滚的时间要在最小恢复时间点之后，最后的事务提交时间点之前。