仙道彰
作者仙道彰2017-08-08 15:18
数据库开发工程师, 花旗集团

DB2数据库指定时间点恢复案例

字数 3905阅读 2397评论 2赞 6

公司一生产环境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数据库备份恢复的概念和知识点

备份类型:脱机备份(也称冷备份或离线备份)、联机备份(也称热备份或在线备份)、完全备份、增量备份(也称累积备份)、差异备份

-----------------------------------------------------『非原创』

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论2 条评论

penguin23penguin23系统运维工程师, 广州佳杰科技有限公司
2017-08-18 16:53
应该是老的文章咯
mytribalmytribal数据库管理员, DB2
2017-08-18 16:35
好资料
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广