今天像大家描述的是DB2数据库恢复的一些实际操作经验的总结，前几天我们刚进行DB2数据库恢复测试，想不到这么快就用到了。所以说每当你发现某个技术可能会用到，但是还没动过手，必须立即动下手。说不定那天就要用到。
那天下午突然收到项目经理电话，说生产库某个表被工程人员删错了数据了，希望能在测试环境对生产库进行恢复。我当时***感觉就是测试环境的空间不够。生产库表空间分配的空间一共是200g不到。但是使用的空间不到50g。当时我怀疑DB2的这个恢复应该是类似于oracle的rman恢复，直接进行物理恢复。直接将表空间恢复出来。因此需要200g左右的空间。
测试环境肯定是没有这么大的空间了，但是不完全肯定，尝试做下恢复。有报错，看了下，是说某个路径没有权限读写，仔细看了下，那个路径是生产库表空间文件存放的路径。原来DB2恢复只能恢复在原路径上。建立好相应的文件系统。再看还是有报错，原来是日志的目录不存在，再建文件系统，恢复。还报错，这次是归档日志的目录，再建，恢复。
- DB2 RESTORE db abc FROM /DB2/data/bk taken at 20100517000001
结果显示，有部分表空间没有恢复成功，但是整体DB2数据库恢复是成功了。
将需要的归档日志拷贝到(/DB2/data/bk/log/)目录，做前滚
- DB2 "rollforward db abc to end of logs and stop overflow log path(/DB2/data/bk/log/)"
报错
- SQL1218N There are no pages currently available in bufferpool "".
觉得应该是恢复过程中出现问题，查看DB2的日志。日志太大，感觉不方便看，因此再做一次恢复，然后实时监控日志输出。发现在恢复一些表空间的时候，一直抱一个disk full的错误。问题应该定位到，就是磁盘空间不够。但是测试环境的磁盘空间是绝对不可能腾出200g出来。咋办？
***实在没办法，就在生产库的磁阵上，建了一个200g的nfs给测试环境用，再进行DB2数据库恢复。过程有报错，是说表空间的使用率超过阀值，因为有些表空间的使用率是100%，不知道那些表空间是否有用的.......。
200g的恢复果然很花时间，用了差不多一个多小时。再做一次前滚，仍然报错
- SQL1218N There are no pages currently available in bufferpool "".
奇了怪了！上网搜了下，也有人碰到一样的问题。建议修改参数
- DB2set DB2_OVERRIDE_BPF=1000，
然后重启DB2，
果然，能够成功前滚，DB2也能成功登录。
总结:
1.在进行DB2异地DB2数据库恢复的时候，已经要先建好相应的目录，数据文件目录，日志目录，归档日志目录。
2.在操作失败需要查看日志时候，尽量想办法去看老日志，因为重新操作，再实时看日志，虽然比较明朗，但是需要花费更多的时间。
【编辑推荐】
