D_db2重定向恢复+日志前滚，恢复误删除的数据

重定向恢复+日志前滚，恢复误删除的数据

转自：http://www.db2china.net/home/space.php?uid=124595&do=blog&id=31751

使用恢复+前滚的方式追回误删除的数据2013-12-12 10:42阅读(1175)

（转载）

<!--

分享</div>-->

2103年12月05号中午12点，本人在兰州拉面馆正准备享用一碗红烧牛肉面，电话响了。某医院的DBA告诉我有一张关键表的数据被误操作，数据惨遭清理，需要我急速赶赴现场处理。

快速吃完面，打车赶往现场。根据平时的巡检，我知道这个库的基本信息，版本是 V9.1.8，系统是AIX 5.3，大概300G，开启了归档模式，并且会每周进行一次全备，每天增量备份，都是在晚上22:30进行。

到达现场，跟客户简单交流后，确定在测试机使用恢复加前滚的方式追数据。Let's do it ~

一、搭建测试机：

     客户提供的系统环境中安装了V9.7，但是没有V9.1版本，由于V9.1的备份介质不能直接在V9.7上进行恢复，所以需要安装V9.1版本，于是要求提供db2 9.1.8的安装介质（因为牵涉到license
问题，所以一定要客户提供，而且客户方一般都有安装光盘的）  。客户方保管介质的工程师找了好久都没有找到光盘，为此被领导批评了。在费了九牛二虎之力后，总算是解决了介质问题。  

     观察测试机的存储，发现根本不够，空闲空间只有不到100G。根据备份介质的大小和表空间高水位，提出需要增加800G存款空间的要求。客户方工程师迅速完成了存储扩容。

     

     于是在测试机上安装了DB2 V 9.1.8 for AIX ；

     创建用户和组：

mkgroup id=550 db2iadm9 mkgroup id=551 db2fadm9 mkgroup id=552 dasadm9 mkuser id=550 pgrp=db2iadm9 home=/home/db2inst9  groups='staff' db2inst9 mkuser id=551 pgrp=db2fadm9 home=/home/db2fenc9  groups='staff' db2fenc9 mkuser id=552 pgrp=dasadm9 home=/home/db2das9  groups='staff' db2das9

     创建实例db2inst9.在创建实例时碰到以下错误：

root@CIS02#./db2icrt -u db2fenc9 db2inst9 The file access permissions do not allow the specified action. ksh: /dev/null: 0403-005 Cannot create the specified file. cat: cannot open /tmp/db2icrt.tmp1.291226 DBI1281E The database manager configuration file could not be initialized.

     这是权限不够问题，我将 /dev/null 和 /tmp都改成了777，重建就OK了。

具体请参见：http://www-01.ibm.com/support/docview.wss?uid=swg21598091

     通过使用ftp的方式将备份介质上传到测试机上；

(将文件传到B机：在A机上ftp <B机IP>，输入user/passwd,cd到目标目录，put 文件名；目录的话，可以先关闭交互模式prompt off ,mput *)

     通过ftp的方式将需要用到的归档日志上传到测试机；

二、恢复+前滚：

     在源库中使用以下语句生成重定向脚本：

db2 "restore db <dbname> from '<dir>' taken at <timestamp> into <dbname> redirect generate script  redirect.ddl "

     修改重定向脚本，注意表空间的高水位线，每个表空间大小不得低于高水位线：

     

UPDATE COMMAND OPTIONS USING S ON Z ON HIS_NODE0000.out V ON; SET CLIENT ATTACH_DBPARTITIONNUM  0; SET CLIENT CONNECT_DBPARTITIONNUM 0; RESTORE DATABASE mydb FROM '/home/db2inst9/backup' TAKEN AT 20131128223003 ON '/home/db2inst9/dbpath' DBPATH ON '/home/db2inst9/dbpath' INTO mydb   REDIRECT; （若测试机路径如源库不同，需要修改数据库路径，否则会报SQL5099N的错误） SET TABLESPACE CONTAINERS FOR 3 USING (  file '/home/db2inst9/data/c1'  5570560, file '/home/db2inst9/data/c2'  5570560, file '/home/db2inst9/data/c3'  5570560,file '/home/db2inst9/data/c4'  5570560); SET TABLESPACE CONTAINERS FOR 4 USING (  file '/home/db2inst9/data/idx1' 2500000, file '/home/db2inst9/data/idx2' 2500000); SET TABLESPACE CONTAINERS FOR 5 USING (  PATH   '/home/db2inst9/data/tbsp4k'); SET TABLESPACE CONTAINERS FOR 6 USING (  PATH   '/home/db2inst9/data/tbsp16k'); SET TABLESPACE CONTAINERS FOR 7 USING (  PATH   '/home/db2inst9/data/usertemp1'); SET TABLESPACE CONTAINERS FOR 10 USING (  PATH   '/home/db2inst9/data/ORVRTS'); SET TABLESPACE CONTAINERS FOR 11 USING (  FILE   '/home/db2inst9/data/TSASNCA'        10000); SET TABLESPACE CONTAINERS FOR 12 USING (  FILE   '/home/db2inst9/data/TSASNUOW'    1024); SET TABLESPACE CONTAINERS FOR 13 USING (  FILE   '/home/db2inst9/data/CDFIN_OPB_FEEDETAIL'  10240); SET TABLESPACE CONTAINERS FOR 14 USING (  file '/home/db2inst9/data/c5'  50000, file '/home/db2inst9/data/c6'  50000); SET TABLESPACE CONTAINERS FOR 15 USING (  file '/home/db2inst9/data/idx3'  10240, file '/home/db2inst9/data/idx4' 10240); RESTORE DATABASE mydb CONTINUE;

     执行重定向恢复：db2 -tvf redirect.ddl。 恢复期间可以使用db2pd -utilities 查看进度。恢复完成后进行数据库的前滚。

     从客户那了解到，误操作大概发生在12月5号11:50（备份介质的时间是20131128223003 ）；

     查看时区：db2 "values current timezone" 发现是正8，

1

--------

80000.

     所以在前滚中使用USING LOCAL TIME时需要向前推8个小时，我们首先执行前滚到12月4号的11:40：

db2 "rollforward database mydb to 2013-12-04-03.40.00.000000 USING LOCAL TIME overflow log path (<归档日志在测试机上的位置>)"，注意这里不加complete或者stop，因为我们还需要前滚。

可以通过db2
rollforward db mydb query status来查看前滚情况，关注下一个日志。

第二次前滚：db2 "rollforward database mydb to 2013-12-05-03.40.00.000000 USING LOCAL TIME overflow log path (<归档日志在测试机上的位置>)"

再次使用db2
rollforward db mydb query status查看前滚情况发现下一个日志是在11:50后生成的，于是与客户协商，讲明继续前滚的风险，可能需要重新进行恢复+前滚，并明确客户是否能够容忍着近10分钟的数据丢失，客户最终确定追到11:40就可以了。

于是执行最后一次前滚：db2 "rollforward database mydb to 2013-12-05-03.41.00.000000 USING LOCAL TIME and
stop overflow log path (<归档日志在测试机上的位置>)"

三、数据恢复

     到这一步的时候就已经成功了90%了，现在千万不能被胜利冲昏了头脑，要保持冷静。

     使用export和load的方式数据恢复到源库中，要注意LOAD需要带nonrecoverable子句，否则让数据库挂起你就KO了~

四、问题总结

在恢复时，你可能会碰到以下问题：

1.执行到最后一步时（RESTORE DATABASE mydb CONTINUE），报如下错误：

DB21080E  No previous RESTORE DATABASE command with REDIRECT option was issued for this database alias, or the information
about that command is lost。   

     这可能使由于你使用了另外的数据库别名，及“into <dbname>”,尝试使用源库的库名。

2.SQL0299N  Container is already assigned to the table space.  SQLSTATE=42731。

     容器重名了。

在前滚时，你可能会碰到以下问题：

1.SQL4970N  Roll-forward recovery on database "MYDB" cannot reach th
a750
e specified stop point (end-of-log or point-in-time)
because of missing or corrupted log file(s) on database partition(s) "0". 

Roll-forward recovery processing has halted on log file "S0038255.LOG".

(1).检查时间点位置是否正确；

(2).检查需要的日志是否在overflow log path 内。     

(3).检查日志S0038255.LOG是否有损坏。比较源库和测试机上此日志的大小，发现测试机的比源库的小了1byte,于是重新传，结果还是小，改成二进制传就可以了。

     ftp > bin

     ftp > put S0038255.LOG

五、相关链接

http://blog.itpub.net/24177460/viewspace-696757

http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1104zhangl/