在DB2中部署Q Replication:包含哪些工作?

以下各节将介绍部署 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 实例的步骤,在另一个站点上重复这些步骤即可。

时间: 2024-08-31 13:08:12

在DB2中部署Q Replication:包含哪些工作?的相关文章

IBM DB2 pureScale和Q Replication监视、调节复制并排除其故障

Q Capture 和 Q Apply 程序维护着大量数据库表,以记录有关复制过程的重要信息.这包括具有性能指标的监视表.包含程序信息的轨迹表,以及包含数据冲突信息的异常表.多年来,许多数据库管理员已开发了一些利用了此信息的可访问工具:您始终可以相信,优秀的 DB2 会找到 DB2 表中容易访问和有用的信息的许多用途! IBM 工具还利用了这些监视表,以及 Q Capture 和 Q Apply 程序更新的所有其他表.此外,IBM 还提供了一个庞大的工具集来帮助管理多站点复制配置. 命令行实用程

使用IBM DB2 pureScale Feature与Q Replication实现可伸缩性和业务连续性

要沉着应对如今愈加全球化和竞争激烈的市场,离不开这样一种http://www.aliyun.com/zixun/aggregation/14345.html">数据处理架构,该架构能够随未来的战略需求增长而灵活地增长,能在发生组件故障.维护活动和灾难事件时确保业务连续性. 对某些企业而言,哪怕一小时的停工都可能导致数百万美元的收入损失,更别说对公司声誉的损害和潜在的客户流失.全球化的企业跨不同时区而运作,无时无刻不在提供业务服务.为系统维护和升级保留的离线时窗已不复存在.分布式的企业需要能

使用Tivoli System Automation自动化Q Replication故障转移

我们利用 DB2 所提供的 http://www.aliyun.com/zixun/aggregation/13966.html">Tivoli System Automation (TSA) 功能来自动化在发生故障时对 Q Replication 的重新启动. 在使用 TSA 时,您是在一个已定义的资源组上使用命令管理复制操作,而不是显式调用 asnqcap 和 asnqapp 程序.例如,如果一个定义将 Q Capture.Q Apply 和队列管理器划分到为一个名为"ibm

IBM DB2中Q Replication概念和操作

我们现在会介绍并解释一些考虑因素.配置选择.概念和技术,以及使用 Q Replication 实现您的 DB2 实例的完全连续的可用性所需的部署和操作过程.本文将专门介绍 pureScale,但文中提供的所有概念和命令同样适用于其他任何 DB2 系统. 针对 pureScale 的特殊考虑因素 将 Q Replication 用于 DB2 pureScale 或其他任何 DB2 产品(包括 DB2 ESE.InfoSphere Warehouse(具有数据库分区功能的 DB2)和 DB2 for

C# 积木模块 ABC(二)在C#中部署应用程序

程序 在C#中部署应用程序 在Visual Studio.NET中部署工程非常简单.大部分程序都可以通过一些方便的向导自动完成,而不需要费什么力气.但是要记住,根据请看,可能还需要在机器上安装Windows组件的更新Beta 1版.当然还需要Microsoft .NET框架.还要注意一点:Microsoft说当前的部署到了将来可能会无效. 一旦在Visual Studio中完成了应用程序的编写,就可以按照下述步骤开始部署: 首先,从文件菜单中选择增加新的工程文件: 然后,选择设置和部署工程,这时

如何在 Integrated Solutions Console(ISC)中部署和删除 bundl

Integrated Solutions Console (ISC) 介绍 Integrated Solutions Console(ISC)是 IBM 开发的集成解决方案控制台.它的设计目标是给相关的 web 管理产品提供一套标准的框架和统一的界面风格.ISC 可以运行在不同的 web 容器中, 比如:WebSphere.Light Weight Infrastructure(LWI).本文将介绍运行在 LWI 环境下的 ISC.集成 ISC 软件包的 lwimax zip 包可以在 LWI

db2中的用户和schema关系是怎样的

问题描述 db2中的用户和schema关系是怎样的 db2中的用户和schema关系是怎样的 一个用户下面可以有很多schema? 解决方案 数据库中Schema有两种含义,一种是概念上的Schema,指的是一组DDL语句集,该语句集完整地描述了数据库的结构.还有一种是物理上的 Schema,指的是数据库中的一个名字空间,它包含一组表.视图和存储过程等命名对象.简单的说,Schema就是一个(数据库)用户所拥有的数据库的对象. 在一个数据库中可以有多个应用的数据表,这些不同应用的表可以放在不同的

在DB2中提高INSERT性能的技巧(1)_DB2

正在看的db2教程是:在DB2中提高INSERT性能的技巧(1).INSERT 处理过程概述 首先让我们快速地看看插入一行时的处理步骤.这些步骤中的每一步都有优化的潜力,对此我们在后面会一一讨论. 在客户机准备 语句.对于动态 SQL,在语句执行前就要做这一步,此处的性能是很重要的:对于静态 SQL,这一步的性能实际上关系不大,因为语句的准备是事先完成的. 在客户机,将要插入的行的各个 列值组装起来,发送到 DB2 服务器. DB2 服务器确定将这一行插入到哪一页中. DB2 在 用于该页的缓冲

DB2中两种语言:SQL/XML和XQuery的使用

您可以单独使用 XQuery 和 SQL,但也可将 XQuery 嵌入 SQL 中使用(反之亦可).每一种可选方案在特定环境下都非常有用.本文将讨论这些可选方案,介绍其各自的优缺点,并给出根据您的需求选择恰当方案的指导原则. DB2 中的 pureXML 支持为管理 XML 数据提供了高效且通用的功能.DB2 以 XML 数据自身固有的分层格式存储和处理这些数据,避免因为将 XML 存储为 CLOB 中的文本或将它映射为关系表而导致的性能和灵活性限制.与仅使用 XML 的数据库不同,DB2 V9