本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 迁移选项详细信息
以下各节详细介绍了与上一节中的图表对应的选项。
## 1. 离线备份和恢复
本机 Db2 备份可备份整个数据库。其可用于将数据库重新创建（恢复）到任何主机。
+ 离线备份和恢复是将数据库从本地迁移到 AWS最基本的方法。
+ Db2 本地数据库必须位于小端平台上。
+ 进行离线备份、将备份映像传输到 Amazon S3 以及从备份中恢复数据库均需要停机时间。
## 2. HADR 失效转移
Db2 HADR（高可用性灾难恢复）通过将数据更改从源数据库（称为主数据库）复制到目标数据库（称为备用数据库）来提供高可用性解决方案。HADR 最多支持三台远程备用服务器。
+ HADR 失效转移最适合在小端平台上运行的非 DPF 实例。
+ 必须记录源数据库上的所有事务。
+ HADR 支持通过日志流将数据更改从源数据库（主数据库）复制到目标数据库（备用数据库）。HADR TCP/IP 用于主数据库和备用数据库之间的通信。
+ 经过完整业务验证后，可以在不中断的情况下关闭 HADR，并且可以停用本地 Db2 数据库。
## 3. 通过事务日志传送进行在线备份和恢复
与离线备份和恢复（选项 1）不同，在线备份不需要源数据库停机时间。源数据库的备份完成后，该功能会使用数据库事务日志将更改应用到目标数据库。
+ 通过事务日志传送进行在线备份和恢复最适合小端平台上的 Db2 DPF 实例。由于 Db2 DPF 数据库的大小往往较大，因此常规备份和恢复（选项 1）的中断时间可能会超过 12 小时。Db2 DPF 数据库不支持 HADR。
+ 必须记录源数据库上的所有事务。
+ 您可以使用通过事务日志传送进行在线备份和恢复，以最大限度地缩短中断时间。
+ 通过日志传送进行在线备份和恢复也可用于非 DPF 实例。但是，对于非 DPF 实例，带有失效转移选项的 HADR 更容易实施。
+ 与 HADR 失效转移（选项 2）不同，反向同步并非自动进行，需要手动设置。
+ 经过完整业务验证后，您可以停用本地 Db2 数据库。
## 4. Q Replication
Q Replication 是一种高容量、低延迟的复制解决方案，它使用 IBM MQ 消息队列在源数据库与目标数据库之间传输事务。
最常见的配置如下图所示。
IBM MQ 在与 Db2 相同的服务器上运行。有两个 IBM MQ 实例，一个在本地服务器上，另一个在 Amazon EC2 上。Capture 程序在源数据库上运行。该程序读取事务日志并将已提交的更改（插入、更新或删除）发送到本地的 IBM MQ。本地的 IBM MQ 将消息通过 AWS Site-to-Site VPN 发送到 Amazon EC2 上的 IBM MQ。Apply 程序在包含目标数据库的 EC2 实例上运行。首先，该程序对表执行完全加载。然后，其从 Amazon EC2 上的 IBM MQ 读取更改数据消息并将其应用到目标表。
+ 本地 Db2 是源数据库，而 Amazon EC2 上的 Db2 是目标数据库。两个数据库均处于在线状态。
+ 本地 Db2 数据库可以位于任何平台系列上。
+ 必须记录源数据库上的所有事务。
+ IBM MQ 提供高性能、高可用性和有保障的消息传递。
+ 在目标数据库上提交更改后，消息将从 IBM MQ 中删除。
+ Two-way 复制是一种后备选项。但需要额外的设置。
+ 需要进行架构迁移。有关详细信息，请参阅[架构迁移](#schema-migration)部分。
+ Q Replication 需要 [extra license starting with version 11.5](https://www.ibm.com/support/pages/ibm-db2-11-changes-data-replication)。
+ 成功割接后，停止复制并停用 IBM MQ 实例。您也可以根据需要停用本地数据库。
## 5. SQL Replication
SQL Replication 由以下主要组件组成：Capture、Apply、GUI 和 CLI 界面以及 Alert 监视器。
Capture 程序在源数据库上运行。该程序读取事务日志并将提交的更改（插入、更新或删除）保存到已更改的数据（CD）表中。每个源表都有一个 CD 表。
工作单元的 Db2 提交点存储在工作单元（UOW）表中。在用户指定的时间点，Capture 程序会删除 CD 和 UOW 表中不再需要的数据。这称为修剪。
Apply 程序在目标数据库上运行。该程序连接到源数据库，获取 CD 表中存储的数据，将获取的行存储到一个或多个溢出文件中，然后将其应用到目标数据库中。
+ 本地 Db2 数据库可以位于任何平台系列上。
+ 必须记录源数据库上的所有事务。
+ 由于每次写入都必须运行多次（在基础表、CD 表和 UOW 表上执行），因此源数据库开销相对较高。通常，我们建议对写入流量较低的系统使用 SQL Replication。
+ Two-way 复制是一种后备选项。但需要额外的设置。
+ 需要进行架构迁移。有关详细信息，请参阅[架构迁移部分](#schema-migration)。
+ 与 Q Replication 不同，所有 Db2 版本都包含 SQL Replication。其不需要额外的许可证。
+ 成功割接后，停止复制，并根据需要停用本地数据库。
## 6. AWS DMS
[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) 是一项托管迁移和复制服务，可帮助您将数据库和分析工作负载 AWS 安全地迁移，同时最大限度地减少停机时间和零数据丢失。
+ AWS DMS 复制实例会执行您的数据库迁移。
+ AWS DMS 源端点和目标端点使 AWS DMS 实例能够连接源数据库和目标数据库以进行迁移。
+ AWS DMS 任务连接到源端点并将数据复制到目标终端节点。
+ 您可以开启数据验证，以确认准确地将数据从源迁移到目标。
+ 您可以使用 Amazon 启用日志记录 CloudWatch。
## 7。 Third-party 复制工具
Third-party [Infosphere CDC、](https://www.ibm.com/docs/da/iis/11.7?topic=sources-infosphere-change-data-capture) [Qlik Replicate、[精确实时 CDC](https://www.precisely.com/solution/real-time-cdc-and-etl-solutions) 和 [Oracle](https://www.oracle.com/integration/goldengate/) 等复制](https://help.qlik.com/en-US/replicate/May2025/Content/Replicate/Main/Introduction/replicat_concepts.htm)工具 GoldenGate可以支持 Db2 for LUW 的数据迁移作为目标。
对于 Qlik Replicate，需要将 Db2 for LUW 设置为开放式数据库连接（ODBC）目标。
## 8。 InfoSphere Optim 高性能卸载和装载
InfoSphere Optim High Performance Unload 绕过 Db2 引擎，直接从物理文件中卸载数据。
+ Optim High Performance Unload 卸载 Db2 数据的速度通常比 Db2 `EXPORT` 命令快几倍。其可以通过直接从磁盘读取数据文件来绕过 Db2 数据库管理器，还可以避免在控制文件中指定多条 `SELECT` 语句或多种文件格式时多次扫描 Db2 表。
+ Optim High Performance Unload 还可以从备份映像中卸载 Db2 数据。这意味着您可以在另一台计算机上运行 Optim High Performance Unload，以减少对源数据库服务器的性能影响。这对于大型历史表或表分区非常有用。
+ 数据输出文件可以传输到 Amazon S3，供 Db2 EC2 服务器访问。
+ Db2 加载支持直接访问 Amazon S3。例如，您可以使用以下命令：
```
db2 load from DB2REMOTE:///// replace into mytable
```
+ 需要进行架构迁移。有关详细信息，请参阅[架构迁移](#schema-migration)部分。
+ InfoSphere Optim 高性能卸载需要额外的许可证。
## 9. LOAD FROM CURSOR
LOAD FROM CURSOR 是一个 Db2 加载实用程序选项，该选项使用目标上的表作为源，而无需将数据卸载到文件中。
+ 需要在目标数据库上创建联合身份验证链接并将其链接到源数据库。
+ 为每个表创建一个链接到本地源表的昵称。如果涉及大量的表，我们建议使用自动化脚本来生成昵称和加载语句。
+ LOAD FROM CURSOR 会绕过暂存存储，并可将表分成不同的流以并行运行。我们建议在大型加载期间监控网络拥塞情况。
+ 通过操作游标定义中的 `SELECT` 语句，可以选择完整表、跳过不想加载的数据，或者将基于范围的分区表拆分为多条加载语句（例如，按季度和按月份）。
+ 需要进行架构迁移。有关详细信息，请参阅[架构迁移](#schema-migration)部分。
## 10. db2move
`db2move` 命令在 `EXPORT`、`IMPORT` 或 `LOAD` 模式下使用时，便于在 Db2 数据库之间移动大量表。
+ 需要进行架构迁移。有关详细信息，请参阅[架构迁移](#schema-migration)部分。
+ 您可以使用 `db2move` 命令将表中的数据卸载到文件中，然后将该数据加载到 Db2 表中。这非常有用，因为 db2move 实用程序通过少量命令即可下载源数据库中的所有表，然后将其加载到目标数据库。
1. 要将源数据库中所有包含 LOB 的表导出到 ``，请运行以下命令：
```
db2move export -l //
```
1. 将文件传输到 Amazon S3，Db2 EC2 服务器可在此检索这些文件。
1. 要将所有表加载到目标数据库中，请运行以下命令：
```
db2move load -l //
```
## 架构迁移
对于备份和恢复、HADR 失效转移以及通过日志传送进行备份和恢复（选项 1-3），架构迁移已包含在数据迁移中，不需要额外的步骤。
对于逻辑复制和大端迁移（选项 4-10），您必须在目标上手动创建数据库和架构。我们建议在迁移期间避免对源进行架构更改。迁移可能需要几天时间，但实际停机时间要短得多。
在源服务器上：
1. 使用 db2look 实用程序提取数据定义语言（DDL），并将输出保存到 `db2look.ddl`。
1. 将 `db2look.ddl` 传输到 Amazon S3。
在目标服务器上：
1. 从 Amazon S3 获取 `db2look.ddl`。
1. 提取外键约束、检查约束和 `CREATE TRIGGER` 语句，将其保存到单独的文件中。此过程并不复杂，因为 db2look 输出将这些语句组合在一起。
1. 创建不包含外键、检查约束和触发器的数据库和架构。
1. 对于包含身份列的表，将 `GENERATED ALWAYS` 转换为 `GENERATED BY DEFAULT`。
1. 对于逻辑复制选项 4、5、6、7，请开始复制。在完全加载完成后，您可以重新创建外键和检查约束。但是，在割接之前必须重新创建触发器。
1. 对于选项 8、9 和 10，在数据加载完成后，重新创建外键、检查约束和触发器。
1. 将您在步骤 4 中更改的、包含身份列的表恢复为 `GENERATED ALWAYS`。
1. 在割接之前，重新设置身份列和序列种子。