【译】零停机迁移——超大型数据库的物理在线迁移

原创 Ellison 2022-06-15

661

原文地址：https://dohdatabase.com/2021/06/11/zdm-physical-online-migration-of-vldb/

零停机迁移——超大型数据库的物理在线迁移

现有数据卫士

VLDB 通常由带有一个或多个备用数据库的 Data Guard 保护。当您使用零停机时间迁移 (ZDM)开始迁移时，您不想承诺现有的Data Guard设置。如果在准备迁移到 OCI 的过程中发生了一些事情，您仍然希望能够切换到本地备用数据库。像这样的东西：

当 ZDM 配置 OCI 备用数据库时，它将被添加为手动管理的数据库，即它不使用 Data Guard 代理。它不会干扰您的 Data Guard 代理设置，并且设置仍然有效。需要注意的几点：

ZDM 工作时，不允许切换。这将导致进程出错。
我的意思是工作——从你开始 ZDM 迁移的那一刻起，直到它在ZDM_CONFIGURE_DG_SRC处暂停。
当 ZDM 暂停时，您可以进行任意次数的切换。只要确保原始源数据库尽快再次成为主数据库即可。
当您需要完成迁移时，源数据库必须是主数据库并且不允许切换。这确实是有道理的，因为在最后一个阶段，ZDM 正在切换到 OCI 目标数据库。
故障转移呢。故障转移意味着数据丢失并接受您需要使用RESETLOGS打开数据库。这会对您的 Data Guard 设置造成各种破坏。你又重新开始了。

重要的

但是在使用 ZDM 完成迁移之前，您必须删除本地 Data Guard 设置，即恢复暂停的作业。如果存在冲突的 Data Guard 配置，ZDM 将无法正确完成。要删除现有的 Data Guard 设置：

ZDM 迁移当前在ZDM_CONFIGURE_DG_SRC处暂停。
使用Data Guard CLI ( dgmgrl) 连接到源本地数据库（主要）。删除配置：

remove configuration

使用 SQL*Plus ( sqlplus) 连接到源本地数据库（主）。删除 Data Guard 代理配置：

alter system set dg_broker_start=FALSE scope=memory;
alter system reset dg_broker_start;
alter system reset dg_broker_config_file1;
alter system reset dg_broker_config_file2;

检查log_archive_config。它必须包含源本地数据库（主）和 OCI 目标数据库的DB_UNIQUE_NAME - 仅此而已。使用上面的例子，它应该是：

alter system set log_archive_config='dg_config=(SALES_1,SALES_oci)' scope=both;

检查log_archive_dest_n参数。确保 Data Guard 代理删除了正确的代理。应该只有一个远程重做日志目的地——那就是 OCI 目标数据库——所有其他的都应该被删除。如果你需要删除一个，使用这个命令（记得调整后缀）：

alter system set log_archive_dest_2='' scope=memory;
alter system reset log_archive_dest_2;

确保log_archive_config在 OCI 目标数据库中正确设置（如 #4）：

alter system set log_archive_config='dg_config=(SALES_1,SALES_oci)' scope=both;

最后，完成迁移：

$ZDM_HOME/bin/zdmcli resume job -jobid <id>

备份

ZDM 需要可以在目标上恢复的完整备份。

DBCS：如果您的目标数据库是 OCI 云服务之一（虚拟机、裸机或 Exadata 数据库系统），ZDM 将需要进行新的完整备份。无法使用现有备份。
ExaCC 或 Exadata on-prem：您可以进行新的完整备份，也可以使用磁盘上提供的现有备份。此外，如果您有幸拥有零数据丢失恢复设备 (ZDLRA)，则无需进行备份。ZDM 可以直接从 ZDLRA 恢复。

如果您以 DBCS 为目标，DATA_TRANSFER_MEDIUM则设置为OSS（对象存储服务）。使用Oracle Database Cloud Backup Module for OCI将备份存储在对象存储中。源数据库中的备份和目标数据库中的还原将通过一个特殊的sbt通道进行，该通道将备份直接流式传输到对象存储和从对象存储流出。这表示：

备份永远不会命中磁盘，因此您不需要额外的磁盘空间来保存备份。
备份的持续时间取决于您对 OCI 的网络速度。由于备份直接流式传输到 OCI，因此网络可能成为瓶颈。如果您与 OCI 的连接速度较慢，则备份运行速度也会同样慢。这同样适用于还原，但是，目标数据库已经在 OCI 中并且与对象存储有良好的连接。

默认情况下，ZDM 将使用 10 个 RMAN 通道进行恢复和备份。凭借您对源数据库的了解，您可能会更清楚。您可以调整响应文件中的通道数。寻找参数SRC_RMAN_CHANNELS和TGT_RMAN_CHANNELS。

根据您的知识或测试，您可以确定哪种RMAN 压缩算法可以为您的数据库带来最大收益。您可以使用参数调整响应文件中的压缩算法ZDM_RMAN_COMPRESSION_ALGORITHM。默认值为MEDIUM，它通常会在压缩率和 CPU 时间之间取得最佳平衡。请记住，RMAN 压缩通常需要 Advanced Compression Option 的许可证，但是当您使用 ZDM 迁移时，您可以免费使用它。

当 ZDM 对源数据库进行备份时，不应运行其他备份。请务必暂停您的常规备份，包括存档备份。

重做应用

在源数据库中，您应该将归档日志保存在磁盘上，直到目标数据库已恢复、Data Guard 已配置并且目标数据库已赶上重做应用。如果您的网络连接速度较慢且数据库很大，则可能需要几天时间才能完成备份、恢复完成并且重做应用已经赶上。

假设您从序列 100 开始备份。
两天后目标数据库的还原完成。源数据库现在位于序列 200。
ZDM 配置 Data Guard 并启动重做传输和重做应用。源数据库现在位于序列 220。
序列 100-220 必须在源数据库主机的磁盘上可用，以便源（主）数据库可以将它们传输到目标（备用）数据库。

VLDB 每天生成两位数TB 的重做并不少见。就在前几天，我与一位客户交谈，他的数据库每天生成 15 TB 的归档日志。

首先，您必须能够将重做从源数据库（主）传输到目标数据库（备用）。这是一个简单的数学运算：如果您每天有 15 TB 重做，您应该能够使用 1.5 Gbps 连接（重做量 / 24 / 60 / 60 * 8）进行传输。如果传输重做成为问题，您可以考虑使用重做传输压缩。这可以减少必须以 CPU 周期为代价传输的数据量。您可以在 MOS 说明Data Guard Environment 中的重做传输压缩 (Doc ID 729551.1)中阅读有关它的更多信息. 我从最大可用性架构 (MAA) 团队的同事那里了解到，TDE 表空间加密和重做传输压缩不能很好地结合使用。如果您的源数据库是加密的，那么您不应该期望从重做传输压缩中获得那么多好处。

接下来，必须在目标数据库上应用重做。目标数据库是否能够如此快速地应用重做？在 Exadata 上，答案很可能是：是的 - 但与 IT 领域一样，这取决于下图的数字来自Redo Apply Best Practices – Oracle Data Guard 和 Active Data Guard。根据您的数据库版本和数据库中的工作负载类型；您可以看到每天可以应用的重做量（以 TB 为单位）。最后两列正在使用具有两个或四个活动 RAC 节点的多实例重做应用 (MIRA) 。这些数字是在 Exadata 上生成的。

目标数据库备份

如何在 OCI 中备份目标数据库？您希望从切换到目标数据库的那一刻起就有一个有效的备份。

您最初创建的目标占位符数据库将被 ZDM 覆盖。这意味着您无法提前在 OCI 中配置和启用自动备份。您必须等到迁移完成后才能启用自动备份。

你可以：

延长停机时间以允许在迁移后配置自动备份。此外，请留出足够的时间来完成第一次备份。
或者，在 OCI 中进行自己的备份。这比较麻烦，但可以让您在切换后立即打开数据库进行业务。但是您现在负责备份。所有各种点点滴滴都可用：
- 原始备份仍在对象存储中。
- 存档日志在磁盘上——您可以手动备份它们。
- 如果需要，执行增量 - 将它们放在安全的地方。
- 在紧急情况下——把它们粘在一起

目标数据库上的 Data Guard

与自动备份类似，在 ZDM 完成迁移之前，您无法创建Data Guard 关联。云工具不支持通过级联备用创建备用数据库。这意味着在 ZDM 完成迁移之前，您无法构建 OCI 备用数据库，而 OCI 数据库是主数据库。您可以在 ZDM 完成后立即开始创建 OCI Data Guard，但是

您必须容忍缺少 OCI Data Guard
或者，采取停机时间

结论

甚至可以使用零停机迁移将大型 Oracle 数据库迁移到 OCI。您可能需要对标准流程进行一些调整，但这绝对是可行的。迁移后才能在 OCI 中创建自动备份和数据保护。这可能会迫使您停机。除了实际迁移之外，您还应该尽力确保数据库开放业务后的性能稳定性。为此，您应该查看我们的网络研讨会性能稳定性、提示和技巧以及下划线。

本系列的其他博客文章

墨力计划墨力翻译

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者