如何进行DB2数据库指定时间点恢复的分析

今天就跟大家聊聊有关如何进行DB2数据库指定时间点恢复的分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

创新互联是一家专注于网站设计制作、成都网站建设与策划设计,大丰网站建设哪家好?创新互联做网站,专注于网站建设十多年,网设计领域的专业建站公司;建站业务涵盖:大丰等地区。大丰做网站价格咨询:18980820575

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

备份类型:脱机备份(也称冷备份或离线备份)、联机备份(也称热备份或在线备份)、完全备份、增量备份(也称累积备份)、差异备份
如何进行DB2数据库指定时间点恢复的分析

数据库备份文件结构

如何进行DB2数据库指定时间点恢复的分析

恢复类型:崩溃恢复、版本恢复、前滚恢复(任意时间点恢复,恢复到最近时间点)

恢复情形:完全恢复、不完全恢复

手动恢复数据库的顺序

日志类型:循环日志(默认)、归档日志(活动日志、在线归档日志、离线归档日志)

日志类型与恢复类型:循环日志只支持崩溃恢复和版本恢复,归档日志支持所有类型的恢复

凡是联机备份产生的备份集在恢复时都需要使用归档日志,归档日志方式是是允许用户执行前滚(rollforward)恢复的唯一方法。

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

看完上述内容,你们对如何进行DB2数据库指定时间点恢复的分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


文章标题:如何进行DB2数据库指定时间点恢复的分析
分享网址:http://pwwzsj.com/article/pssgph.html