有奖讨论： DB2在进行数据备份时需要注意的事项

crypig

我觉的数据库备份有两类，一种是建立备份数据库，与生产备份库做互相备份。另一种是导出备份文件，当需要时再恢复数据。
1、建立备份数据库方式
  （1）建立备份数据库，备份数据库可以是另外的实例。要保证数据库表结构的一致性。
  （2）编写存储过程，定时将生产数据库中的数据导入到备份数据库中。这个定时频率可以根据实际情况制定。但要考虑效率，不能影响生产环境
  （3）只有在生产数据库出现异常，或者需要恢复的时候，才启动恢复程序。
  （4）为了保证能回滚，最好在恢复时候，能将生产环境数据库中的内容先导出一份来
  好处：可以保持备份数据库和生产数据库从表结构和数据的高度一致。
  坏处：需要占用资源和牺牲性能
2、导出数据文件
  （1）定时将数据库的表结构和数据导出，生成数据库备份文件
  （2）在需要恢复的时候，首先确定是恢复数据还是恢复表结构
  （3）根据需要恢复数据即可
  好处：处理简单，备份什么表就根据需求备份
  坏处：同步差一些

建议：如果是很重要的数据库，建议使用上面的两种方式做备份。

eagleming

1.每周日备份数据，生成备份日志。备份介质存储放在备份机中。
2.在测试系统中每周日恢复备份数据，即验证备份可靠性，又可以更细测试系统数据。

yywangsx

用DATAGUARD，每月以readonly模式打开备用数据库，对比主备库数据库对象是否一致，并通过业务测试数据的有效性。公司是10g的库，11G可直接比较。

bitiwyh

前排占座学习。只简单用过export/import导出导入。

比较想知道的是如何测试保证备份是可恢复的。测试环境与生产环境的差异可能会对备份的测试带来什么影响。（很难让测试环境跟生产环境一样？）。。。

lldt210

学习中

leetaedong

个人觉得 db2 在备份恢复方面较oracle还是弱了一点。

假如可以像rman样的，可以restore preview就好了。

可能我对db2 了解不够。

还是需要定时 进行恢复测试吧。

另外据说 db2 坏了primary redo log 的话，就没办法open了。

这个也有点弱。就更要测试了。 总体上 db2 在一些小的特性上还是要加强。

一家之言。

定期随机抽备份样本做恢复测试，确保备份的有效性。巡检时要确认备份是否正常结束。做备份策略时要对各种情况进行测试恢复，定期做灾难性恢复测试。

wangzhonnew

在db2中备份文件可以分为几类
离线备份
在线备份
镜像分离

其中离线与在线备份使用DB2的backup命令，而镜像分离使用存储的flashcopy。那么在使用db2 backup命令的场景下，确保备份文件的完整性是可恢复的前提。如果备份文件不完整或者硬件损坏，那就一切空谈
在备份文件完整的前提下，下一步需要保证回滚日志的完整性和正确的日志链，才能做到正常恢复。

前面的朋友们总结的很好，很多种方法都可以降低备份文件与日志文件损坏的可能，其中最为有效，也是非常重要的步骤就是定期的回复测试。
曾经见过用户在进行恢复时发现硬件介质问题，导致一段时间内的备份全部不可用，最后弄得很狼狈。

另外对于生产环境与测试环境的差异，不知道各位朋友有什么好的备份验证方法。比如生产系统150个分区，但是在测试系统不可能真正分配150个逻辑分区。这种情况下怎样能最大可能地保证备份文件的稳定性呢？

leetaedong

在进行恢复时发现硬件介质问题，导致一段时间内的备份全部不可用，最后弄得很狼狈。

====>
我碰到过的有一些是 备份是做了，在线的，然后但是不包含日志，或者 备份后的几个日志删除了，造成
有gap，也就是你说的 日志链的完整性，就少那么几个，后面的也都有。

绝对抓瞎。

另外就是 oracle主备的时候，备库只是接收日志，并没有应用，碰到问题要去切换。
根本切换不过来，不一致。 这个也很严重。


至于你说的 " 生产系统150个分区 "，不是太清楚你的意思。
想恢复到测试库的话，可以重定向恢复啊。

不知道是不是一回事。

leetaedong

定期的恢复测试，道理其实 很多人都懂。

但是真的要把它当成规章制度，这个 得要 dba说话有一定的份量才行。

同样道理的还有，两机互备，系统运行的好好的，谁会让你去切换一下，看看会不会出问题。
毕竟线上业务稳定性是第一位。 领导觉得现在好好的，为什么要切换。

但真要是发生问题，谁能保证就一定可以接管过来。或者可以及时接管过来。

版主也说说自己的意见。