3

我目前有 200+ GB 的数据库正在使用 DB2 内置备份进行每日备份（希望不会恢复 - 哈哈）但是由于该备份现在需要超过 2.5 小时才能完成，所以我正在研究第三方备份和恢复效用。版本是 8.2 FP 14 但我很快就会升级到 9.1，而且我还有一些 9.5 数据库要备份和恢复。您为此目的使用的最佳工具是什么？

谢谢！

4

7 回答 7

2

实际上只有两种方法可以进行备份，更重要的是恢复运行速度更快：1. 备份更少的数据和/或 2. 拥有更大的备份媒体管道

我认为您对如何减少备份的数据量有很多建议。基本上，您应该创建一个备份策略，该策略依赖于相对不频繁的完整备份和更频繁的更改（自上次完整备份以来）数据的备份。我鼓励您查看 DB2 Control Center 中的“配置自动维护”向导。它将帮助您创建自动备份以及Antonio建议的 REORG 等其他实用程序。由于数据量要低得多，因此压缩之类的东西显然会有所帮助。但是，并非所有 DB2 版本都提供压缩。例如，DB2 Express-C没有。坦率地说，对 200GB 的数据库进行压缩可能并不值得，这正是为什么像DB2 Express-C这样的免费 DBMS不提供压缩。

至于为您的备份打开一个更大的管道，您首先必须决定是备份到磁盘还是磁带。速度有很大差异（显然磁盘要快得多）。其次，DB2 可以并行化备份。因此，如果您有多个设备要备份，它会同时备份到所有设备，即您经过的时间会少很多，具体取决于您要解决问题的设备数量。同样，DB2 Control Center 可以帮助您进行设置。

于 2008-10-14T19:11:46.237 回答
2

在查看第三方工具之前，我怀疑它会帮助太多，我会考虑一些优化。

1) 你在你的表和索引上使用过 REORG 吗？这将压缩信息并最大限度地减少使用的页面数量；

2）如果可以，请同时在多个磁盘上备份。这可以通过运行轻松实现db2 backup db mydb /mnt/disk1 /mnt/disk2 /mnt/disk3 ...

3) DB2 应该在微调本身方面做得很好，但是您总是可以尝试使用WITH num_buffers BUFFERS,BUFFER buffer-size和PARALLELISM n选项。但同样，通常 DB2 自己会做得更好。

4）考虑进行每日增量备份，周六或周日进行一次全量备份；

5）UTIL_IMPACT_PRIORITY并UTIL_IMPACT_LIM让您限制备份过程，使其不会过多影响您的常规工作量。如果您主要关心的不是时间本身，而是备份时数据服务器的性能，这很有用；

6) DB2 9 的数据压缩在减少需要备份的数据维度方面确实可以创造奇迹。我已经看到了非常令人印象深刻的结果，如果您可以迁移到 9.1 版或者更好的 9.5 版，我强烈推荐它。

于 2008-10-13T21:44:06.900 回答
2

有帮助的一件事是转到 DB2 版本 9 并打开压缩。然后备份的大小将减少（表级别最多减少 70-80%），这应该会缩短备份时间。当然，如果您的数据库持续增长，您很快就会再次遇到问题，但是数据归档可能适合您。

于 2008-10-11T22:33:41.497 回答
1

尝试高性能卸载 (HPU) - 这是 Infotel 的独立产品，现在作为 Optim 数据工作室的一部分提供 - 在此处发布https://www.ibm.com/developerworks/mydeveloperworks/blogs/idm/date/200910？ lang=en

于 2010-06-02T12:42:37.533 回答
0

It's not a "third-party" product but anyone that I have ever seen using DB2 is using Tivoli Storage Manager to store their database backups.

Most shops will set up archive logging to TSM so you only have to take the "big" backup every week or so.

Since it's also an IBM product you won't have to worry about it working with all the different flavors of DB2 that you have.

The downside is it's an IBM product. :) Not sure if that ($) makes a difference to you.

于 2008-10-06T20:15:07.953 回答
0

I doubt that you can speed things up using another backup tool. As Mike mentions, you can add TSM to the stack, but that will hardly make the backup run any faster.

If I were you, I'd look into where backup files are stored: Are they using the same disk spindles as the database itself? If so: See if you can store the backup files on a storage area which isn't contented for access during your backup window.

And consider using incremental backups for daily backups, and then a long full backup on Saturdays.

(I assume that you are already running online backups, so that your data aren't unavailable during backup.)

于 2008-10-06T20:28:47.050 回答
0

第三方备份包可能对您的速度没有太大帮助。确保您不是每 2 小时进行一次完整备份可能是第一步。

之后，查看您将备份写入的位置。它是本地驱动器，而不是网络驱动器吗？主轴是否用于其他用途？备份不涉及大量查找活动，但确实涉及大量写入，因此您可能希望避免使用 RAID 5 并使用大条带大小以帮助最大化吞吐量。

自然，您迟早必须进行完整备份，但希望您可以在负载较轻的时候找到一个窗口，并且您可以忍受更长的备份间隔时间。在正常增量关闭的 4-6 小时内进行完整备份，然后在其余时间基于此进行增量备份。

此外，在您将备份复制到一个完全独立的系统之前，您实际上并没有得到备份。您必须尝试确定在发送之前、期间或之后压缩它是否更好。

于 2008-10-13T20:34:49.050 回答