代码之家 › 专栏 › 技术社区 › KenFar

备份大型实时数据仓库的最佳方法是什么?

db2

KenFar · 技术社区 · 14 年前

我有一个DB2ESE9.7非DPF数据仓库,使用数据压缩和20TB的数据,通过每10分钟加载一次,每天获取1亿行数据,通过每天5万次的导入,每天获取100万行数据。此外,还有少量与其他两个大型数据集相关联的事务性数据。

目前,我们使用的是应用程序级备份——并依赖于加载以前导出的摘要表,或者在恢复时每天重新加载1亿行。但是为了少量的事务和导入——我想要在线备份。

但是,联机表空间特定备份似乎需要初始脱机备份。这就是问题所在,即使我可以将离线备份重定向到/dev/null,离线备份也需要大约48小时的停机时间。这是不可接受的。在将来的某个时候可能会再次需要。

在某个时候,我们可能会将其拆分为8+个分区,这将有助于此和加载索引构建。但这种情况可能暂时不会发生,而且很难为最初不必要的任务辩护。

编辑:我们最初没有使用DPF的原因,以及为什么它不是我们查询的驱动问题是超过99%的查询命中摘要表,并且1%的查询必须使用每月超过30亿行的表,几乎总是可以利用表分区、MDC和为了只扫描较小数量的索引。这就意味着传统的启发式方法并不总是适用于每个CPU有多少数据。

有什么方法可以绕过离线备份的要求吗?有什么第三方工具可以帮助我吗?还有其他建议吗?

1 回复 | 直到 14 年前

Ian Bjorhovde 14 年前

不幸的是,没有真正的方法可以解决这个问题——当您进行数据库的物理设计时,必须计划好恢复。使用带有范围分区的单独表空间,只允许使用新数据备份表空间(假设您知道哪些表空间正在更改…)

通常,这属于在磁盘级别使用拆分镜像或快照的领域。当然,这要求您的磁盘子系统支持此功能(除非您使用的是Veritas卷管理器之类的软件),并且您有能力实际启用此功能。不过,DB2完全支持这一点,而且非常有用。我已经使用了EMC SYMMETRIX和Clariion;但它确实需要一次短暂的“停机”,在那里冻结数据库I/O,以便发出操作系统命令来处理破坏镜像的问题。

在V9.5中,DB2添加了一个称为高级拷贝服务(acs)的特性,它允许存储供应商集成到备份数据库命令中。IBM通过其一些存储子系统来支持这一点,而Netapp也很快对此提供了支持。说“备份数据库HugeDB使用快照”并观看它需要10秒钟,这是非常令人惊讶的。然后“恢复数据库hugedb使用快照在 时间戳 “。