重定向恢复+日志前滚，恢复误删除的数据
2103年12月05号中午12点，本人在兰州拉面馆正准备享用一碗红烧牛肉面，电话响了。某医院的DBA告诉我有一张关键表的数据被误操作，数据惨遭清理，需要我急速赶赴现场处理。
快速吃完面，打车赶往现场。根据平时的巡检，我知道这个库的基本信息，版本是 V9.1.8，系统是AIX 5.3，大概300G，开启了归档模式，并且会每周进行一次全备，每天增量备份，都是在晚上22:30进行。
到达现场，跟客户简单交流后，确定在测试机使用恢复加前滚的方式追数据。Let's do it ~
一、搭建测试机：
license 问题，所以一定要客户提供，而且客户方一般都有安装光盘的） 。客户方保管介质的工程师找了好久都没有找到光盘，为此被领导批评了。在费了九牛二虎之力后，总算是解决了介质问题。
备份介质的大小和表空间高水位，提出需要增加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 和
具体请参见：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
三、数据恢复
到这一步的时候就已经成功了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 the 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
五、相关链接