我有一个db2 ese 9.7非dpf数据仓库，使用20 TB数据进行数据压缩，每10分钟通过负载获得1亿行，每天通过50,000次进口获得每天100万行。此外，还有少量与其他两大数据相关的交易数据。
目前，我们正在使用应用程序级备份 - 并且依赖于加载以前导出的摘要表或在恢复时每天重新加载1亿行。但是为了少量的交易和进口 - 我喜欢在线备份。
但是，特定于联机表空间的备份似乎需要初始脱机备份。这就是问题，即使我可以将离线备份重定向到/ dev / null，离线备份也需要大约48小时的停机时间。这是不可接受的。并且可能在将来的某个时候再次被要求。
在某些时候，我们可能会将其拆分为8个以上的分区，这将有助于此和加载索引构建。但这可能不会发生一段时间，并且很难证明首先应该不需要的任务。
编辑：我们最初没有使用DPF的原因，以及为什么它不是我们的查询的驱动问题是超过99％的查询命中总结表，而1％的查询必须涉及到每月超过30亿行的表几乎总能利用表分区，MDC和索引，以便只扫描更小的数量。这得到了关于每个CPU的数据量并不总是适用的传统启发式方法。有什么方法可以绕过该离线备份要求？任何可以帮助我的第三方工具？还有其他建议吗？
答案 0 :(得分：2)
不幸的是，没有办法解决这个问题 - 在进行数据库的物理设计时，必须计划恢复。使用具有范围分区的单独表空间允许您仅使用新数据备份表空间（假设您知道哪些表空间正在更改...）
通常，这将属于在磁盘级别使用分割镜像或快照的领域。当然，这需要您的磁盘子系统支持此功能（除非您使用的是Veritas Volume Manager之类的软件），并且您有能力实际启用此功能。 DB2完全支持这一点，它非常有用。我使用EMC Symmetrix和Clariion完成了这项工作;但它确实需要一个简短的“中断”，你冻结数据库I / O，以便发出操作系统命令来处理破坏镜像。
在v9.5中，DB2添加了一项称为高级复制服务（ACS）的功能，该功能允许存储供应商集成到BACKUP DATABASE命令中。 IBM通过一些存储子系统支持这一点，NetApp也很快加入了对此的支持。令人惊讶的是，“BACKUP DATABASE HUGEDB使用SNAPSHOT”并观看需要10秒钟。然后“恢复数据库HUGEDB使用时间戳时使用的快照”。