本文基于具有一个管理节点和两个数据节点的 IBM Smart Analytics System 5600 环境。下载 部分提供了到示例脚本的链接，其中包含了本文所提到的，用于文件、环境、及配置设计备份的命令。可依据具体环境的兼容性需求，对这些示例进行编辑。一定要在非生产环境中测试命令。
DB2 实例可能由于各种原因而不可用：文件许可错误变更，文件删除，或者文件系统不可用。为了快速有效地应对这些情况，建议准备一个实例恢复计划。该计划应当在与 DB2 实例相关的环境中识别文件及设置，并定义一个备份策略，来提供发生任何类型的实例失败时所需恢复的文件。
实例与数据库的关系不是绝对的。删除已泄露的实例，不会删除相关的数据库。数据不会丢失。只要能够正确恢复实例配置与环境，就可以删除并重新创建实例，并对相关数据库进行分类。
通过在分区数据库环境中实施针对 DB2 实例的备份与恢复策略，可避免为了恢复实例配置而需要恢复整个服务器，这就减少了潜在停机时间。
图 1 说明了分区数据库环境中的 DB2 架构。在每个节点上执行 DB2 软件，并在每个节点上支持数据库分区。标有 IBMTEMPGROUP 的分区组横跨管理节点及两个数据节点。SDPG 与 IBMCATGROUP 分区组位于管理节点。PDGP 分区组跨越数据节点，这是表空间所在的位置。
图 1. DB2 实例恢复架构
实例配置
IBM Smart Analytics System 实施数据库分区，来提供大规模并行与线性能力。在这一环境中，对数据库（而不是实例）进行分区。在管理节点中创建了实例，然后为 DB2 软件所运行的相关节点（服务器）提供对 db2home 目录的共享。为使分区数据库正常运行，必须在每个数据节点中以相同的方式来配置操作系统环境，包括用户和组。通过管理节点来管理分区数据库，它协调了对数据库结构的访问与管理。
IBM Smart Analytics System 中每个数据节点具有多个数据库分区。为每个数据库分区分配了处理器、内存、以及 I/O 资源，并为其维护着单独的数据库容器、日志、索引、及其各自的数据库配置管理器。查询被提交给协调器函数，来依据查询进行检索。
本文所描述的测试集群由三个节点组成：beluga-bvn-05 是管理节点，beluga-bvn-06 与 beluga-bvn-07 是数据节点。管理节点具有单个数据库分区，每个数据节点都有 4 个数据分区。因此，集群总共包含了 9 个数据库分区。
在集群中所有的节点上创建实例，在 db2nodes.cfg 文件中所定义的所有数据库分区中创建数据库。清单 1 展示了 db2home/sqllib 目录中的示例 db2nodes.cfg 文件。它描绘了测试集群的配置。
清单 1.示例 db2nodes.cfg
0 beluga-bvn-05 0 1 beluga-bvn-06 0 2 beluga-bvn-06 1 3 beluga-bvn-06 2 4 beluga-bvn-06 3 5 beluga-bvn-07 0 6 beluga-bvn-07 1 7 beluga-bvn-07 2 8 beluga-bvn-07 3 |
在 IBM Smart Analytics System 环境中，DB2 实例主目录是位于管理节点中的 /shared_db2home 目录。该文件系统通过 GPFS 或者 NFS，供其他节点共享。其他节点将文件系统作为 /db2home 挂载到本地。因为每个节点的 /db2home 文件系统是到管理节点的挂载点，所以仅需在管理节点中对目录进行备份。
实例备份策略
用于 DB2 环境的备份策略应当包括操作系统、DB2 实例、以及 DB2 数据库。这样，可利用相应的备份来处理任何的恢复场景。通过最小化停机时间，来提高恢复效率。
将实例备份流程合并到整个备份计划中。在将变更的配置应用到环境的之前和之后，要备份实例配置。想备份一个实例，需要记录如下的所有相关细节：
- 软件版本
- 许可
- 用户和组
- 包含配置设置的文件
- 实例目录
这部分所列出的文件、设置、以及变量，是需要备份的全部内容。文件很小，并包含变量信息，该信息可用于在恢复完成后，对相关内容进行协调与验证。此外，如果想要更进一步的协助，则要把备份中所包含的细节信息提交给 IBM 支持人员。
本部分中的 4 个表中的每个表，描述了所需备份的 4 类文件及配置设置中的一个。表 1 和 2 代表在每个节点上所需备份的数据。表 3 和 4 代表在管理节点上所需备份的数据。可以 DB2 实例所有者的身份来执行这两个备份。 下载 部分中的两个脚本代表了这两个备份。
表 1. 备份操作系统文件
| 文件名 | 描述 |
|---|---|
| /etc/services | 包括 DB2 FCM 网络设置 |
| /etc/exports | 包含所导入文件系统的细节信息 |
| /etc/passwd | 用户信息 |
| /etc/hosts | 集群中每个节点的主机名和 IP 地址 |
| /etc/group | 组信息 |
| /opt/tivoli/tsm/client/api/bin64/dsm.opt | 备份存储管理器设置（TSM 用于测试） |
| /opt/tivoli/tsm/client/api/bin64/dsm.sys | 如果 TSM 与 DB2 日志归档与备份集成，拷贝该配置。 |
表 2. 捕获操作系统信息
| 命令 | 描述 |
|---|---|
db2level > db2level.out |
DB2 产品级别 |
oslevel > oslevel.out |
操作系统级别 |
df > df_g.out |
磁盘空间状态 |
mount > mount.out |
挂载状态 |
ulimit -a > ulimit.out |
Ulimit 设置 |
crontab -l > crontab.out |
Crontab 日程 |
id $Instance > id.out |
所用的实例 ID |
~/sqllib/java/jdk64/jre/bin/java -version > jdk.out |
Java JDK 版本 |
~/sqllib/java/jdk64/jre/bin/java com.ibm.db2.jcc.DB2Jcc -version > jcc.out |
JCC 版本 |
表 3.创建 DB2 主目录的 tar 文件
| 命令 | 描述 |
|---|---|
tar -cvf 2010-07-29.beluga-bvn-05.tar $HOME/* |
在管理节点上创建目录 DB2HOME/ 的 tar 文件 |
表 4. 输出并保存 DB2 Manager 及其相关配置
| 命令 | 描述 |
|---|---|
db2 get admin cfg > admin.cfg |
获取 db2 管理配置 |
db2set -all > db2set |
列出 DB2 环境注册变量设置 |
db2licm -l > db2licm.license.information |
获取 DB2 许可信息 |
db2cfexp db2cfexp.bak backup |
获取 DB2 配置导入数据 |
db2 list node directory > db2.list.node.directory |
获取节点目录清单 |
db2 list database directory > db2.list.database.directory |
获取数据库清单 |
db2 list dcs directory > db2.list.dcs.directory |
列出 DCS 目录 |
cp /sqllib/.rhosts .rhosts.bak |
Linux 平台上的可信主机。 |
db2 get dbm cfg > dbm.cfg |
获取数据库管理配置 |
$HOME/.profile |
拷贝实例所有者配置 |
$HOME/sqllib/db2nodes.cfg |
拷贝数据库节点机分区配置文件 |
实例故障场景
最有可能导致实例故障的情况包括人为错误、服务失败、或者文件损坏。失败的原因有很多，从变更的环境变量，到 DB2 软件所引用的操作系统配置文件中条目的修改，等等。可依据导致问题的原因是已知还是未知，来对恢复场景进行分类。如果导致问题的原因已知，那么可通过修改文件或者配置设置来纠正错误。如果原因不明，那就应当执行实例的完全恢复。在生产环境中，恢复的速度比发现问题的速度更重要。
理解在您的环境中发生什么恢复场景，并准备可用于针各种失败场景中，进行实例恢复的备份策略。以下部分描述了需要准备恢复计划来应对的 4 个典型的失败场景：
- 位于管理节点上的 db2home 目录被删除，或者无意中删除了实例。 管理节点上的 db2home 目录为分区数据库中的其他节点提供共享。如果主目录中的内容受损或被删除，实例将不可用。
- 实例配置损坏或受损。 配置或者 DB2 二进制文件受损、损坏、或者被删除，可能导致实例不可用。这类文件包括 .rhosts、db2nodes.cfg、和全局注册表。对环境变量的意外修改也会导致此类问题。
- 在数据、待机、用户、或者 InfoSphere Warehouse 应用节点中的共享 db2home 文件系统被删除。 在目录被删除的节点上，该实例将不可用。
- 实例目录的权限被意外变更。 如果 db2home 目录的文件或目录权限变更了,DB2 将不可用。
实例恢复过程
本部分描述了验证操作系统配置，以及删除并重新创建实例的过程。备份文件是指利用 下载 部分所提供的示例备份脚本，所创建的文件。在验证设置时，要确保将故障节点的配置与所备份的文件进行比对。需要根目录访问来编辑操作系统文件与设置。对于所有 DB2 相关的任务，都采用 DB2 实例所有者。
- 在受影响节点上验证操作系统的配置：
- 验证实例用户及受保护用户位于 /etc/passwd 中。
- 验证相关 DB2 组帐户位于 /etc/group 中。
- 将 /etc/services 和 /etc/hosts 与各自的备份文件进行对比，在必要时进行修改与恢复。
- 列出系统中相关的软件包，并将其与备份文件中所列内容进行对比。隔离任何的变更，并确认其原因。
- 对比并验证用户权限（ulimit）、挂载点（/etc/fstab），操作系统级别（oslevel）、以及 crontab 条目。确定任何变更的原因。
- 在受影响节点上删除受损实例：
- 利用
db2ilist命令来确定实例是否存在于实例清单中。如果实例完整，检查挂载及网络问题。利用db2iupdt来改正权限问题。 - 利用这一命令来删除特定的受损实例：
db2idrop <instance> - 利用命令
db2iset来删除相关配置信息与配置参数。例如：db2iset -d bcuinst2
- 利用
- 在受影响节点上创建并配置实例：
- 利用
db2icrt命令，在管理节点上创建实例。可在 DB2 软件的安装目录中发出该命令。在本文的测试集群中，该目录是 /opt/IBM/dwe/db2/V9.7/instance。所发出的命令是：
db2icrt -u bcufenc2 bcuinst2
其中bcufenc2和bcuinst2是实例所有者的用户 ID。 - 对比数据库管理者配置参数与 dbm.cfg.out 备份文件，在必要时进行恢复。
- 对比 $DB2HOME/sqllib/db2nodes.cfg 文件与备份版本，在必要时进行恢复。
- 对比注册表变量与 db2set.out 备份文件中的内容，在必要时进行重新应用。例如，可能需要将变量
DB2COMM设置为tcpip，内容如下：
db2set DB2COMM=tcpip - 利用备份的版本来对比 $DB2HOME/sqllib/userprofile 文件，必要时进行替换。
- 利用
- 在受影响节点上增加许可文件、对数据库进行分类，并启动 DB2：
- 从文件备份集中恢复 db2ese.lic 文件，并执行命令：
db2licm -a db2ese.lic
如果没有找到许可文件，db2start命令会返回 SQL8000N 错误。 - 依据备份集中 db2.list.database.directory 和 db2.list.node.directory 文件中的内容，来归类节点与数据库目录。例如，为在测试集群上进行这一操作，需要执行如下命令：
catalog tcpip node beluga-bvn-05 remote beluga-bvn-05 server 50000
catalog database BCUDB as BCUDB at node beluga-bvn-05 - 启动 DB2。如果正在使用 DB2 High Availability（HA）特性，参见与您环境相关的关闭及启动程序。
- 从文件备份集中恢复 db2ese.lic 文件，并执行命令：
从已知故障恢复
正如本部分所描述的，如果导致实例故障的原因是已知的，就不必进行完全恢复。可通过特定恢复步骤来修复网络、挂载以及权限问题。
- 非管理节点上的实例所有者主目录被删除。
非管理节点上的实例主目录是挂载的文件系统。尝试如下步骤来恢复此类场景：
- 利用挂载命令来挂载受影响节点上的文件系统：
mount /db2home - 作为实例所有者来启动数据库管理器。例如：
db2start注意：在高可用环境中，命令可能会不同。可参考您的用户指南。
- 利用挂载命令来挂载受影响节点上的文件系统：
- 实例目录的权限被意外修改。
在 db2home 目录中执行
chmod或者cp命令，特别是在 sqllib 目录中，可导致实例不可用，因为 DB2 软件可能会在尝试读取、写入、或者执行一个文件时失败。例如，在本文的测试集群中，在管理节点上执行chmod命令。这会导致db2start命令因文件许可错误而失败。清单 2 展示了失败的启动。
清单 2. 变更权限会导致失败
bcuinst2@beluga-bvn-05:~>cd ~/sqllib bcuinst2@beluga-bvn-05:~>chmod -R 444 * bcuinst2@beluga-bvn-05:~> db2start -bash: /db2home/bcuinst2/sqllib/adm/db2start: Permission denied SQL6031N Error in the db2nodes.cfg file at line number "<line>". Reason code "<reason-code>". Explanation: The statement cannot be processed because of a problem with the db2nodes.cfg file, as indicated by the following reason codes: 1 Cannot access the sqllib directory of the instance.
在此类场景中，可按照如下步骤来重新应用所有关系及权限值：
- ~/sqllib 中的每个文件应当由实例用户 ID 和 db2 实例组所有。可通过在管理节点上执行如下命令来实现：
chown db2inst2:db2igrp /db2home/bcuinst2/sqllib/*
其中实例和组账户分别是bcuinst2和db2igrp。 - 执行
db2iupt命令来更新 db2home 目录并基于所安装 DB2 软件来相应地替换命令文件。想利用db2iupdt来更新实例，首先需要停止为该实例所运行的所有进程。db2iupt命令替换 ~/sqllib 目录中的文件。清单 3 展示了如何在测试集群上完成这一步。
清单 3. 利用db2iupdt，基于所安装 DB2 软件，来更新实例。
beluga-bvn-05:/opt/IBM/dwe/db2/V9.7/instance # ./db2iupdt bcuinst2 DBI1070I Program db2iupdt completed successfully. bcuinst2@beluga-bvn-05:~> db2start 08/10/2010 15:09:16 1 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 5 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 2 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 3 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 7 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 6 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:18 4 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:18 8 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:30 0 0 SQL1063N DB2START processing was successful. SQL1063N DB2START processing was successful.
- ~/sqllib 中的每个文件应当由实例用户 ID 和 db2 实例组所有。可通过在管理节点上执行如下命令来实现：
您应当执行 DB2 实例备份与恢复策略，这样就可以在实例损坏，并导致不可用的情况下，快速而有效地进行恢复。通过为实例准备备份与恢复策略，可在遇到实例损坏问题时，不必进行整个操作系统恢复。这样可在此种条件下明显减少停机时间。