在线克隆PDB并与Oracle GoldenGate同步？

原创 Mike.Dietrich 2020-04-16

1908

我们收到问题：我可以在线克隆PDB并与Oracle GoldenGate同步吗？我的回答是“当然！”

朱迪思·普林斯（Judith Prins）在Unsplash上拍摄的照片

在线克隆与PDB迁移

关于PDB的在线克隆和重定位，我收到了很好的想法和反馈。我简要地总结一下，因为第一种技术可以使您的PDB仍然存活，所以大多数人都更喜欢在线克隆而不是PDB的Relocate进行升级（测试）。在“重定位”示例中，一旦 STARTUP UPGRADE 在重定位的PDB上发出a，源就会终止。

我完全同意您的观点。因此，感谢Jeannette和Peter以及其他解释了他们的观点和经验的人。

真正的最小停机时间

这两种，在线克隆和移居的PDBS会导致升级的停机时间。在这两种情况下，在具有不同版本CDB的升级方案中，操作完成后都需要升级PDB。在所有这些情况下，请注意Multitenant中的无提示COMPATIBLE更改。

但是，如果您需要在这种情况下真正减少停机时间怎么办？您可以使用物理备用数据库来使用瞬态逻辑备用设置。或者，如果您已经或计划获得OGG许可证，则可以简单地使用Oracle GoldenGate 。

在这种情况下，应该非常简单地在源PDB和目标PDB之间进行同步，不是吗？但是您需要知道克隆过程基于哪个确切的SCN并完成。

克隆SCN

我重用了在线克隆博客文章中的简单示例。然后，我检查 alert.log 两个CDB。

在源代码CDB1上，我在alert.log中仅获得一个额外的标记：

2020-04-13T22：24：53.472382 + 02：00
PDB3（3）：AUDSYS.AUD $ UNIFIED（SQL_TEXT）-已填充CLOB
复制

当然，在接收方CDB2上，还有更多要说的：

2020-04-13T22：24：51.043427 + 02：00
从PDB3 @ clonemypdb创建可插入数据库PDB3 file_name_convert =（'CDB1'，'CDB2'）
2020-04-13T22：24：55.819212 + 02：00
PDB3（3）：字典的字节序类型设置为little
****************************************************** **************
具有pdb id-3的可插拔数据库PDB3被创建为UNUSABLE。
如果在将pdb标记为NEW之前遇到任何错误，
那么必须删除pdb
本地undo-1，localundoscn-0x0000000000000107
****************************************************** **************
2020-04-13T22：24：57.326460 + 02：00
将pdb-4099的介质恢复从SCN 1293822应用于SCN 1293852
远程日志信息：count-1
thr-1，seq-14，日志文件-/ u02 / fast_recovery_area / CDB1 / CDB1 / foreign_archivelog / PDB3 / 2020_04_13 / o1_mf_1_14_3210936238_.arc，los-1201204，nxs-18446744073709551615，maxblks-0
PDB3（3）：介质恢复开始
2020-04-13T22：24：57.333484 + 02：00
PDB3（3）：串行媒体恢复已开始
PDB3（3）：max_pdb为3
2020-04-13T22：24：57.409144 + 02：00
PDB3（3）：介质恢复日志/u02/fast_recovery_area/CDB1/CDB1/foreign_archivelog/PDB3/2020_04_13/o1_mf_1_14_3210936238_.arc
2020-04-13T22：24：57.531943 + 02：00
PDB3（3）：应用不完全恢复，直到更改1293852时间04/13/2020 22:24:56
2020-04-13T22：24：57.540787 + 02：00
PDB3（3）：介质恢复完成（CDB2）
PDB3（3）：撤消保留自动调整功能已打开。
PDB3（3）：撤消初始化恢复：err：0开始：336909结束：336928差异：19毫秒（0.0秒）
PDB3（3）：[4698]成功联机了撤消表空间2。
PDB3（3）：撤消初始化在线撤消段：err：0开始：336928结束：336937 diff：9毫秒（0.0秒）
PDB3（3）：取消初始化完成序列号：0开始：336909结束：336938差异：29毫秒（0.0秒）
PDB3（3）：PDB3的数据库字符集为AL32UTF8
PDB3（3）：JIT：pid 4698请求停止
PDB3（3）：缓冲区高速缓存刷新开始：3
PDB3（3）：缓冲区高速缓存刷新完成：3
已完成：从PDB3 @ clonemypdb创建可插入数据库PDB3 file_name_convert =（'CDB1'，'CDB2'）
复制

我在RED中标记了上面的SCN 。从源端来看是SCN。一旦STARTUP UPGRADE克隆的PDB，此SCN确实会被目标CDB2的SCN覆盖。

克隆完成后，这就是我在CDB2中得到的内容：

从V $ DATABASE中选择current_scn;  

CURRENT_SCN
-----------
    4588431

SQL> alter session set container = PDB3;
会话已更改。

SQL> alter pluggable database pdb3打开升级；
可插拔数据库已更改。

SQL>从V $ DATABASE中选择current_scn;  

CURRENT_SCN
-----------
    4588967
复制

我亲爱的同事约翰·麦克休（John McHugh）向我们解释了这一点。简而言之，尽管在克隆过程中设置了隐式的BEGIN和END SCN，以使克隆的图像与END SCN一致（请参见alert.log上面的摘录：1293852是END SCN），但它并不反映“目标” SCN。但是我们不需要目标SCN。END SCN是重要的。这是来自源的SCN，出现在alert.log目标CDB2的中。这是我们将传递给Oracle GoldenGate的内容。

升级克隆的PDB

下一步，我将升级克隆的PDB。我已经在此处进行了详细说明并进行了说明：

升级测试–在线将PDB克隆到19c

与Oracle GoldenGate同步

而且，我的PDB也已升级到Oracle 19.7.0之后，就可以使用Oracle GoldenGate 启动复制了。我假设在Oracle 12.2.0.1的源方面，我的生产工作负荷仍在继续。重要的是提取必须尽早开始以捕获所有必要的事务。

非常感谢我们OGG产品管理总监Nick Wagner。因为我不是OGG专家，所以我确实问过Nick。他向我解释说这里的主要命令是START REPLICAT [name] AFTERCSN 1293852。在这种情况下，alert.log告诉我们END SCN为1293852–，然后OGG需要在此SCN之后立即开始应用事务。

现在，您等待直到您的PDB与生产同步。而且，一旦您获得额外的停机时间，就可以切换应用程序。我想，如果我正确地准备了一切，那么我可以在允许应用程序在19.7.0 PDB上启动之前反转Oracle GoldenGate设置，然后将所做的更改立即发送回旧源。这样，我将确保无缝回退。

原文链接：https://mikedietrichde.com/2020/04/15/online-clone-a-pdb-and-synch-with-oracle-goldengate/

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

关注作者