IBM DB2 备份简介 我们花了大量时间同客户和用户组谈关于 DB2 Universal Database for Linux、UNIX® 和 Windows® (DB2) 中最新、最重要特性的承诺。但事实总是：当我们在讲一个话题时，如果问听众他们是否熟悉一项新的关键特性，即使这项特性已经存在有一段时间了，大多数人还是没有听说过这项特性。在本文中，我们将带您经历一次 BACKUP 实用程序之旅，并展示该实用程序在 DB2 中的工作原理。我们将谈到它的内部组成，以及已经增加了有一段时间的一些新特性，这些新特性使它的速度更快，功能更丰富。 为什么要备份？ 对于为什么应该定时进行备份（并测试这些备份的可恢复性），有很多的原因。备份中的数据对您虽然没什么用，但它却是您企业的救命稻草，所以把备份数据当作您的工作吧。 以下情况都需要备份：为了在出现应用程序错误时进行恢复，为了复制数据库（例如，填充开发或测试系统），为了将数据库转移到新的硬件上，为了迁移到一个新的级别，为了确保软件更新保护前后的可恢复性，为了建立某种灾难恢复（DR）或高可用性（HA）拓扑结构，等等。 有趣的是，如今人们做备份的最大原因是确保能够在出现应用程序错误时进行恢复。可以说，如今的硬件（H/W）已经相当安全了。例如，双电源、RAID、双控制器等等都非常接近标准，如果一切设置无误的话（显然有例外），遭受 H/W 停机事故的几率很小。但如何才能避免人为的错误呢？ 为什么是 DB2 备份而不是文件系统备份？ 很多新的数据库管理员（DBA）都会问这个问题。主要原因是，
DB2 在努力保持热缓存（实际上是在内存中应用程序所需的数据）方面非常主动。随着 64-位模型的壮大，这会成为一种趋势，并且这种趋势不会减缓（也不应该减缓，因为能够放在处理器的 L1、L2 或 L3 缓存或随机存储器中的数据越多，工作负载就运行得越快。实际上，您需要积极主动的数据缓存，因为它使数据尽可能远离磁盘，从而避免高代价的 I/O 周期。 当 DB2 在运行的时候，如果要拷贝一个文件系统上的文件，那么肯定会导致数据的不一致，DB2 不能保证可以
恢复数据。例如，如果
数据库在运行，那么执行文件系统复制操作时将得不到即时点（point in time,PIT）上数据库的快照。您应该坚持使用 DB2 备份来确保数据的一致性 —— 否则，如果不终止整个 DB2 实例的话，就无法确保数据的一致性。 而且，有了基于 DB2 的备份，就可以利用 DB2 的在线能力，它允许在备份过程中执行 DDL 和 DML，这样业务操作就可以像往常一样继续。由于可以在表空间级进行备份，所以还可以进行粒度控制。这样可以将那些关键的表分离出来进行备份，而留下其他那些不需要备份或者不需要经常备份的表。 DB2 备份还有助于可恢复性。您可以通过日志前滚到所选择的某个 PIT 上。换句话说，您可以细粒度地控制系统在“起死回生”时的样子，而不是像使用文件系统的方法那样只是得到一个静态的快照（这种快照很可能是不一致的）。 DB2 还支持“子集（subset）”恢复。例如，如果备份 5 个表空间，那么可以选择只恢复其介质出现故障的那个表空间。而在文件系统备份中，要么是全部恢复，要么一个也不恢复。