在DB2中部署QReplication：包含哪些工作？

以下各节将介绍部署 Q Replication 所需的必要决策和操作，从规划到系统设置和生产操作。需要执行的操作包括： 1. 安装前验证和容量规划，包括为 DB2 启用复制 2. WebSphere MQ 和 Q Replication 许可的安装和配置 3. 复制订阅的定义；也就是说，您希望复制

以下各节将介绍部署 Q Replication 所需的必要决策和操作，从规划到系统设置和生产操作。需要执行的操作包括：

1. 安装前验证和容量规划，包括为 DB2 启用复制
2. WebSphere MQ 和 Q Replication 许可的安装和配置
3. 复制订阅的定义；也就是说，您希望复制哪些表？
4. 操作：开始和停止复制，处理中断
5. 监视、调节和故障排除，以便从解决方案获得最大回报。

Q Replication 预安装步骤和容量规划

Q Replication 是一种日志捕获/事务重放技术；也就是说，从 DB2 恢复日志中捕获数据更改，并重构 SQL 语句，以便在目标上重放它们。 在目标上，出于 DB2 容量规划和调节的目的，DB2 实例必须拥有足够的容量来处理所复制的实际SQL 工作负载。一般而言，应用程序在源系统上所需的任何性能调节也适用于目标系统。

在源数据库上，针对 DB2 的主要 Q Capture 活动是读取日志，这一般不需要 DB2 调节。但是，您可能希望参阅DB2 信息中心中的针对 Linux、UNIX 和 Windows 的数据库参数设置，了解调节建议，尤其在要复制的事务量特别大的时候。

CPU 需求

Q Capture 和 Q Apply 复制程序，以及 WebSphere MQ 都会为复制的 DB2 工作负载增加少量的开销。

作为一条经验规则，在目标上，对于将来自源数据库的 DB2 更改应用到目标数据库所需的 CPU 负载，Q Apply 和 WebSphere MQ 总共会为其增加 20% 到 25% 的开销。也就是说，在目标上应用更改所需的 CPU 资源中，大约 75% 花在DB2 中，这相当于源系统上执行这些相同的语句所需的 CPU 资源，所需 CPU 资源的大约 25% 花在 Q Apply 和 WebSphere MQ 中。来自 Q Apply 和 WebSphere MQ 的 CPU 开销仅用在运行这些程序的成员上；在其他成员上的复制所产生的 CPU 开销通常可忽略。对于来自包含大量成员的系统的大量复制的更改，专门分配一个成员在目标上运行 Q Apply 程序可能很有用。

在源系统上，在 4 个成员中的每一个成员都消耗其 50% 的 CPU 容量的大容量性能实验中，Q Capture 程序会给运行它的成员增添大约 10% 的 CPU 开销，用这笔开销从所有其他成员捕获更改。在其他成员上捕获日志记录的开销可忽略不计。

一般而言，不同环境和工作负载的 CPU 需求有很大差别，建议您使用自己的应用进行测试。

磁盘空间需求

在目标上的 WebSphere MQ 接收队列中暂存更改需要一定的磁盘空间。在最低限度上，此空间大小只需足够处理可被复制的最大 DB2 事务即可，但该大小应该足够存储预计会在故障期间积累的更改量。例如，如果每秒复制 1000 行，其中每行平均 200 字节，并且希望在目标数据库关闭时将累积的更改保留 24 小时，那么您可以向目标系统上的接收队列分配 1000 行 * 200 字节/行 * 3600 秒/小时 * 24 = 17.3GB 的空间。WebSphere MQ 消息头有一个最低开销，一般为每个复制的DB2 事务几百个字节，您可使用该开销对估算结果进行舍入。但是，如果接收队列填满了，也不是问题。当复制空间不足时（无论是对于源队列还是目标队列），Q Capture 程序要么停止，要么会依据 qfull_retry_delay 和 qfull_num_retries 参数进入重试模式。 用于传输队列的磁盘空间大小，只需足够存储可被复制的最大数据库事务即可。

空间耗尽不是什么大问题。Q Replication 将读取 DB2 日志的进度以及它已处理的 WebSphere MQ 消息的信息存储在持久存储中，所以复制流程的任何组件都可以随时中断（甚至突然中断），不会丢失数据。

在本文中，我们对所有 DB2 和 WebSphere MQ 数据使用了相同的文件系统，但是，为了实现最优的性能，建议对 DB2 日志、DB2 数据、WebSphere MQ 日志和 WebSphere MQ 数据使用独立的磁盘和文件系统。源系统上的 WebSphere MQ 日志需要的空间与可能在 XMITQ 中累积的消息量成正比；在目标上，它与 Q Apply 可同时应用的消息数量成正比。在这两种情况下，它所需的空间都比 WebSphere MQ 数据小得多。一般而言，200 MB 就足以存储 WebSphere MQ 日志了，除非您复制比此容量更大的单一 DB2 事务。

准备用于复制的数据库

要准备好一个使用复制的数据库，需要执行以下操作：

1. 在另一个站点上对每个 DB2 数据库进行编目，使 Q Apply 程序可在需要时远程连接它，比如在初始表加载期间。我们通过别名对数据库进行编目，比如站点 1 上的 QSAMPLE1 和站点 2 上的 QSAMPLE2。

2. 在数据库上设置 LOGARCHMETH1=LOGRETAIN。不能使用循环的日志，因为可以重用一个仍需要用于复制的日志文件。

3. 调整您希望复制的表，以便启用 DATA CAPTURE CHANGES。

Q Replication 安装和配置

安装和配置 Q Replication 涉及到以下步骤：

1. 并安装 WebSphere MQ。
2. 创建 WebSphere MQ 对象。
3. 如果需要，请获取一个 Q Replication 许可。
4. 初始化 shell 环境。
5. 创建用于 Q Replication 的控制表。

1. 下载并安装 WebSphere MQ

参见附录 2，了解下载和安装 WebSphere MQ 的命令和说明。

2. 创建 WebSphere MQ 对象

我们需要创建队列管理器、WebSphere MQ 队列、通道和监听器、对于此任务，您需要知道运行 WebSphere MQ 的每个数据成员的 IP 主机名和 WebSphere MQ 使用的端口（默认为 1414 端口）。您还需要用于 WebSphere MQ 的共享文件系统的名称，在我们的例子中，该名称为站点 1 上的 /db2fs/data 和站点 2 上的 /db2fs/data2。

我们将使用与数据库别名相同的名称创建队列管理器，即与站点 1 的 QSAMPLE1 和站点 2 的 QSAMPLE2 相同的名称。 我们提供了一个 pureScale 实例的步骤，在另一个站点上重复这些步骤即可。