利用 MySQL 技能学习 DB2 Express: DB2 与 MySQL 的备份和恢复
2009-11-12 00:00:00 来源：WEB开发网简介
本文帮助现有的 MySQL 数据库管理员转移自己的技能，学习 DB2 Express 的备份和恢复功能。您可能已经熟悉在 MySQL 中对数据库进行备份和恢复的方法；本文主要介绍备份和恢复策略的特性、功能和好处，以及如何在 DB2 Express 中完成备份和恢复。本文还介绍如何利用 DB2 Express 中的绝对无数据损失选项。
本文主要关注 DB2 Express 的功能，同时介绍开放源码的 MySQL 和 DB2 Express 之间的相似性和差异。
概述
本文讨论以下主题：
系统结构
备份 —— 离线
恢复 —— 离线
备份 —— 在线
恢复 —— 在线
Throttling
自动备份维护
其他实用程序
介绍
本文主要关注使用 MyISAM 和 InnoDB 存储引擎进行备份和恢复，因为它们是 MySQL 中最常用的引擎。本文不关注 MySQL 的复制特性。
因为 MySQL 可以选择底层的存储引擎，比如 MyISAM、Oracle 的 InnoDB 和 Sleepycat 的 Berkeley BDB，因此备份和恢复机制随使用的存储引擎而变。例如，如果底层存储引擎是 MyISAM，它提供了两个备份和恢复实用程序：mysqldump 和 mysqlhotcopy（出于性能原因，本文主要关注 mysqlhotcopy）。mysqlhotcopy 脚本进行文件级复制（*.frm、*.MYD 和 *.MYI 文件），只适用于 MyISAM 存储引擎。它可以在需要备份的数据库所在的相同机器上运行。在恢复时，将数据库目录替换为备份目录。
对于大型环境，mysqldump 执行起来很慢；但是，在备份重要的表时它非常有用。它将表转储为一种可读的格式。尽管 mysqldump 提供了 --single-transaction 标志用于为 InnoDB 执行在线备份（需要读锁；FLUSH TABLES WITH READ LOCK），还提供了用于前滚的二进制日志，但是仍然最好使用单独付费的 InnoDB 备份和恢复工具，ibbackup（注意，这个组件在 InnoDB 存储引擎之上工作，是一个单独付费的组件）。
因为在本质上不具有内在的 ACID 性质，所以 MyISAM 存储引擎的备份和恢复可以用来执行版本级恢复，但是不保证数据完整性。使用这种存储引擎，在发生介质故障时，自上次备份以来的所有工作都会丢失。
对于具有 MyISAM 和 InnoDB 存储引擎的混合式 MySQL 数据库环境，进行备份的更好的方法可能是使用 innobackup。这个实用程序对 InnoDB 进行在线备份，同时建立 MyISAM 表的快照。
对于事务安全的存储引擎，InnoDB 备份工具 ibbackup 是首选的。但是，要注意下面列出的兼容性问题：
MySQL/InnoDB 5.0 需要 InnoDB Hot Backup 3.0 或更新版本。
MySQL/InnoDB 4.1 需要 InnoDB Hot Backup 2.0 或更新版本。
MySQL/InnoDB 4.0 需要 InnoDB Hot Backup 1.40 或更新版本。
MySQL/InnoDB 3.23 需要 InnoDB Hot Backup 1.40 或更新版本。
InnoDB Hot Backup 2.0 可以用于 MySQL/InnoDB 4.1 以下的所有 MySQL/InnoDB 版本（包含 4.1），但是与 MySQL/InnoDB 5.0 或更新版本不兼容。
InnoDB Hot Backup 3.0 与从 3.23 到 5.0 的所有 MySQL/InnoDB 版本兼容。
DB2 Express-C 附带一种内置的备份和恢复机制，所以不需要为版本不匹配或任何兼容性问题担心。另外，如果使用 DB2 Control Center 进行备份和恢复，那么几乎不需要编写任何代码，因此这个过程很少会出错误。DB2 Express-C 备份和恢复非常简单，很容易完成。
在 DB2 Express-C 中，数据库可以以两种模式进行备份和恢复。DB2 Express-C 与 MySQL 的备份和恢复不同，因为 DB2 Express-C 没有即插即用的存储引擎（这些引擎需要自己的备份和恢复机制）。例如，对 MyISAM 进行备份的方式与对 InnoDB 或 Berkeley 进行备份的方式不同。对 MyISAM 和 InnoDB 数据库进行备份需要特殊处理，也就是需要 innobackup 那样的 shell/perl 脚本。但是，DB2 Express-C 就简单多了，只需用一个命令进行备份（BACKUP），用另一个命令进行恢复（RESTORE）。
在 DB2 Express-C 中，除了用户数据之外，还可以备份以下对象：
用户定义的函数
用户定义的数据类型
存储过程
触发器
序列
表
索引
视图
离线模式适用于非连续运行的环境，在这种环境中，数据库常常每天或每周（取决于数据库的重要性）进行一次整体备份。还可以将离线模式应用于只读的数据库。这种模式简单易行，但这是有代价的；如果发生故障，上次备份以来的数据就会丢失（请注意这种风险！）。通常，备份的时间间隔由事务量和在发生硬件故障时能够接受的数据损失量决定。在进行恢复之后，需要重新输入数据。在 DB2 Express-C 中，这种模式称为版本恢复，即以一定的时间间隔对整个数据库（不可恢复的数据库）进行备份，并在发生故障时进行恢复。
不需要对整个文件系统进行备份，因为 DB2 Express-C 提供了对数据库进行离线备份和恢复的简易方法。有一个命令用于备份，另一个命令用于恢复。
在线备份和恢复是一种内置的机制，用来确保数据库中的数据不会丢失。典型的连续运行环境常常使用这种模式，从而确保所有数据在灾难中得到保护。DB2 Express-C 提供的这种备份和恢复模式有许多选项。例如，对于实现无数据损失策略的小型环境，可以对数据库进行整体的在线备份和恢复。换句话说，备份和恢复功能在数据库级执行。作为一种更好、更灵活的维护选项，可以选择在表空间级进行备份。最后（但并非是最次要的），对于大型环境（尤其是对于 DB2 Workgroup 和 Enterprise 版本）可以在在线全数据库备份的基础上执行 delta 和增量备份。
同样，别以为备份文件系统就可以备份数据库。DB2 Express-C 提供了内部机制来确保数据完整性和同步。如果在文件系统级进行备份，就可能使数据库完全失效。您不应该这么做，因为 DB2 Express-C 为备份和恢复、在线备份和在线恢复分别提供了简单的命令。
如果没有提到 DB2 Express-C 中的自动备份和恢复维护特性，本文就是不完整的。这个特性使 DBA 可以高枕无忧，因为数据库备份和恢复可以完全自动地进行。
最后，DB2 Express-C 的备份机制附带一个 throttling 特性（尤其适用于 Workgroup and Enterprise 版本），它在生产负载低的时间段占用更多的 CPU 时间，在生产负载高的时间段占用更少的 CPU 时间。Throttling 特性使服务器不会由于数据库备份这样的资源密集型活动而变慢。利用这个特性，备份活动就可以在生产负载高的时间段执行。
现在，我们来详细讨论每个方面。
系统结构
为了理解 DB2 Express-C 提供的备份和恢复机制，最好先了解它的体系结构。例如，日志缓冲区将每个事务写到日志，可以使用不同的日志模式来实现不同的备份和恢复模式。
内存结构
下图给出 DB2 Express-C 内存结构的简化版本。关于更完整、更详细的内存结构，请参考 developerWorks 中的 内存模型。注意，日志缓冲区位于数据库的共享内存中，这种机制确保每个事务被记录到日志文件中。
图 1. DB2 Express-C 内存结构
下面列出这些组件的功能：
包缓存（package cache）—— 分配这里的内存来存储静态和动态 SQL 语句。
缓冲区池（buffer pool）—— 在将数据刷新到磁盘之前，分配这里的内存来存储数据。
日志缓冲区（log buffer）—— 在刷新到磁盘上的日志文件之前，使用这里的内存存储对数据库的所有修改。
目录布局
在默认安装的情况下，DB2 Express-C 具有以下表空间：
Syscatspace —— 存储系统编目信息。
Tempspace1 —— 存储系统临时表。临时表空间可以是系统的，也可以是用户的。最好从系统临时表空间创建用户临时表空间。
Userspace1 —— 存储用户数据。
但是，表空间代表数据库容器的逻辑方面，而物理布局决定实际数据存储在文件系统中的什么地方。
物理文件系统的布局如下图所示：
图 2. DB2 UDB Express 容器布局 
驱动器/目录 —— CREATE DATABASE 命令中指定的驱动器或目录
DB2 实例名 —— DB2 实例所有者的名称
NODE0000 —— 数据库的分区号（0 代表无分区数据库）
SQL00001 —— 从 1 开始的数据库 ID
SQLOGDIR —— 数据库的默认日志目录
SQLT0000.0 —— 编目表空间，SYSCATSPACE
SQLT0001.0 —— 临时表空间，TEMPSPACE1
SQLT0002.0 —— 用户表空间，USERSPACE1
比较重要的问题是，在 DB2 Express-C 8.2 之前的版本中，事件日志需要发送到离站位置，DBA 必须知道需要发送哪些存档日志以及这些日志的位置。由于在备份命令中引入了 include logs 选项，日志也包含在备份映像中。这使日志管理更容易了。对于前滚恢复，不需要知道实际日志的位置，因为前滚命令会自动找到它们。
日志机制
DB2 Express-C 提供两种日志模式，循环和存档日志模式。在循环日志模式中，事务以循环方式写到日志中。循环日志只能支持版本恢复。换句话说，无法前滚到上次全数据库备份以来的任意时间点或日志的末尾。这种模式只适用于只需恢复上次全数据库备份的场合。当然，其影响就是上次备份之后的所有事务都会丢失。如下图所示，由于日志采用循环方式，所以日志会被重写。活跃日志防止在崩溃恢复（比如电源故障）期间的数据损失。辅助日志用于长期运行的事务；指定 -1 表示允许无限的辅助日志。
图 3. 打开辅助日志的循环日志
存档日志模式支持在线备份和恢复。利用在线备份，就可以将日志前滚到任何特定的时间点或日志的末尾。这是配置存档日志模式的最大优点。崩溃恢复需要活跃日志，存档日志是活跃的，但崩溃恢复不再需要这种日志。但是，在日志重放期间需要存档日志。只有在这些日志之间没有 “中断” 的情况下，才可能前滚到任何特定的时间点或日志的末尾。换句话说，要想确保绝对没有数据损失，需要原样保存上次在线备份以来的日志。在默认情况下，在完成在线备份之后，DB2 会将当前活跃的日志关闭，从而确保可以使用完整的存档集来进行前滚。从 DB2 Express-C Version 8.2 开始，可以在备份命令中使用 include logs 选项，从而将日志包含在备份映像中。用户退出时也会发送日志，这只是为了提供向后兼容性。
图 4. DB2 存档日志
可以在 DB2 Control Center 或命令提示 CLP 中控制和设置 DB2 Express-C 日志参数。对于 Control Center，只需选择一个数据库并右击，再选择 configure parameters。
图 5. DB2 Express-C 日志参数
要想在命令 CLP 中看到参数，应该发出命令 get db cfg for <your_db_name>。要更新参数，应该发出命令 update db cfg using <parameter_name> <value>。例如，要将 logretain 设置为 ON，应该发出命令 update db cfg using logretain on。一些参数设置只有在断开所有应用程序与数据库的连接之后才会生效。最后，如果需要恢复系统默认设置，那么应该发出命令 reset db cfg for <your_db_name>。
图 6. 在 CLP 中显示的 DB2 Express-C 日志参数
图片看不清楚？请点击这里查看原图（大图）。
下面讨论在 DB2 Express-C 中使用的一些重要的日志参数。正如前面提到的，需要回顾一些概念才能更好地理解配置参数。
活跃日志是崩溃恢复需要的日志。
存档日志是活跃的，前滚恢复需要存档日志，但是崩溃恢复不再需要它们。
logarchmeth1/logarchmeth2（默认值是 OFF）—— 它们首先决定使用哪种日志机制，然后决定存储存档日志的位置。它们使存档日志文件写到活跃日志路径（默认为 SQLOGDIR）之外的位置。这些参数的默认值是 OFF，这表示使用循环日志模式。下面是可以为这两个参数设置的 5 个值：
OFF —— 默认设置，表示使用循环日志模式。采用这个设置时，只能进行版本恢复，没有前滚功能。
LOGRETAIN —— 设置 LOGRETAIN 值会自动地将参数 LOGRETAIN 的值改为 RECOVERY，这表示使用存档日志模式。这个值允许在数据库恢复期间进行前滚。这个值只对 logarchmeth1 是有效的。
USEREXIT —— 调用一个用户退出程序来进行日志的存档和获取。设置这个选项将把配置参数 USEREXIT 自动地更新为 ON。这个值只对 logarchmeth1 是有效的。
DISK —— 指定存储存档日志的位置（物理文件系统）。这个选项也允许使用磁带存储存档日志。
TSM —— 使用 Tivoli® Storage Manager 来维护存档日志。要使用这个选项，需要指定 TSM 管理类名。例如，要使用 CMDISK 作为管理类，应该发出命令 update db cfg for <your_db_name> using logarchmeth1 TSM:CMDISK。配置参数 TSM_MGMTCLASS 不会自动更新。
VENDOR —— 这个选项指定要使用厂商的备份和恢复 API。
logbufsz（默认值是 8 x 4K）—— 表示作为日志缓冲区的内存大小。
logfilsiz（默认值是 4096 x 4K）—— 指定日志文件的统一大小。对整个活跃日志空间的逻辑限制是 256GB。
logprimary（默认值是 3）—— 指定使用的主日志的总数。每个日志的统一大小由参数 logfilsz 指定。选择要创建的主日志的总数和大小时，需要在可用磁盘空间和应用程序的功能之间进行折中，以便适应日志的所有情况。无论日志被填充了 10% 还是 90%，创建的每个日志都需要相同的磁盘空间。对于长期运行的事务，常常需要创建容量更大的主日志。在当前的 DB2 Express-C 版本中，整个活跃日志空间大小的上限是 256GB。
logsecond（默认值是 2）—— 指定在主日志文件被填满时创建的日志文件总数。这些日志文件只在主日志文件被填满之后创建。默认值 2 意味着只创建 2 个日志文件。但是，可以指定 -1，这允许无限的活跃日志空间。
logretain（默认值是 OFF）—— 表示使用循环日志还是存档日志。这个值通常使用 logarchmeth1 配置参数进行设置。
userexit（默认值是 OFF）—— 表示使用用户退出程序。不建议使用这个选项，因为它主要用于提供向后兼容性。这个值也可以使用 logarchmeth1 配置参数进行设置。
mirrorlogpath（默认值是 NULL）—— 这个配置参数允许通过在指定的路径中保存相同的副本来保护日志。这可以防止介质故障或意外删除日志造成日志 “中断”。
但是有两件事需要注意：当打开 logarchmeth1 以支持前滚恢复时，当前活跃日志不会复制到 mirrorlogpath 中指定的路径；需要记住这个路径，以防主日志位置中出现日志损失。
newlogpath —— 这个路径的默认设置随数据库 ID（创建的第一个数据库的 ID 是 1）和节点号（适用于 Workgroup and Enterprise 版本）而变。对于创建了第一个数据库的一个节点设置，这个路径是 C:\DB2\NODE0000\SQL00001\SQLOGDIR（参见上面 “目录布局” 一节中对布局的解释）。如果对默认路径不满意，那么可以使用这个配置参数修改它，活跃日志和存档日志就可以写到这个新位置。
overflowlogpath（默认值是 NULL）—— 表示在前滚恢复期间使用的日志路径。注意，可以在恢复命令中使用 OVERFLOW LOG PATH 选项，这个选项的优先级比这个配置参数高。
num_log_span（默认值是 0）—— 指定在一个工作单元中可以跨越的活跃日志总数。0 表示无限制跨越。
failarchpath（默认值是 NULL）—— 当实际存档路径不可用时使用的路径。只有在尝试过 numarchretry 中指定的次数（默认值是 5）之后，才会使用这个路径。可以使用参数 archretrydelay 指定在这些尝试之间等待的时间间隔（秒数，默认值是 20 秒）。换句话说，在使用默认值时，需要等待 (5 x 20) 秒，然后存档日志才会写到 failarchpath 中指定的路径。
下表对比了这两种数据库中的特性以及控制它们的参数。对于使用 mysqlhotcopy 的 MyISAM 存储引擎，大多数日志特性是不可用的。
| 日志功能 | 在 MySQL - InnoDB 中的可用性 | 在 DB2 Express-C 中的可用性 | DB2 Express-C 参数 | 注释 |
| 循环日志 | √ | √ | logarchmeth1 | InnoDB 的日志是以循环方式写入的。 |
| 存档日志 | × | √ | logarchmeth1 | 打开二进制日志 log-bin 就可以在 InnoDB 中恢复到特定的时间点。在进行时间点恢复时，将 mysqlbinlog 的输出重定向到 mysql。不使用参数 innodb_log_arch_dir 和 innodb_log_archive。 |
| 分配给日志缓冲区的内存 | √ | √ | logbufsz | 使用 InnoDB 的参数 innodb_log_buffer_size。 |
| 日志文件大小 | √ | √ | logfilsiz | 使用 InnoDB 的参数 innodb_log_file_size。在 DB2 Express-C 中，这个值在所有日志文件上是统一的。 |
| 创建的主日志总数 | √ | √ | logprimary | 在 InnoDB 中，备份目录中只有一个日志文件 ibbackup_logfile，其中包含前滚信息。要进行前滚，应该使用选项 --apply-log。 |
| 创建的辅助日志总数 | × | √ | logsecond | 在 InnoDB 中，没有用来处理长期运行的事务的辅助日志概念。日志将以循环方式写到 innodb_log_group_home_dir 指定的目录中。 |
| 日志发送 | √ | √ | userexit | 对于使用 ibbackup 的 InnoDB 备份，将生成日志文件 ibbackup_logfile，可以通过标志 --apply-log 使用这个文件进行前滚。从 DB2 Express-C Version 8.2 开始，日志可以包含在备份映像中。参数 userexit 仅仅用于提供向后兼容性。 |
| 日志镜像 | √ | √ | mirrorlogpath | InnoDB 的镜像日志由 innodb_mirrored_log_groups 指定。 |
| 修改默认的日志路径 | √ | √ | newlogpath | InnoDB 日志文件和数据文件将写到 innodb_log_group_home_dir 指定的路径中。 |
| 溢出日志路径 | × | √ | overflowlogpath | |
| 活跃日志跨越 | √ | √ | num_log_span | InnoDB 日志文件 innodb_log_files_in_group 可以用来处理长期运行的事务。 |
| 设置活跃日志空间中允许使用的空间百分比 | × | √ | max_log | 在 DB2 Express-C 中，max_log 指定可以使用的主日志空间的百分比。这个参数确保单一事务不会耗尽所有活跃日志空间。 |
| 控制将日志缓冲区写到磁盘中的频率 | √ | √ | mincommit | InnoDB 日志的刷新由 innodb_flush_log_at_trx_commit 控制。在 DB2 Express-C 中，mincommit 确保只在一定的时间间隔之后将日志缓冲区写到磁盘中。 |
| 故障转移存档路径 | × | √ | failarchpath | 在 DB2 Express-C 中，archretrydelay 和 numarchrety 与 failarchpath 结合使用。 |
| 防止磁盘满错误 | × | √ | blk_log_dsk_ful | 在 DB2 Express-C 中，这个参数向用户通知磁盘满错误（使用一个管理日志），并每 5 分钟创建一个新日志，直到解决磁盘空间满问题。但是，DB2 在磁盘填充到 80% 或 90% 时没有提供警告措施。所有 DB2 都会阻止事务，直到有更多的空间可用。 |
| 用磁带进行日志管理 | × | √ | logarchmeth1/logarchmeth2 | 在 DB2 Express-C 中，这是通过参数 logarchmeth1 或 logarchmeth2 支持的开箱即用特性。另外，可以使用内置命令 db2tapemgr 进行日志文件的存储/获取管理。 |
| 与 TSM、Veritas 等第三方解决方案进行集成 | × | √ | logarchmeth1/logarchmeth2 | 在 DB2 Express-C 中，这是通过参数 logarchmeth1 或 logarchmeth2 支持的开箱即用特性。Tivoli Storage Manager（TSM）本机集成到 DB2 Express-C 中。对于其他厂商，可以通过在这些参数中指定选项来使用他们的备份和恢复 API。 |
备份 —— 离线
离线备份方法支持进行版本恢复。这种方法用于没有存档日志可用的不可恢复数据库。采用这种方法时，使用循环日志模式，可以以循环方式重写日志。在数据库恢复操作期间，使用以前的备份映像恢复整个数据库（不是部分数据库）。这会将数据库恢复到创建这个映像的时间点。创建上一个备份映像以来的事务都会丢失。
关于离线备份有几点应该记住：
只能进行版本恢复。上次备份以来的所有工作都会丢失。
这是默认的备份模式，由 logarchmeth1 设置为 OFF 来表示。
由 logsec 表示允许长期运行的事务。
在发出备份命令时，不允许有连接。
执行离线备份需要特殊的授权 —— sysadm、sysctrl 和 sysmaint。
备份在数据库级进行。不能进行表级或表空间级备份。
有完整的备份历史列表。
不能进行增量或 delta 备份。
简单、容易而且灵活。
可以使用命令 CLP 或 Control Center 进行离线备份。我们将分别看看这两种方式。
使用命令 CLP 进行离线备份
使用命令 CLP 进行离线备份是很简单的。首先发出命令 db2 force applications all 或 quiesce，确保所有应用程序断开连接。下面给出备份命令。
清单 1. 使用命令 CLP 进行离线备份 db2 backup db <your_db_name> to <your_backup_path>
这样就可以了，但是如下面的完整语法所示，也可以用许多选项控制备份过程。在一般情况下，只需要使用简单的备份命令。
清单 2. DB2 Express-C 备份语法 BACKUP DATABASE database-alias [USER username [USING password]]
[TABLESPACE (tblspace-name [ {,tblspace-name} ... ])] [ONLINE]
[INCREMENTAL [DELTA]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}] | TO dir/dev
[ {,dir/dev} ... ] | LOAD lib-name [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}]]
[WITH num-buff BUFFERS] [BUFFER buffer-size] [PARALLELISM n]
[COMPRESS [COMPRLIB lib-name [EXCLUDE]] [COMPROPTS options-string]]
[UTIL_IMPACT_PRIORITY [priority]] [{INCLUDE | EXCLUDE} LOGS] [WITHOUT PROMPTING]
使用 DB2 Control Center 进行离线备份
使用 DB2 Control Center 进行数据库离线备份是另一种备份方法，这种方法不需要发出任何命令。DB2 Control Center 是一个用于管理的 GUI。它主要基于向导，可以引导用户完成管理任务。它提供的一个选项可以在每个向导结束时显示底层的命令。为进行离线数据库备份，需要执行以下步骤。
打开 DB2 Control Center。
选择要备份的数据库（例如，ABX84）并右击选择 Backup 选项。
图 7. 使用 Control Center 进行离线备份 —— 右击选择 Backup 选项
在第一个屏幕上，可以获得以下信息。点击 Next 继续。
要备份的数据库。
数据库状态，可用或不可用。
这个数据库上次备份的时间戳。
自动备份维护。在默认情况下，这是禁用的。本文后面的一节将讨论这个问题。
日志类型，循环或存档。
在线备份。对于离线备份，这个选项总是 NO。
表空间级备份。对于离线备份，这个选项总是 NO。
图 8. 使用 Control Center 进行离线备份 —— 介绍
有几个可供选择的目标选项。为了简单，选择 File System 并添加路径。点击 Next。
File System
Tape
Tivoli Storage Manager (TSM)
XBSA
Vendor
图 9. 使用 Control Center 进行离线备份 —— 映像
在这一步中可以了解到许多信息。
备份类型 —— 只启用全备份。在使用循环日志时，只能进行离线全数据库备份。
可用性 —— 在使用循环日志模式时，只能进行离线全备份。如果要进行在线备份，那么需要将日志模式改为存档日志。这可以使用命令提示 CLP 或 DB2 Control Center 的 Configure Database Logging Wizard 来完成。
Quiesce 数据库 —— 可以显式地断开所有应用程序的连接，也可以使用这个新的 quiesce 数据库特性。它迫使所有用户离开实例或数据库，并进入 quiesced 模式以便进行维护。这个选项在默认情况下是启用的。
Throttling —— 正如前面提到的，这是最好的特性之一，可以确保在备份期间服务器不会过载。在默认情况下，这个选项没有启用。启用这个选项之后，可以根据希望分配给这个备份操作的资源相应地设置优先级。
压缩 —— 在默认情况下没有启用。打开这个选项会使备份映像被压缩。
图 10. 使用 Control Center 进行离线备份 —— 选项
这一步处理性能设置。对于一般情况，采用默认值即可。
图 11. 使用 Control Center 进行离线备份 —— 性能
可以立即运行备份，也可以安排它的运行时间。
图 12. 使用 Control Center 进行离线备份 —— 调度
接下来，在总结页面中显示前面的所有选项/设置。同时，可以使用 show command 按钮生成命令，还可以保存命令供以后使用。点击 Back 按钮可以返回前面的页面进行修改，或点击 Finish 按钮执行备份。
图 13. 使用 Control Center 进行离线备份 —— 总结
在执行期间，显示备份过程已经经过的时间。
图 14. 使用 Control Center 进行离线备份 —— 备份进度
最后，显示备份成功提示。
图 15. 使用 Control Center 进行离线备份 —— 备份成功
您可能会注意到，备份映像采用以下格式写入：
清单 3. 使用命令 CLP 进行离线备份 DB_alias.Type\Inst_name\NODEnnnn\CATNnnnn\yyyymmdd\hhmmss.Seq_num
在我的环境中，路径是 E:\temp\ABX84.0\DB2\NODE0000\CATN0000\20060519\151906.001。
恢复 —— 离线
在进行版本恢复时，需要使用一个离线全备份映像将数据库恢复到建立这个备份时的状态。恢复备份映像与进行备份一样简单。这也可以用命令 CLP 和 DB2 Control Center 两种方式完成。
使用命令 CLP 进行离线恢复
恢复离线备份与进行备份一样简单。在发出离线恢复命令之前，需要发出命令 force applications all 或新的 quiesce 命令（并在完成恢复之后发出 unquiesce 命令），从而让数据库进入维护模式；否则可能会收到错误 SQL1035N The database is currently in use. SQLSTATE=57019。
需要注意离线恢复的一些性质：
恢复可以覆盖现有的数据库，也可以改为新的数据库名。
可以根据备份时间戳恢复特定的映像。
需要 sysadm、sysctrl 和 sysmaint 等特权。
恢复在数据库级进行。不能进行表级或表空间级恢复。
有完整的恢复历史列表。
不能进行增量或 delta 恢复。
简单、容易而且灵活。
以下命令演示如何从离线备份映像进行恢复。
清单 4. 使用命令 CLP 进行离线恢复 restore db <your_db_name> from <your_backup_directory>
基本上只需要使用上面这样的简单命令。但是，有时候需要更大的灵活性，比如选择要恢复的特定备份映像、在恢复期间修改数据库的名称等等。为了完整，下面给出恢复语法（但是注意，有些选项只对在线恢复有意义）：
清单 5. 使用命令 CLP 进行离线恢复 RESTORE DATABASE source-database-alias { restore-options | CONTINUE | ABORT }
restore-options:
[USER username [USING password]] [TABLESPACE [ONLINE] |
TABLESPACE (tblspace-name [ {,tblspace-name} ... ]) [ONLINE] |
HISTORY FILE [ONLINE] | LOGS [ONLINE] | COMPRESSION LIBRARY [ONLINE]]
[INCREMENTAL [AUTOMATIC | ABORT]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}] |
FROM dir/dev [{,dir/dev} ... ] | LOAD shared-lib [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}]] [TAKEN AT date-time]
[TO target-directory] [INTO target-database-alias] [LOGTARGET directory]
[NEWLOGPATH directory] [WITH num-buff BUFFERS] [BUFFER buffer-size]
[DLREPORT file-name] [REPLACE HISTORY FILE] [REPLACE EXISTING] [REDIRECT]
[PARALLELISM n] [COMPRLIB lib-name] [COMPROPTS options-string]
[WITHOUT ROLLING FORWARD] [WITHOUT DATALINK] [WITHOUT PROMPTING]
使用 DB2 Control Center 进行离线恢复
使用 DB2 Control Center 进行离线恢复只需要两个步骤。
打开 DB2 Control Center。
右击要恢复的数据库。选择 Restore 选项。
图 16. 使用 Control Center 进行离线恢复 —— 右击选择 Restore 选项
在恢复向导的介绍页面中有三个恢复选项。如果需要决定恢复哪个数据库映像，但是当前的历史文件损坏了，那么历史文件恢复是非常有用的。备份映像中存储的历史可以单独恢复，它包含所有备份和恢复信息。对于本例，只使用默认选项。点击 Next 继续。
图 17. 使用 Control Center 进行离线恢复 —— 介绍
可以手工输入要恢复的映像。如果采用手工选项，那么需要指定备份映像的位置。也可以从 Available backup images 列选择一个可用的映像并将它移动到 Selected backup images。这个列表是使用历史文件中记录的信息填充的（记住，历史文件记录了备份和恢复的历史）。点击 Next 继续。
图 18. 使用 Control Center 进行离线恢复 —— 可用映像
图片看不清楚？请点击这里查看原图（大图）。
如果原来的容器路径不可用，或者需要恢复到非默认的容器路径，恢复期间的容器重定向是很有用的。我们只使用默认选项。点击 Next 继续。
图 19. 使用 Control Center 进行离线恢复 —— 容器
在向导的这一步中有 4 个选项。
quiesce 数据库让数据库进入维护模式，不允许应用程序连接它。
数据链接用来引用数据库之外存储的对象。
历史文件选项替换已经损坏的历史文件。
恢复日志文件选项恢复备份映像中保存的日志文件（适用于在线备份和恢复）。
选择 Queisce 数据库并点击 Next 继续。
图 20. 使用 Control Center 进行离线恢复 —— 选项
接受默认的性能选项。点击 Next 继续。
图 21. 使用 Control Center 进行离线恢复 —— 性能
接受默认的立即运行选项。点击 Next 继续。
图 22. 使用 Control Center 进行离线恢复 —— 调度
在总结页面上，检查设置。要想看到将发出的命令，点击 Show command 按钮。点击 Finish 运行恢复。
图 23. 使用 Control Center 进行离线恢复 —— 总结
显示经过的时间，然后显示成功恢复消息。
图 24. 使用 Control Center 进行离线恢复 —— 恢复成功
离线备份和恢复 —— 对照表
下面的对照表对比 MySQL 和 DB2 Express-C 中用于离线备份和恢复的特性和功能。通过这个对比，现有的 MySQL 用户能够了解 DB2 Express-C 中可用的特性并适当地使用它们。尽管 mysqlhotcopy 不是完全离线的，我认为最好对比 mysqlhotcopy 和 DB2 Express-C 的离线备份和恢复，在对比在线备份和恢复时再考虑 InnoDB 的 ibbackup。
| 特性/功能 | 在 MySQL 中的可用性（MyISAM —— mysqlhotcopy） | 在 DB2 Express-C 中的可用性 | 注释 |
| 日志模式 | × | √ | InnoDB 主要使用二进制日志。在 DB2 Express-C 中，使用循环日志支持离线备份和恢复。 |
| 需要的授权 | √ | √ | 对于 mysqlhotcopy，需要 SELECT 和 RELOAD 特权。在 DB2 Express-C 中，执行备份和恢复需要 sysadm、sysctrl 和 sysmaint 等特殊授权。 |
| 是否允许连接正在备份的数据库 | √ | × | mysqlhotcopy 使用 READ LOCK。用户不必断开连接。在 DB2 Express-C 中，在离线备份和恢复操作期间，不允许连接。使用 quiesce 让数据库进入维护模式，进行备份或恢复之后使用 unquiesce 让数据库回到一般操作模式。 |
| 数据库级备份和恢复 | √ | √ | 在 DB2 Express-C 中，提供这个特性。 |
| 表空间级备份和恢复 | × | × | 在 DB2 Express-C 中，离线备份只能在数据库级进行。 |
| 表级备份和恢复 | √ | √ | 在 DB2 Express-C 中，离线备份只能在数据库级进行。不需要对表进行备份以防止意外地删除表。在创建数据表空间期间 DB2 负责处理这个问题，表空间上的选项 DROPPED TABLE RECOVERY 是默认打开的。这个选项可以恢复被删除的表。 |
| 只包含数据的备份（没有索引） | √ | × | mysqlhotcopy 使用 --noindices 标志。 |
| 正则表达式支持 | √ | × | mysqlhotcopy 使用 --regexp 标志来匹配需要备份的数据库或表。在 DB2 Express-C 中，不支持正则表达式。因为备份在数据库级进行，只需选择需要备份的数据库。 |
| GUI 向导备份和恢复 | √ | √ | 到编写本文时为止，MySQL Administrator（版本 1.1.9）提供以下备份模式。
InnoDB 在线备份 锁定所有表备份 用二进制日志位置进行在线备份 一般备份 完整的备份 在 DB2 Express-C 中，提供这个特性。 |
| 命令提示级备份和恢复 | √ | √ | 在 DB2 Express-C 中，提供这个特性。 |
| 多个映像目标 | × | √ | 在 DB2 Express-C 中，提供这个特性。 |
| 对备份进行 throttling | × | √ | 在 DB2 Express-C 中，提供这个新特性，可以在高负载和低负载时间段更好地使用资源。 |
| 备份压缩 | × | √ | mysqldump 提供压缩功能，但是 mysqlhotcopy 没有提供。在 DB2 Express-C 中，提供这个特性。 |
| 提供备份和恢复历史列表 | × | √ | 在 DB2 Express-C 中，历史列表包含数据库备份和恢复的完整历史。这个历史列表捕获以下活动：
数据库或表空间被备份、恢复或前滚。 表空间被创建、修改、删除、quiesce 或重命名。 表被装载、重构或删除。 创建新的日志文件。 对日志文件进行存档。 等等 |
| 恢复成新的数据库 | × | √ | 在 DB2 Express-C 中，提供这个特性。 |
| 在恢复期间重新指定数据库文件（容器）的位置 | × | √ | 在 DB2 Express-C 中，提供这个恢复选项。 |
| 从预填充的列表（GUI）中选择备份映像 | × | √ | 对于 MySQL Administrator 恢复，需要指定备份映像的位置。在 DB2 Express-C 中，在一个 GUI 向导中提供这个特性。 |
| 备份和恢复 API | × | √ | 在 DB2 Express-C 中，嵌入式程序可以调用提供的备份和恢复 API。 |
| 与厂商 API 集成 | × | √ | 在 DB2 Express-C 中，提供了与厂商 API 集成的开箱即用功能。 |
| 改进备份和恢复的性能选项 | × | √ | 在 DB2 Express-C 中，可以实现更高的并发度并使用更大的缓冲区，从而改进备份和恢复过程。 |
| 对备份和恢复进行调度 | √ | √ | 这两种数据库都提供了调度程序。可以将备份和恢复任务安排在特定的时间以一定的时间间隔运行。 |
| 保存备份和恢复脚本（GUI） | × | √ | MySQL Administrator 允许将备份项目（而不是底层备份命令）保存到脚本中。在 DB2 Express-C 中，可以将备份和恢复命令保存到脚本中。 |
| 进度指示（GUI） | × | √ | 在 DB2 Express-C 中，提供了显示经过的时间的进度指示。 |
| 对备份和恢复操作的进度监视 | × | √ | 在 DB2 Express-C 中，要监视备份和恢复操作的进度，可以使用 LIST UTILITIES 命令。例如，list utilities show detail。 |
| 错误或成功日志 | √ | √ | 这两种数据库都提供了丰富的错误日志。 |
备份 —— 在线
与离线备份相似，我们也将演示在 DB2 Express-C 中进行在线备份的两种方法 —— 使用命令 CLP 和 DB2 Control Center。先看看使用命令 CLP 进行在线备份，然后使用 DB2 Control Center 进行在线备份。然后，以相同的次序讨论恢复。
在对数据库进行在线备份之前，首先需要将日志机制从默认的循环日志改为存档日志。可以在命令 CLP 中使用命令或在 GUI 向导中进行这个设置。可以在命令 CLP 中发出的命令都可以在 GUI 向导中得到，反之亦然。但是，我们将演示这两种方法。
在命令 CLP 中，发出以下命令：
清单 6. 打开存档日志 —— 命令 CLP db2 update db cfg for <your_db_name> using logarchmeth1 LOGRETAIN
为了确认设置，发出命令 get db cfg for <your_db_name> 并寻找 archlogmeth1 项。注意，将 archlogmeth1 参数设置为 LOGRETAIN 就会导致 logretain 参数被更新为 RECOVERY。这是默认的行为。如果想恢复这个设置，简便的方法是发出命令 reset db cfg for <your_db_name>。打开存档日志之后，DB2 会要求执行一次离线全数据库备份。
除了打开存档日志之外，还可能需要打开 mirrorlogpath 和 failarchpath。
要在 DB2 Control Center 中完成相同的任务，只需进行几次点击：
右击要打开存档日志的数据库。
图 25. 使用 DB2 Control Center 配置数据库日志
选中 Archive logging。
图 26. 配置数据库日志 —— 日志类型
尽管提供了三个选项，但是建议让 DB2 自动地对日志文件进行存档。使用自动选项时要求指定主存档日志路径和故障转移存档日志路径。
图 27. 配置数据库日志 —— 日志存档
使用默认设置。
图 28. 配置数据库日志 —— 日志存档
使用默认的日志位置。镜像路径可以防止单点故障。
图 29. 配置数据库日志 —— 日志位置
指定备份映像位置。
图 30. 配置数据库日志 —— 备份映像位置
指定备份选项。下面两步分别是调度和总结回顾。
图 31. 配置数据库日志 —— 备份选项
打开存档日志时需要执行一次离线全数据库备份。点击 Finish。
图 32. 配置数据库日志 —— 离线全数据库备份
使用命令 CLP 进行在线备份
使用命令 CLP 进行在线备份只需一行命令（完整的备份语法见清单 2）：
清单 7. 使用命令 CLP 进行在线备份 db2 backup db <your_db_name> online to <your_backup_path>
使用 DB2 Control Center 进行在线备份
使用 DB2 Control Center 对数据库或表空间进行在线备份只需要 6 个步骤，对于后 3 个步骤，就不再给出屏幕图了，因为它们与离线备份时一样。这 6 个步骤是：
介绍
映像
选项
性能
调度
总结
按照这些步骤对数据库或表空间进行在线备份。
注意，可以备份整个数据库，也可以备份数据库中的某些表空间。我们选择备份整个数据库以便说明几个问题。但是，如果选择表空间备份，那么必须在下个页面中选择要进行在线备份的表空间。
图 33. 使用 Control Center 进行在线备份 —— 介绍
选择存储备份映像的位置。
增量和 delta 备份是禁用的。要打开它们，需要打开配置参数 trackmod。另外，可以将日志包含在备份映像中。这对于发送日志尤其有用。
图 34. 使用 Control Center 进行在线备份 —— 选项
恢复 —— 在线
但是，在线恢复不像离线恢复那么简单，它提供了许多选项。我们将研究这些选项以及它们最适合在什么场景中使用。
使用命令 CLP 进行在线恢复
需要发出以下命令。但是注意，可以选择前滚到给定的本地时间（新特性）或 GMT 时间。
清单 8. 使用命令 CLP 进行在线恢复db2 restore db <your_db_name> from <your_image_location> taken at <your_image_timestamp>;
db2 rollforward db <your_db_name> to end of logs and complete;
另外，还可以发出简化的命令 RECOVER DATABASE，它会自动执行前滚任务。见以下示例。
清单 9. 使用命令 CLP 进行在线恢复 —— 数据库还原 db2 recover db <your_db_name> to end of logs;
或
db2 recover db <your_db_name> to <your_image_timestamp>;
使用 DB2 Control Center 进行在线恢复
现在看看主要的向导页面（超过 10 个），了解在线恢复的一些特性。
可以使用三个选项进行在线恢复：
图 35. 使用 Control Center 进行在线恢复 —— 介绍
有两个对象恢复选项，表空间或整个数据库。对于表空间级恢复，要在下个页面中选择要恢复的表空间。在我们的示例中，只进行整个数据库的恢复。
图 36. 使用 Control Center 进行在线恢复 —— 恢复对象
从预填充的列表中选择一个映像，或者手工输入映像位置。从预填充的列表中进行选择是最容易的。这个列表是从历史列表生成的。
图 37. 使用 Control Center 进行在线恢复 —— 可用映像
可以重新指定容器路径。我们采用默认路径。
图 38. 使用 Control Center 进行在线恢复 —— 容器
这里给出许多选项，下面解释这些选项：
可以只进行恢复而不进行前滚。不进行前滚会使数据库处于未决模式。
前滚到
日志的末尾 —— 当要求没有数据损失时通常使用这个选项。它会前滚到日志的末尾，达到最近的事务模式。
特定的本地时间（新特性） —— 它会前滚到特定的本地时间戳。由于 GMT 转换比较麻烦，所以添加了这个特性。
特定的 GMT 时间 —— 它会前滚到特定的 GMT 时间戳。
日志获取选项：
默认的存档日志路径 —— 这是默认路径。
替换的存档日志位置 —— 这相当于在前滚命令中指定 OVERFLOW LOG PATH，或者设置 OVERFLOWLOGPATH 配置参数。如果这两个参数都设置了，那么前者优先。
禁用存档日志的获取 —— 这由 NORETRIEVE 配置参数控制，禁用存档日志的获取。
图 39. 使用 Control Center 进行在线恢复 —— 前滚
选择完整的恢复并返回到活跃状态。
图 40. 使用 Control Center 进行在线恢复 —— 最终状态
对于向导的其余步骤（选项、性能、调度和总结），可以使用默认设置；因为这些步骤与离线恢复相似，这里就不重复解释了。最后会显示一个消息，指出恢复和前滚操作成功。
增量和 delta 备份和恢复
尽管这种特性主要用于使用 DB2 Universal Database™（UDB） Workgroup and Enterprise 的大型环境，但是为了本文的完整性，这里仍然讨论这个主题。
为了只对修改进行备份，DB2 UDB 在在线全备份（0 级）之上提供了增量（1 级）和 delta（2 级）备份。
增量备份是最近一次成功的全备份以来的所有修改的备份。这种备份形式也称为累积备份。每个后续的增量备份映像都包含前一个增量映像的全部内容，也就是包含上一次全备份以来的所有修改。在发生故障时，例如在星期六进行增量备份之后发生了故障，那么只能恢复上个星期日的全备份并应用星期六的增量备份。请参考下图。
图 41. 增量备份
delta 备份是最近一次成功的备份（包括全备份、增量备份和 delta 备份）以来修改的备份。在星期六发生故障时，可以恢复上个星期日的全备份并应用从星期一到星期六的 delta 备份。请参考下图：
图 42. delta 备份
为了进行增量或 delta 备份，需要打开 db cfg 参数 TRACKMOD。假设在每个星期日进行一次 0 级备份，在星期三和星期六进行 1 级备份，其他的日子进行 2 级备份，采用的步骤如下：
打开 TRACKMOD —— 发出命令 db2 update db cfg for icmnlsdb using trackmod on。
在星期日 —— 发出命令 db2 backup db icmnlsdb online。
在星期一 —— 发出命令 db2 backup db icmnlsdb online incremental delta。
在星期二 —— 发出命令 db2 backup db icmnlsdb online incremental delta。
在星期三 —— 发出命令 db2 backup db icmnlsdb online incremental。
在星期四 —— 发出命令 db2 backup db icmnlsdb online incremental delta。
在星期五 —— 发出命令 db2 backup db icmnlsdb online incremental delta。
在星期六 —— 发出命令 db2 backup db icmnlsdb online incremental。
要恢复增量备份，只需要两步，恢复增量数据库并前滚。
清单 10. 增量恢复 db2 restore db icmnlsdb incremental automatic taken at <your_image_timestamp>;
db2 rollfoward db <your_image_timestamp> to end of logs and complete;
在线备份和恢复 —— 对照表
与前面相似，下面的对照表对比 MySQL 和 DB2 Express-C 中用于在线备份和恢复的特性和功能。由于 InnoDB 的 ibbackup 具有在线和前滚功能，所以将它与 DB2 Express-C 进行对比。
| 特性/功能 | 在 MySQL 中的可用性（InnoDB —— ibbackup） | 在 DB2 Express-C 中的可用性 | 注释 |
| 日志模式 | √ | √ | ibbackup 要求使用二进制日志。在 DB2 Express-C 中，使用存档日志支持在线备份和恢复。 |
| 需要的授权 | √ | √ | 在 DB2 Express-C 中，执行在线备份和恢复需要 sysadm、sysctrl 和 sysmaint 等特殊授权。 |
| 是否允许连接正在备份的数据库 | √ | √ | 这两种数据库都允许用户在线执行自己的日常任务。 |
| 数据库级备份和恢复 | √ | √ | 这两种数据库都支持数据库级备份和恢复。 |
| 表空间级备份和恢复 | × | √ | ibbackup 不支持表空间级备份和恢复。 |
| 表级备份和恢复 | √ | √ | 尽管这两种数据库都不支持表级备份（注意，我们指的不是表转储），但是都可以恢复被删除的表。在 DB2 Express-C 中，在线备份只能在数据库级和表空间级进行。不需要对表进行备份以防止意外地删除表。在创建数据表空间期间，DB2 负责处理这个问题，表空间上的选项 DROPPED TABLE RECOVERY 是默认打开的。这个选项可以恢复被删除的表。 |
| 在恢复期间数据库/表空间是否需要离线 | √ | √ | InnoDB 恢复要求数据库离线。在 DB2 Express-C 中，在线备份和恢复只能在数据库和表空间级进行。 |
| 增量和 delta 备份和恢复 | × | √ | ibbackup 不支持增量和 delta 备份。在 DB2 Express-C 中，提供了这些特性，它们适用于不适合进行全数据库备份的大型数据库；只需要对修改进行备份。 |
| 前滚到特定的时间戳 | √ | √ | 要将 InnoDB 恢复到特定的时间戳，需要多做一些工作。需要根据时间戳手工整理 mysqlbinlog 生成的输出中的项目。在 DB2 Express-C 中，可以前滚到本地时间或 GMT 时间，或前滚到日志的末尾。 |
| 指定在主日志位置失效的情况下使用的替代日志位置 | √ | √ | 这两种数据库都支持这个特性。 |
| GUI 向导备份和恢复 | × | √ | ibbackup 基本上是一个命令工具。 |
| 命令提示级备份和恢复 | √ | √ | 在 DB2 Express-C 中，提供这个特性。 |
| 多个映像目标 | × | √ | 在 DB2 Express-C 中，提供这个特性。 |
| 对备份进行 throttling | × | √ | 在 DB2 Express-C 中，提供这个新特性，可以在高负载和低负载时间段更好地使用资源。 |
| 备份压缩 | √ | √ | 这两种数据库都支持压缩。 |
| 提供完整且丰富的备份和恢复历史列表 | × | √ | ibbackup 中提供的一个日志记录了备份和日志应用是失败还是成功。但是，它不够完整和丰富，没有记录对特定数据库发出的所有备份和恢复命令。在 DB2 Express-C 中，历史列表包含数据库备份和恢复的完整历史。换句话说，只要没有删除数据库，就会一直维护历史列表。这个历史列表捕获以下活动：
数据库或表空间被备份、恢复或前滚。 表空间被创建、修改、删除、quiesce 或重命名。 表被装载、重构或删除。 创建新的日志文件。 对日志文件进行存档。 等等 |
| 恢复成新的数据库 | × | √ | 在 ibbackup 中，无法在恢复数据库时对它进行重命名。在 DB2 Express-C 中，提供这个特性。 |
| 将日志包含在备份映像中 | √ | √ | ibbackup 备份日志包含在 ibbackup_logfile 中。在 DB2 Express-C 在线备份中，提供这个特性。 |
| 在恢复期间重新指定数据库文件（容器）的位置 | × | √ | 在 DB2 Express-C 中，提供这个恢复选项。 |
| 指定恢复期间的替代日志路径 | × | √ | 在 DB2 Express-C 中，提供这个恢复选项。 |
| 从预填充的列表（GUI）中选择备份映像 | × | √ | 在 DB2 Express-C 中，在一个 GUI 向导中提供这个特性。 |
| 备份和恢复 API | × | √ | 在 DB2 Express-C 中，嵌入式程序可以调用提供的备份和恢复 API。 |
| 与厂商 API 集成 | × | √ | 在 DB2 Express-C 中，提供了与厂商 API 集成的开箱即用功能。 |
| 改进备份和恢复的性能选项 | × | √ | 在 DB2 Express-C 中，可以实现更高的并发度并使用更大的缓冲区，从而改进备份和恢复过程。 |
| 对备份和恢复进行调度（GUI） | × | √ | 在 ibbackup 中可以设置 cron 作业来进行调度。在 DB2 Express-C 中，提供了调度程序。可以将备份和恢复任务安排在特定的时间以一定的时间间隔运行。 |
| 保存备份和恢复脚本（GUI） | × | √ | 在 DB2 Express-C 中，可以将备份和恢复命令保存到脚本中。 |
| 进度指示（GUI） | × | √ | 在 DB2 Express-C 中，提供了显示经过的时间的进度指示。 |
| 对备份和恢复操作的进度监视 | × | √ | 在 DB2 Express-C 中，要监视备份和恢复操作的进度，可以使用 LIST UTILITIES 命令。例如，list utilities show detail。 |
| 错误或成功日志 | √ | √ | 这两种数据库都提供这个特性。 |
Throttling
Throttling 是 DB2 Express-C 中提供的一种令人兴奋的新特性。DB2 Express-C 备份是一个具有 throttling 功能的实用程序，能够在低负载时间段占用更多的资源，在高峰时间段占用较少的资源。Throttling 是一种非常新颖的特性。为了使用这个特性，需要 sysadm、sysctrl 和 sysmaint 等授权。新的配置参数 UTIL_IMPACT_PRIORITY 指定进行 throttling 的实用程序的优先级。
设置 throttling 优先级的语法很简单。
清单 11. throttling 设置 set util_impact_priority for <utility_id> to priority
可以通过命令 list utilities 获得实用程序 ID。可以在以下范围内设置优先级：
优先级 0 —— 不进行 throttling。
优先级 1-100 —— 最高数值是 100，表示最高优先级。
util_impact_priority 参数与 util_impact_lim 配置参数结合使用。后者指定允许任何给定的 throttling 实用程序对服务器产生多大的影响（百分数）。默认值 100 表示不进行任何 throttling 。这个值只在 util_impact_priority 设置为非零值时有意义。
另一种设置 throttling 优先级的方法是使用 DB2 Control Center。
图 43. 设置 throttling 优先级
自动备份维护
自动备份维护是到目前为止最令人兴奋的主题。这是大多数 DBA 长期盼望的特性（我就是其中的一员！）。自动备份维护究竟是什么？自动备份维护是 DB2 Express-C 为提高数据库系统的可管理性而提供的功能之一。备份（而非 runstats 和表重构）的自动维护加入自管理的属性列表，可以由以下条件之一来调用该列表：
执行全数据库备份时（如果还没有这么做的话）。
上次全备份以来经过的时间。
对于在线备份（使用存档日志），达到使用的日志空间的阈值。
有两个数据库配置参数会影响自动备份维护，auto_db_backup 和 auto_maint。使用以下命令设置配置参数：
清单 12. 设置配置参数的命令 db2 update db cfg for <your_db_name> using auto_db_backup ON;
db2 update db cfg for <your_db_name> using auto_maint ON;
图 44. 自动备份维护 —— 配置参数设置
可以使用 DB2 Control Center 设置相同的配置参数。
对自动备份维护的选项进行配置的快速方法是使用 DB2 Control Center。
在右面板上（接近底部），点击 Maintenance。
图 45. 自动备份维护 —— 维护
在介绍页面上点击 Next。
点击 Next 修改设置。
图 46. 自动备份维护 —— 类型
在这个页面上，可以设置在线和离线备份维护时间窗。
图 47. 自动备份维护 —— 计时
负责的 DBA 可以得到通知。
图 48. 自动备份维护 —— 通知
其他一些活动或选项可以进一步影响备份维护：
图 49. 自动备份维护 —— 活动
图 50. 自动备份维护 —— 总结
其他实用程序
最后，DB2 Express-C 为对象的完整性检查提供了几个实用程序，可以探测数据损坏：
inspect —— 检查表对象和表空间的结构，确保它们是有效的。
db2dart —— 表示 Database Analysis and Reporting Tool，它检查数据库体系结构的正确性。
db2ckbkp —— 检查备份映像是否有任何损坏。这个程序检查特定的映像是否是可恢复的。
为了进行总体的对比，下面的表对比 MySQL 和 DB2 Express-C 在备份和恢复方面的差异。
| 特性/功能 | 在 MySQL MyISAM（mysqldump/mysqlhotcopy）中的可用性 | 在 MySQL InnoDB（ibbackup）中的可用性 | 在 DB2 Express-C 中的可用性 |
| 离线备份 | √ | √ | √ |
| 在线备份 | √ | √ | √ |
| 前滚功能 | × | √ | √ |
| 在备份期间锁定表 | √ | × | × |
| 灵活的存档日志写路径 | √ | √ | √ |
| 灵活的存档日志恢复路径 | √ | √ | √ |
| 灵活的日志重试控制 | √ | √ | √ |
| 用来防止单点故障的内置日志镜像 | × | × | √ |
| 对单一表进行备份和恢复 | √ （mysqldump） | √ | √ |
| 时间点恢复 | × | √ | √ |
| 备份和恢复进度监视 | × | × | √ |
| 数据库可以是本地或远程的 | × | × | √ |
| 备份和恢复的完整历史列表 | × | × | √ |
| throttling | × | × | √ |
| 备份映像的压缩 | √ （mysqldump） | √ | √ |
| 只备份数据（没有索引） | √ | × | × |
| 使用电子邮件或呼叫器进行通知的内置特性 | × | × | √ |
| 内置的调度 | × | × | √ |
| 检查备份映像完整性的实用程序 | √ （myisamchk） | √ | √ |
| 错误和成功日志 | √ | √ | √ |
| 手工备份和恢复 | √ | √ | √ |
| 自动备份维护 | × | × | √ |
| 增量和 delta 备份和恢复 | × | × | √ |
结束语
本文讨论了 MySQL 和 DB2 Express-C 备份和恢复机制的许多方面，包括体系结构、内存结构、日志类型以及备份和恢复类型。以一种并不详尽的方式对比了 MySQL MyISAM 和 Oracle 的 InnoDB 存储引擎与 DB2 Express-C 内置的备份和恢复机制之间的差异。尽管本文的主要目标读者是 MySQL DBA，但是对规划师和一般的 IT 人员也有帮助。
中查找“利用 MySQL 技能学习 DB2 Express: DB2 与 MySQL 的备份和恢复”更多相关内容
中查找“利用 MySQL 技能学习 DB2 Express: DB2 与 MySQL 的备份和恢复”更多相关内容更多精彩
赞助商链接
