我们现在会介绍并解释一些考虑因素、配置选择、概念和技术，以及使用 Q Replication 实现您的 DB2 实例的完全连续的可用性所需的部署和操作过程。本文将专门介绍 pureScale，但文中提供的所有概念和命令同样适用于其他任何 DB2 系统。
针对 pureScale 的特殊考虑因素
将 Q Replication 用于 DB2 pureScale 或其他任何 DB2 产品（包括 DB2 ESE、InfoSphere Warehouse（具有数据库分区功能的 DB2）和 DB2 for z/OS）并没有太大的区别。">产品功能、工具、管理、操作和用例在所有平台上几乎都是相同的。DB2 pureScale 的特殊性（至少在概念上与 DB2 z/OS 数据共享相同）涉及到：
? 理解在数据共享环境中运行复制的性能影响
? 为复制对象提供一个共享磁盘
? 为运行的复制选择一个数据成员
? 如果运行复制组件的成员失败或关闭，那么通过在另一个成员上重新启动复制组件，也可以定义资源来自动化重启过程。
本文将解决这些具体问题，以及其他一些考虑因素，这些因素是复制的一般性质，但对理解如何使用 DB2 pureScale 实现多站点连续可用性解决方案至关重要。
配置选择 – 首先确定您的目标是什么？
如果您对复制数据的主要需求是实时报告，那么您的目标可能是 DB2 ESE，甚至可能是非 DB2 系统。在这种情况下，您的目的应该是通过移除一些应用来消除源系统上的争用。例如，如果您有一个需要大量索引扫描的报告应用，并且您在源系统上运行报告，那么 OLTP 工作负载的性能将会受到影响。要解决此问题，可将报告应用转移到另一个服务器上。对于实时报告，复制通常被配置为单向，从源到目标系统。
如果您复制数据是为了保持连续可用性，并且希望在每个站点运行同一个应用，那么您一定希望复制在每个站点上运行此应用所需的所有数据。一个常见的配置是拥有一个大型的主要系统和较小的辅助系统，这个辅助系统仅保护对业务连续性至关重要的数据。对于连续可用性，通常将复制配置为双向复制数据，即使未在每个站点上同时更新相同的数据。
在使用 Q Replication 时，源系统和目标系统可以有很大的区别。它们无需运行相同的操作系统或 DB2 版本。这种灵活性使您能够更好地使用您可用的硬件、为迁移划分阶段，并且仅部署每个站点上所需的容量。