DB2 最佳实践: DB2 High Availability Disaster Recovery (HADR) 高可用性解决方案

　2009-11-26 00:00:00　来源：WEB开发网　　　

核心提示：摘要DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案，DB2 最佳实践: DB2 High Availability Disaster Recovery (HADR) 高可用性解决方案，

摘要

DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。

但是，由于用户的需求千差万别，因此不存在绝对理想的 HADR 配置。您的 HADR 环境设置、调优和维护决策通常是权衡利弊的结果。比如，您可能需要在数据库可用性要求和防止数据丢失之间进行权衡。好消息是，进行权衡并不一定意味着需要以牺牲某项需求为代价。

本文就设置和维护您的 HADR 环境提供了一些推荐方法，以帮助您在 HADR 提供的保护与性能和成本之间找到平衡点。本文重点关注以下领域：

为快速故障转移设置系统

调优参数以改进网络性能

调优参数以最小化 HADR 相关日志记录对性能的影响

在 HADR 环境中选择适当的表重组方法和负载操作

HADR 简介

HADR 从一个源数据库（称为主数据库）向一个目标数据库（称为备用数据库）复制数据更改。由于这是一个无共享架构，每个数据库都使用自己的存储器。HADR 在主数据库失败时提供快速故障转移。您还可以在实施更新和实施维护等场景中便捷地转换主数据库和备用数据库的角色，从而将停机时间减至最小。HADR 用途广泛，并被完全集成到 DB2 数据库，不需要任何特殊硬件和软件，使用标准 TCP 接口连接主数据库和备用数据库，其设置只需几个数据库配置参数。

HADR 的一个核心原则是：数据库的性能和可用性不能被某些挑战所影响，比如工作负载的突然波动（这影响备用数据库上的日志重放活动量）和服务器或网络失败（这将导致故障转移）。

为实现最优性能而调优您的 HADR 解决方案应该遵循一些基本原则，以避免一段时间后出现的潜在问题。另外，您需要了解几个涉及您的数据库维护行为的 HADR 设置项目。这个最佳实践文档将解决这些问题。本文着眼于为您设计 HADR 基础设施和配置数据库提供指南和推荐方法，从而改进 HADR 相关性能，特别是日志记录和故障转移速度。

设置您的系统

执行基础设施分析

在开始您的 HADR 实现之前，首先需要分析将要使用的系统的状况，这个步骤很关键。基础设施中的每个组件（比如服务器、存储器、网络和软件）都需要进行检查，以便发现潜在的故障点。如果可能，推荐构建备用组件（例如两个网络适配器、备用服务器电源）。分析行为的步骤之一是构建一个类似于表 1 所示的 HADR 示例分析图表，描述主地址和备用地址（如果适用）上的每个组件故障和在发生故障时的预期行为的细节。

表 1. HADR 分析图表示例

主地址	失败地址	失败描述	预期结果	停用影响
Site A	Site A	例如，AIX	Tivoli Systems	所有正在运行的
		服务器失败	Automation 在 5 秒内探测到 Site A 的失败并引发 Site B 上的 HADR 强制接管	事务将回滚，备用服务器接管并在 30 秒内对事务开放

在完成 HADR 设置的实现后，使用 HADR 分析图表创建一个测试计划以验证该实现和时间预期，从而确保高可用性和数据恢复业务要求能够得到满足（或有效预期能够得以设置）。

设置 HADR 的要求

设置 HADR 有下面几个要求：

主数据库和备用数据库上的操作系统与 DB2 版本和级别必须相同。惟一的例外发生在执行滚动更新时。

用于主数据库和备用数据库的 DB2 软件的位大小必须相同。

一个 TCP/IP 接口必须在 HADR 主数据库和备用数据库之间可用。

主数据库和备用数据库必须拥有相同的数据库名。

主数据库和备用数据库的表空间必须相同。

除这些要求之外，还有几个推荐方法可用于设置您的 HADR 系统。

为数据库日志使用高性能专用磁盘或文件系统

由于数据库更改由 EE（HADR 在 EEE 上不可用）中的单个日志流记录，这个流可能成为系统瓶颈。在日志文件系统上拥有 I/O 保障能力很重要。不要在日志文件系统和表空间文件系统之间共享设备。

使主数据库和备用数据库都能访问归档日志

使主数据库和备用数据库都能访问归档日志有以下几个好处：

主数据库是归档日志的惟一数据库，但是备用数据库接管后，新的主数据库（原来的备用数据库）开始归档日志。因此，最简单的办法是使所有日志归档到相同的位置。如果归档设备不共享，经过几次角色替换后，有些文件将位于一个设备上，而另一些文件将位于另一个设备上。这样，可能需要在 HADR 捕获（catchup）和其他恢复操作中进行手动干预，在主数据库和备用数据库之间移动或复制日志文件。

共享归档允许备用数据库在本地捕获状态期间直接从归档检索日志文件，主数据库无需读取文件并通过网络将它们发送到备用数据库。

对 HADR 主 - 备用连接使用专用网络

网络上用于 HADR 的其他流量（比如客户机 - 服务器通信、数据库备用和日志归档）可能会导致轻微的 HADR 性能问题。网络是 HADR 场景最重要的组成部分，因为将数据库更改从主数据库复制到备用数据库需要网络连通性，以便保持两个数据库同步。

无论是专用网络还是共享网络，HADR 网络的带宽必须比数据库日志生成速度要大（可以通过在一段时间内或在其他共享网络行为中监控数据库并查看生成的日志量来计算数据库日志生成速度）。

考虑使用多个网络适配器

使用多个网络适配器有助于确保一个适配器的失败不会导致失去整个网络。

考虑对数据库服务器使用一个虚拟 IP 地址

配置客户机以连接到使用虚拟 IP 地址的数据库，在故障转移时将虚拟 IP 地址从主数据库服务器重新导向备用数据库服务器。由于该 IP 地址在主数据库和备用数据库之间共享，您可以通过使应用程序只与拥有虚拟 IP 地址的数据库通信来防止数据库的两个副本都作为主数据库独立运行（这种情况有时称为 “分脑” 或 “二元主数据库”）。

考虑使用自动客户机重新路由

自动客户机重新路由（automatic client reroute）在发生故障转移时将客户机从主服务器重新导向到备用服务器。将您的系统和应用程序配置为使用一个虚拟 IP 地址或客户机重新路由，但不要同时使用二者。使用客户机重新路由而不是虚拟 IP 地址的一个好处是客户机重新路由是 DB2 的内置功能，不需要额外的硬件和软件。要了解关于自动客户机重新路由的更多信息，请参见“DB2 信息中心”自动客户机重新路由路线图。

调优参数

在更改配置参数前，首先要使主系统和备用系统上的数据库管理器（DBM）和数据库（DM）的配置参数保持一致。在主系统上进行的 DBM 和 DB 配置参数更改不会自动向备用系统广播，因此任何更新都需要同时在两个系统上手动完成。

对非动态数据库配置参数的更改需要对一个 HADR 对进行特殊考虑。

没有一个 HADR 配置参数是可动态更新的。另外，这些参数在两个 HADR 数据库上必须保持对称。如果 DB2 检测到主数据库和备用数据库上的有效 HADR 配置参数（比如 HADR_SYNCMODE 和 HADR_TIMEOUT）不同，则 HADR 连接将失败。结果是，一旦 HADR 参数已经在主数据库和备用数据库上更新，这两个数据库必须被再循环（取消激活并重新激活）以便使参数更新生效。如果只有一个数据库被再循环，则由于 HADR 配置中的不匹配，这个数据库将不能被激活。这种类型的更新需要将一个主数据库停用。

HADR 不要求非 HADR 配置参数具有对称性。因此，不能动态更新的数据库配置参数可以通过一个滚动更新流程更新，这不需要主数据库停用。首先，备用数据库更新，数据库被取消激活并重新激活。然后执行 HADR 接管，新的主数据库使用指定的数据库配置参数的新设置。新的备用数据库然后可以更新，数据库将被取消激活并重新激活。

特定于 HADR 的参数

选择适当的　HADR 同步模式

HADR 提供 3 种同步模式以满足多样化的运行环境和客户需求。同步模式是最重要的 HADR 配置参数。数据库配置参数 hadr_syncmode可以设置为以下值：

SYNC：主服务器上的事务只在相关日志写入主服务器和备用服务器上的磁盘后才提交。

NEARSYNC：主服务器上的事务只在相关日志写入主服务器上的磁盘且被备用服务器上的内存接收后才提交。

ASYNC：主服务器上的事务只在相关日志写入本地磁盘并发送到备用服务器后才提交。

一般而言，HADR 同步模式的选择取决于网络速度。对于 WAN，ASYNC 模式是推荐选项，因为传输延迟对 ASYNC 模式下的 HADR 性能没有影响。

对于 LAN，最常用的选项是 SYNC 和 NEARSYNC 模式。一种例外情况可能是：备用数据库只用于灾难恢复且业务需求能够容忍故障转移时的数据损失，或者工作负载太高，即使是 LAN 也不能处理。这时，您也许只能使用 ASYNC 模式。在 SYNC 和 NEARSYNC 之间进行选择时，要权衡 SYNC 模式可能带来的系统性能成本（源自通信开销）和 NEARSYNC 模式针对 “双失败” 提供的安全性。

SYNC 模式

SYNC 模式提供最好的数据保护。事务提交需要两份磁盘数据副本。这种模式的成本在于将数据写入备用数据库并将 ACK 消息发回主数据库所需的额外时间。

在 SYNC 模式中，日志只有在写入主磁盘后才发送到备用数据库。日志写入和复制事件按顺序进行。日志写入的总时间为：primary_log_write + log_send + standby_log_write + ack_message。这种模式中的复制通信开销比其他两种模式都高很多。

NEARSYNC 模式

NEARSYNC 模式几乎与 SYNC 模式一样出色，且其通信开销大量降低。在 NEARSYNC 模式中，发送日志到备用数据库和将日志写入主磁盘同时进行，备用服务器的内存接收到日志后立即发送一条确认（ACK）消息。在高速网络上，日志复制对主日志写入产生的开销很小甚至没有。

在 NEARSYNC 模式中，如果主服务器失败且备用服务器在将接收到的日志写入磁盘之前也失败，则数据将丢失。这是一种非常少见的 “双失败”场景。因此，NEARSYNC 是很多应用程序的首选，因为它以非常低的性能损失提供近乎同步的保护。

下面展示一个逼真的 NEARSYNC 性能分析示例：
网络流量：100Mb/ 秒

网络往返时间：0.1　毫秒　假定主服务器上的每次日志写入操作写入　4　个日志页（16　KB），则一次写入的日志复制时间为：　　16　*　1024　*　8　/　100M　+　0.0001　=　0.00141072　秒　

这相当于一个 11.6 MB/ 秒的速度，这个速度与磁盘写入速度属于同一个级别。由于主服务器上的磁盘写入和到备用服务器的日志复制同时进行，因此日志复制开销很小甚至没有。鉴于如今 Giga 位的网络已经很普遍，这个示例中使用的 100Mb/ 秒的网络实际上是一个相对较慢的网络。在一个 Giga 位网络中，日志复制速度将为 106MB/ 秒，这个速度比许多磁盘的速度还快。

ASYNC 模式

在 ASYNC 模式中，发送日志到备用数据库和将日志写入主磁盘同时进行，这与 NEARSYNC 模式完全相同。由于 ASYNC 无需等待来自备用服务器的 ACK 消息，因此主系统流量是日志写入速度和日志发送速度二者之间的最小者。ASYNC 模式非常适用于 WAN 应用程序。网络传输延迟不会影响这种模式的性能，但如果主数据库失败，则正在传输的日志丢失（没有复制到备用数据库）的几率更大。

HADR 模拟器

您也可以使用 IBM DB2 High Availability Disaster Recovery (HADR) 模拟器来估计不同同步模式下的 HADR 性能。这个模拟器是非常有用的 HADR 计划和调优工具。您可以在部署 HADR 之前运行模拟器来预览日志记录性能。如果 HADR 已经部署，可以运行模拟器来查看同步模式更改后可以获得的性能。所有这些操作都可以在数秒内完成，并且对生产系统毫无影响。

调优 DB2_HADR_BUF_SIZE

将 DB2_HADR_BUF_SIZE 注册表变量设置为预期的工作负载波动大小，这可以配置您的 HADR 备用日志接收缓存以吸收主工作负载中的波动。

备用数据库的日志接收作为生成者将日志写入接收缓存，日志重新播放作为使用者读取日志。如果使用者太慢，缓存就会填满，备用数据库不能接收更多日志。对于
SYNC 和 NEARSYNC 模式，主数据库在备用数据库缓存填满时还能够送出一个日志刷新，但备用数据库不能将其接收到它的接收缓存内。主数据库将被阻塞，等待 ACK 消息。对于 ASYNC 模式，主数据库将持续发送日志，直到网络管道填满，当它试图继续发送日志时，将收到网络堵塞错误消息。对于 SYNC 和 NEARSYNC，如果网络管道不能容纳一个刷新，主数据库也会收到堵塞错误消息。堵塞错误通过使用数据库快照或 db2pd 命令等常见 HADR 监控机制报告。

执行以下步骤来测量工作负载波动：

临时对备用数据库执行取消激活操作。

检查您的 HADR 快照或 db2pd 输出中的 “primary log position（主数据库日志位置” 字段（日志位置是当前日志在日志流中的字节偏移量）来测量主数据库日志速度。如果主数据库不支持 HADR，则（通过 CLP 命令、快照视图或 SNAP_GET_DB 函数）从数据库快照检查与日志写入相关的字段。

监控 HADR 备用接收缓存使用情况

调优备用缓存大小时，使用 db2pd 命令和 -hadr 选项监控 HADR 备用接受缓存的使用情况，这将报告缓存使用的百分比。100% 表明缓存已满——即日志接收比日志重新播放快，0% 表明缓存为空——即没有可以播放的内容。

为了进行调优，要定期采样缓存使用情况。如果百分比频繁达到 100%，则考虑使用更大的缓存。如果百分比总是很低，则考虑减少缓存大小。如果百分比偶尔很高，那么您必须平衡吸收波动的好处和增加内存的成本。

较大的备用接收缓存将会吸收主数据库工作负载中的波动。但是，如果备用数据库上的持续重新播放速度比主数据库上的日志生成速度要低，则这不会有所帮助。建议备用服务器和主服务器采用相同的硬件，以便备用数据库总体重新播放速度能够跟上主数据库日志生成速度。如果备用数据库速度跟不上主数据库，就会减慢主数据库。

调优 hadr_timeout

hadr_timeout配置参数确定 HADR 流程在确认一个通信准备失败之前等待的秒数。如果一个数据库没有在 hard_timeout值设定的秒数内接收到来自伙伴数据库的心跳消息，该数据库将认为连接失败并关闭 TCP 连接。调优这个参数意味着平衡 HADR 迅速探测网络失败的能力和出现“错误警告”的可能性。如果 hadr_timeout配置参数设置得太长，则 HADR 流程不能迅速探测网络或伙伴数据库失败。主数据库最终会为一个日志复制尝试等待很长时间，从而导致主数据库上的事务堵塞。如果该值设置得太短，则 HADR 流程将收到太多的错误警告，从而频繁中断连接。如果对等窗口启用
（即 hadr_peer_window参数设置为非零值），则每次连接断开将在已配置的对等窗口大小期间使主数据库处于断开对等状态（disconnected peer state），从而导致主数据库上的事务堵塞。

注意，只要探测到网络错误或远端关闭，HADR 数据库就会断开连接。hadr_timeout只是检测连接失败的最后手段。通常，当数据库崩溃时，它的宿主机器将清理它的开放连接并通知远端这个数据库已关闭。只有机器崩溃会导致远端挂起直到超时。各种网络层都可能有自己的心跳机制，能够在 HADR 之前探测到连接失败。只要失败被报告给主机，HADR 就将探测到它，因为 HADR 通过轮询持续监控连接的健康状态。

推荐的 hadr_timeout 参数设置至少为 60 秒。设置 hadr_timeout参数时，要考虑网络稳定性和机器响应时间。如果网络拥有不规则或长时间传输延迟，则应使用更长的超时设置。HADR 流程以固定间隔发送心跳消息。但发送和接收的敏捷程度和流程自身在主机上的计划运行敏捷程度一样。有些事件（如交换）可能会阻止流程按时发送或接收消息。

调优 hadr_peer_window

如果主数据库在指定时间（对等窗口）内失败，hadr_peer_window数据库配置参数支持无数据损失故障转移。当 HADR 主数据库处于对等状态时，日志在写入本地磁盘时被直接发送到内存日志缓存。如果连接断开，主数据库在 hadr_peer_window 设置的秒数内堵塞日志记录且不提交任何事务。如果主数据库在这个窗口时间内失败，我们知道没有“已提交但未复制”的事务，到备用数据库的故障转移不会损失任何数据。

对等窗口启用（设置为非零值）时，处于对等状态下的主数据库以固定间隔向备用数据库发送消息，指定一个“对等窗口结束（peer window end）”时间戳，主数据库在到达这个时间戳后将阻塞日志，断开与备用数据库的连接。可以使用数据库快照或 db2pd 工具等常用 HADR 监控机制从主数据库或备用数据库获取当前对等窗口结束时间戳。主数据库失败时，您可以检查备用数据库上的对等窗口结束时间戳，看看主数据库是否在对等窗口时间内失败。如果失败的话，您可以执行一个没有数据损失的故障转移。否则，主数据库可能已经、也可能没有在对等窗口启用后提交事务；这时，您需要考虑数据丢失风险，您也许应该选择修复并重新启动失败的主数据库，而不是执行故障转移。

为了与集群管理器轻松集成，TAKEOVER BY FORCE 命令添加了一个 PEER
WINDOW ONLY 选项。通过这个选项，该命令只在当前时间早于对等窗口结束时间时执行故障转移。检测到主数据库失败时，集群管理器可以发出 TAKEOVER BY FORCE PEER WINDOW ONLY 命令来启动一个故障转移。使用这个选项最小化自动化故障转移导致数据损失的几率。进行自动故障转移时推荐使用这个选项（DB2 集群管理器使用这个选项）。在这样的配置中，对等窗口时间不应低于集群管理器探测到主数据库失败并使用故障转移对该失败做出反应所需的时间。使用以下公式进行估算：

　hadr_peer_window设置　>=　响应时间　+　安全　边际　+　心跳间隔　　其中：　　响应时间　=　自动化软件探测到失败并调用　HADR　接管的预计时间　　安全边际　=　5　秒，主　-　备用机器时钟同步的安全边际　　心跳间隔　=　MIN（hadr_timeout值　/4，hadr_peer_window值　/4，30　秒）　

表 1展示这个公式背后的基本原理。心跳和主数据库失败之间的时间是心跳间隔（heartbeat interval）（这是最坏的情况，主数据库正好在它将要送出另一次心跳之前失败）。DBA 或集群管理器探测失败并通过发出 TAKEOVER 命令进行响应的时间称为响应时间（response time）。“对等窗口结束” 时间戳在主系统上生成并通过心跳消息发送到备用系统。当它与 TAKEOVER BY FORCE PEER WINDOW ONLY 命令执行期间备用系统上的当前时间相比较时，一个 5 秒的安全边际（safety margin）用于比较，以处理不够完美的主服务器和备用服务器时钟同步。（建议您使用类似于网络时间协议的方法同步主服务器和备用服务器时钟。）这样，对等窗口大小应该至少等于心跳间隔 + 响应时间 + 安全边际

图 1. 对等窗口大小
DB2 最佳实践: DB2 High Availability Disaster Recovery (HADR) 高可用性解决方案

图片看不清楚？请点击这里查看原图（大图）。

为避免数据损失，接管命令不需要在对等窗口结束之前发出。对等窗口结束后，您仍然可以分析对等窗口结束时间（通过数据库快照和 db2pd 等常用 HADR 监控界面在主系统和备用系统上报告）并将其与主系统失败时间比较；只要主系统失败时间早于对等窗口结束时间，您就可以发出接管命令进行无损失故障转移。如果您在对等窗口结束后发送接管命令，不要使用“peer window only”选项，该选项用于集群管理器在主系统失败后迅速执行安全的故障转移，以便提供最小的停机时间。

从主系统到备用系统的 “对等窗口结束”消息实际上作为心跳消息实现。这样，启动对等窗口的系统上的心跳间隔将考虑对等窗口大小（使用上述公式）。备用系统上显示的对等窗口结束时间是主系统上的对等窗口结束时间之后的一个更新间隔（即心跳间隔），这样，上述对等窗口设置公式将再加上一个心跳间隔。

上述公式只考虑了自动故障转移。其他因素，比如对数据损失的低容忍度、可能的网络或备用系统失败时间以及对网络分区的探测和反应时间，也可能需要更长的对等窗口。例如，如果网络或备用服务器失败，主服务器将在对等窗口失效后继续处理事务，且没有 HA 保护。如果在备用服务器上拥有第二份数据备用的业务需求状态非常重要，则可能需要一个更长的对等窗口来阻塞主服务器以便 DBA 干预。

hadr_peer_window的默认值为零，这意味着一旦连接断开，主服务器将解锁所有等待事务并恢复日志记录。这在故障转移期间面临数据丢失风险的情况下提供最大的可用性。这个参数可以从零调优到数年（有效值甚至到无限期），允许用户调优可用性和数据丢失风险之间的平衡。本质上，一个超长的对等窗口实际上遵守“主系统上的事务提交要求备用系统上存在第二份备用”这一规则。

即使可用性很重要，hadr_peer_window的推荐设置也至少为几秒，因为它能极大地减少一次滚动失败中数据丢失的几率（在滚动失败中，先是网络失败，然后是主机器失败）。在这个间隔期间，如果 hadr_peer_window值为零或非常短，主服务器将把没有经过复制的事务提交到备用服务器，这个数据将在故障转移中丢失。默认值为零是为了实现向后兼容。

一旦对等窗口启用，主服务器将在配置期间内阻塞事务，不管连接断开的原因是什么：网络错误、备用服务器失败、超出 hadr_timeout值、超出 DB2_HADR_PEER_WAIT_LIMIT 注册表变量设置。这确保备用服务器上的 “peer window only” 故障转移总是安全的。但是，如果连接由于备用服务器正常关机而关闭，则主服务器在连接关闭时绕过对等窗口并恢复日志记录。对等窗口和 hadr_timeout相互独立，依次生效。对等窗口规定连接断开后持有主服务器事务的时间，而 hadr_timeout 规定断开连接的条件。类似地，对等窗口和 DB2_HADR_PEER_WAIT_LIMIT 也相互独立，因为 DB2_HADR_PEER_WAIT_LIMIT 规定通过断开连接结束主服务器日志记录等待的条件。

使用对等窗口时，将心跳间隔的值从默认值 120 秒降低到 30 秒。

调优 DB2_HADR_PEER_WAIT_LIMIT

设置 DB2_HADR_PEER_WAIT_LIMIT 注册表变量允许您阻止因为较慢或堵塞的备用数据库而导致的数据库日志记录堵塞。如果主数据库上的日志记录在对等状态中堵塞了指定的秒数，DB2_HADR_PEER_WAIT_LIMIT 值确定 HADR 主数据库在断开连接前等待的时间。主数据库可能正在等待发出日志（等待网络拥堵结束），或者在发出记录后等待从备用数据库返回的 ACK 消息。

连接断开时，如果对等窗口启用，则主数据库在对等窗口大小期间内持续阻止日志记录；反之，它立即恢复日志记录。这样，当 DB2_HADR_PEER_WAIT_LIMIT 启用（非零值）时，最大客户机堵塞时间等于 DB2_HADR_PEER_WAIT_LIMIT 值加上
hadr_peer_window 值。

设置 DB2_HADR_PEER_WAIT_LIMIT 值时的主要考虑是客户机响应时间。对于 DB2_HADR_PEER_WAIT_LIMIT 和 HADR_PEER_WINDOW，更小的值意味着更好的客户机响应，但是故障转移中的数据丢失风险可能更高。

可以先后使用 DB2_HADR_PEER_WAIT_LIMIT 和 hadr_timeout 进行目标既定调优。可以指定较短的 hadr_timeout 来迅速探测网络问题和备用数据库崩溃，同时设置相对较长的 DB2_HADR_PEER_WAIT_LIMIT，以便只要主数据库和备用数据库连接就启用复制。反之，当数据库不处于对等状态时，可以指定较短的 DB2_HADR_PEER_WAIT_LIMIT 获取更好的客户机响应时间，同时使用更长的 hadr_timeout 来避免频繁的连接断开。

调优 DB2_HADR_SOSNDBUF 和　DB2_HADR_SORCVBUF

可以使用 DB2_HADR_SOSNDBUF（套接字发送缓存大小）和 DB2_HADR_SORCVBUF（套接字接收缓存大小）注册表变量来优化 HADR TCP 连接，这不会影响系统上的其他 TCP 连接。设置 TCP 窗口大小的一般规则是：TCP 窗口大小 = 发送速度（send rate）×往返时间。

在 WAN 系统上，这可能意味着比系统默认值更大的设置，因为 WAN 系统上所需的往返时间相对较长。如果窗口大小太小，则网络不能充分利用其带宽，HADR 这样的应用程序经历比正常带宽更小的流量。过大的窗口大小除了占用更多内存外没有其他危害。

DB2_HADR_SOSNDBUF 和 DB2_HADR_SORCVBUF 在主数据库和备用数据库上应该拥有相同的设置。

HADR 模拟器可以用于找出主机器和备用机器之间的最优网络设置，运行模拟器只需几秒钟，且对实际数据库系统没有影响。相反，在数据库上更新这些参数则需要停止并重新启动数据库实例以使更新后的参数生效。建议您首先试验模拟器，然后将适当的值应用到数据库。

客户机 - 服务器通信参数调优 DB2TCP_CLIENT_RCVTIMEOUT

DB2TCP_CLIENT_RCVTIMEOUT 注册表变量指定客户端在一个 TCP/IP 接收操作中等待数据的秒数。超出等待时间时，客户机认为连接失败；如果启用了客户端重新路由，则尝试重新路由。将 DB2TCP_CLIENT_RCVTIMEOUT 设置为较低的值可以最小化探测 HADR 主数据库是否失败的等待时间。但是，不要将其设置得比最长的运行查询更短，否则您将收到错误警告。

数据库参数

将　logfilsiz 设置为适当大小

通过设置 logfilsiz配置参数使用大小适中的日志文件，这个大小通常不超过几百
MB。创建、归档、检索和删除一个非常大的日志文件可能需要很长时间，从而导致系统性能降低。

主数据库和备用数据库上的 logfilsiz设置应该一致。为了最大化备用数据库上的所有已复制日志文件与主数据库上的对应源文件之间的互换性，主数据库上的 logfilsiz设置将应用到备用数据库上，不管备用数据库上的实际设置如何。但是，接管行为发生后，新的主数据库（原来的备用数据库）在接管发生后的第一次数据库重新激活时使用其本地配置值。

将　logindexbuild 设置为 ON

将 logindexbuild配置参数设置为 ON 表示：您的索引创建、重新创建和重组操作将被完全记录为日志。尽管这意味着主数据库上的索引构建过程将耗费更多时间且需要更多空间，但这些索引将在 HADR 日志重新播放期间在备用系统上重新构建并在故障转移发生时可用。如果 logindexbuild设置为 OFF，当备用数据库重新播放一个构建或重组事件时，由于日志不包含构建事件数据，此前构建的索引将被标记为无效。如果主系统上的索引构建没有记录日志且故障转移发生，接管结束之后保留的任何无效索引必须重新构建才能在新的主系统上接受访问。

对于以下情形，您可能不希望对索引行为进行日志记录：

临时使用索引（例如，在中间表上）。

索引数据非常大且表不需要经常访问（这时，indexrec配置参数应该设置为 RESTART）。

没有足够的活动日志空间来支持索引构建的日志记录。

可以使用 LOG INDEX BUILD 表属性在单独的表级别覆盖数据库级别的 logindex
build设置。

将 indexrec 设置为 RESTART

将 indexrec配置参数设置为 RESTART 表示：任何无效索引都将在接管操作结束时被重建。使用这个设置，在接管操作结束时，新的主数据库将搜索所有无效索引并在后台重建它们。重建索引并不阻止客户机连接到新的主数据库。

调优　 softmax

softmax配置参数设置确定软检查点的频率和恢复范围，从而有助于崩溃恢复流程。
softmax设置的值应该权衡备用数据库上的前滚性能和崩溃恢复速度。较低的值减少需要处理的日志记录数量和崩溃恢复期间需要处理的冗余日志记录的数量，但较低的值也会降低前滚性能，因为这需要更频繁地缓存池刷新。

与客户机重新路由相关的数据库参数

设置 DB2_MAX_CLIENT_CONNRETRIES 和　DB2_CONNRETRIES_INTERVAL

设置 DB2_MAX_CLIENT_CONNRETRIES 和 DB2_CONNRETRIES_INTERVAL 注册表变量允许您配置自动客户机重新路由的重新尝试行为。第一个变量指定重新尝试连接的次数，第二个变量指定两次连续尝试之间的间隔时间。如果这两个变量都没有设置，则自动客户机重新路由特性将在最多 10 分钟内重复尝试连接数据库。

数据库管理和维护

选择适当的重组方法

在线和离线重组操作都是已复制的操作。但是，它们所复制的方法是不同的，并会影响操作的选择。根据您是否希望受影响的表格和索引在操作期间变得可用来选择重组方法。

执行一个在线重组以维护受影响的表和索引的可用性

在一个在线（或就地）重组期间，所有操作都以精细的粒度记录到日志。对表和索引的更改随重组进展而被记录和复制。因此，HADR 能够以比离线重组更平均的节奏复制操作。但是，操作生成的日志量可能对系统有较大的影响。

如果在线重组期间发生故障转移，则重组不能在新的主数据库上恢复，其原因是状态文件存储在数据库之外且没有被复制。但是，重组可以在新的主数据库上重新启动。

在受影响的表和索引不可用时执行一个离线重组

离线（或典型）重组比在线重组拥有的复制粒度低得多，但是，对系统的影响取决于操作是否正使用索引重新集群化（reclustering）。

在集群化重组中，操作通常针对每几百（千）条受影响的行执行一次记录。如果您的数据库处于对等状态，这可能会导致断断续续的主数据库事务堵塞，因为备用数据库必须为一条日志记录一次性重新播放大量更新。备用数据库重新播放可能会阻塞很长时间以至于备用接收缓存填满，导致主数据库堵塞。

非集群化重组只在主数据库上的重组完成后生成一条日志记录。这种方法对 HADR 对的影响最大，因为备用数据库在从主数据库接收到关键日志记录后将从头执行整个重组。操作实际执行了两次，先在主数据库上，然后在备用数据库上。

由于备用数据库必须重新播放重组记录，因此它的日志接收缓存可能被填满并停止从主数据库接收日志，如果 HADR 对处于对等状态，这会导致主数据库日志记录堵塞。

如果您必须执行大型离线重组，考虑以下推荐方法：

在备用数据库重新播放重组时临时禁用 HADR以避免主数据库堵塞。具体操作方法是在主数据库上的重组开始前取消激活备用数据库。重组在主数据库上完成后，重新激活备用数据库并允许它跟上主数据库。重组记录将在捕获状态中重新播放，这不会堵塞主数据库日志记录。但是，取消激活备用数据库将导致一个时间窗口，其中高可用性和灾难恢复不可用。相反，您可以在主数据库上运行“stop HADR”和“start HADR”而不是取消激活并重新激活备用数据库，以使主数据库在重组期间不处于对等状态。

将 HADR_PEER_WAIT_LIMIT设置为使主数据库自动断开对等状态。这个设置的好处是不需要任何手动干预，缺点是自动中断只在主数据库上的事务持续堵塞了 HADR_PEER_WAIT_LIMIT 指定的时段后才被触发。

在　HADR 环境中执行负载操作

HADR 环境中的负载操作需要特殊考虑，因为只有一个成功的 LOAD COPY YES 被复制到备用数据库上。所有其他类型的 LOAD 操作可能导致备用数据库不再适合充当有效的故障转移备选数据库，因为 HADR 对之间的数据不再一致。为了避免这种情况，执行以下小节介绍的推荐方法。

执行一个不可恢复负载（仅当负载操作无需在备用数据库上复制时）

有时，您也许不希望将表复制到备用数据库（例如，如果该表是将要丢弃的中间表）。不可恢复负载导致目标表被标记为坏表，备用数据库将跳过关于该表的未来日志记录。要监控这一点，可以在备用数据库上的 db2diag.log 中查找 ADM5571W 消息。

如果一个不可恢复的或失败的 LOAD ... COPY YES 操作将一个表空间标记为坏空间，则要识别影响备用数据库在故障转移操作中的可行性的潜在问题。发出
db2pd – db <dbname> -tablespaces 命令识别处于非常规表空间状态的表空间。查看为非零值生成的 Tablespace Statistics 报告的“State”列，注意会影响 HADR 重新播放的状态（比如，0x100 表示恢复等待，0x80 表示前滚等待，0x4000 表示离线、不可访问）。

确保负载副本在负载重新播放时对备用数据库可用

LOAD ... COPY YES 操作成功完成后，数据仅当备用数据库能够通过加载命令中指定的路径或设备访问副本时才能复制到备用数据库上。考虑使用一个共享设备（如 NFS）实现此目的。如果您通过类似于实际转移磁带的方法来传输副本，建议在主数据库启动负载之前停止备用数据库。一旦主数据库完成负载且负载可用于备用数据库，则启动备用数据库，这时，备用数据库将重新连接到主数据库并重新播放该负载。

如果负载副本不能在备用数据库上访问，则在其中存储该表的表空间在备用数据库上被标记为坏空间，备用数据库跳过关于该表空间的未来日志记录。在这种情况下，备用数据库必须从一个备用映像重新构建，该备用映像是负载操作在主数据库上发出后创建的。要监控这种情况，浏览备用数据库上的 db2diag.log，查找识别 LOAD命令所针对的表的消息，副本所在的不可访问的路径，标记为坏空间的每个表空间的消息。如果故障转移在您探测到这种情况之前发生，浏览主数据库上新的 db2diag.log，查找表明表空间状态异常的消息。

将　DB2_LOAD_COPY_NO_OVERRIDE 注册表变量设置为 COPY YES（当负载操作频繁时）

当 DB2_LOAD_COPY_NO_OVERRIDE 注册表变量设置为 “copy yes <copy destination>” 时，所有 LOAD ... COPY NO 操作将转换为 LOAD ... COPY YES，并使用该注册表变量中指定的复制目标。

小结

执行基础设施分析。

为数据库日志使用独立的、高性能磁盘或文件系统。

使主数据库和备用数据库都可访问归档日志的地址。

为主 - 备用连接使用专用网络。

使用多个网络适配器。

考虑为数据库服务器使用一个虚拟 IP 地址或自动客户机重新路由。

选择适当的 hadr_syncmode。

调优 DB2_HADR_BUF_SIZE、hadr_timeout、hadr_peer_window 和 DB2_HADR_PEER_WAIT_LIMIT。

调优 DB2TCP_CLIENT_RCVTIMEOUT、DB2_HADR_SOSNDBUF 和 DB2_HADR_SORCVBUF。