[译文] 使用 Data Guard 或 Dbvisit Standby 管理 ODA 修补

原创 Jérôme Dubar 2021-09-23

593

介绍

如今，在不考虑灾难恢复解决方案 (DR) 的情况下构建 Oracle 基础架构的情况非常罕见。很明显，如果您在生产服务器停机后不知道从哪里恢复或导入，备份或转储将无济于事。恢复备份绝对不是让您的数据库恢复活力的最快方法。因此，必须拥有 Data Guard 或 Dbvisit Standby，具体取决于您运行的版本。这些工具不仅仅是灾难恢复解决方案。您也可以将它们用于计划内维护，或者如果您需要将服务器移动到另一个数据中心。

Oracle 数据库机并没有偏离这一点，最低配置由 2 个 ODA 组成，1 个用于生产，1 个用于 DR 和测试/开发。使用 Data Guard 或 Dbvisit Standby 实现的 DR 功能。

在修补方面，使用 Data Guard 或 Dbvisit Standby 也有帮助。因为不时修补您的 ODA 是一个很好的做法。您可能会问在使用 Data Guard 或 Dbvisit Standby 时如何继续，这是我多年来的做法。

ODA 的 3 步补丁

您可以逐步应用 ODA 补丁：

一些用于更新 dcs 组件的预补丁
用于更新 BIOS、ILOM、操作系统和网格基础设施的系统补丁
用于更新数据盘固件的存储补丁
一个用于更新数据库家的数据库补丁，如果你有多个数据库家，这个补丁会被多次应用

补丁可能需要相当长的时间，您需要为单节点 ODA 计划至少 3/4 小时。如果您在打补丁之前添加 ODA 准备、故障排除和在应用补丁后进行健全性检查，您很可能需要 1 天的时间来打补丁。停机时间可能会有所不同，但由于至少需要重新启动一两次，我通常会考虑一整天的停机时间。是的，这是巨大的，但这是现实生活。

此外，如果您打补丁的频率不够高，一个补丁可能无法完成这项工作。补丁并不总是累积的，您有时需要应用 3 或 4 个补丁才能升级到最新版本，这会显着增加打补丁的时间和相关的停机时间。

好像还不是很复杂，打补丁的时候可能会遇到问题，卡住一会才找到解决办法或变通办法。但不要为此责怪 Oracle：谁能将如此多种更新（操作系统、BIOS、固件、ILOM、GI、DB）捆绑在一个补丁中？Oracle 数据库一直是一个功能强大的 RDBMS，但具有高度的复杂性。添加 GI 层、Linux 操作系统和硬件更新无疑使修补成为一项艰巨的任务。

使用 DR 解决方案时的修补策略

修补可能是您的噩梦……或不是。这完全取决于您如何管理这些补丁。

首先，我建议只修补没有主要运行的 ODA。这只有在您使用 Data Guard 或 Dbvisit Standby 时才有可能：在打补丁之前计划将主要数据库切换到其他 ODA。如果在修补过程中出现问题，或者花费的时间比计划的多，则不会对您的业务产生任何影响。您可能会在几个小时内错过备用数据库，但这通常是您可以管理的。高度关键的数据库可能会使用多个备用数据库，以便在修补期间保持最大的安全性。

我还建议为每个 ODA 上的每个 DB home 保留一个主要测试（我习惯于在部署时在每个 ODA 上创建一个 DBTEST，并保留它以进行测试）。将修补该主数据库以验证完整的修补过程。

当您在第一个 ODA 上应用补丁时，您最终可以在修补 DB 主目录之前停止修补过程，以使它们与其他 ODA 保持相同的版本。或者您可以决定应用这个数据库主补丁：它会更新二进制文件，但它不能在数据库本身上应用数据补丁。只要您不将初选切换回此修补的 ODA，这都无关紧要。如果您决定应用 DB home 补丁，然后切换到这个更新的 ODA，您的二进制文件将不再与目录同步，并且可能会导致几个问题（尤其是关于 DB 中的 Java 代码）。因此，如果在此 ODA 上仅保留备用数据库，则应用完整补丁是可以的，直到您修补其他 ODA。

不建议等待超过几周的时间来修补其他 ODA。因此，一旦您成功修补了第一个并等待了几天以确保此修补程序一切正常，请将所有主要版本切换到已修补的 ODA。完成后，您现在需要首先使用 update-dbhome 在这些主数据库上应用 DB home 补丁。您还可以使用手动数据补丁。这是更新目录以匹配二进制文件版本所必需的。然后将完整的补丁应用到您的其他 ODA。完成后，两个 ODA 都是最新的，您可以在两台服务器上再次发送您的数据库。

我强烈建议在每个数据库上验证补丁是否已正确应用。有时需要手动数据补丁，所以如果 odacli update-dbhome 出现问题，请不要犹豫：

set serverout on
exec dbms_qopatch.get_sqlpatch_status;
...
Patch Id : 29972716
Action : APPLY
Action Time : 14-OCT-2020 10:59:29
Description : DATABASE BUNDLE PATCH 12.1.0.2.191015
Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/29972716/23132651/29972716_apply_DEV121_202
0Oct14_10_58_32.log
Status : SUCCESS
复制

什么时候重新成像？

有时，重新映像比应用补丁更好。重新映像可能比应用多个补丁更快，并且在您清理所有内容并从头开始重新启动时，故障排除要少得多。仅当您可以将所有原色切换到另一个 ODA 数天时，才可以考虑重新映像。然后，您需要从 Data Guard 中删除备用配置（仅删除备用就可以了），因为您的备用数据库将在几个小时/几天内不可用（实际上您将重建它）。

当您进行重新映像时，您无法决定将在 DB home 之上应用哪个补丁，它是全球版本附带的补丁。因此，您将无法在修补后立即切换回原色。例如，使用重新映像从 18.5 修补到 19.11（这是有道理的，因为差距很重要）将带来 18.14 DB 主目录，这可能会导致 18.5 数据库目录出现问题。

在重新映像之前，我建议将备用的控制文件自动备份备份到外部文件系统，它还包括最新的 spfile。这样你就不需要从主 pfile 再次创建 spfile，你不会忘记恢复一个 STANDBY 控制文件，因为你的控制文件备份已经是一个备用控制文件。

如果您不想使用 RMAN DUPLICATE，则可以使用主备份恢复备用数据库。

为什么我可以安全地使用不同的二进制文件运行已安装的备用数据库，但不能将其用作主数据库？

通常，您应该只运行相同版本的二进制文件和数据库目录。但是运行具有不同二进制文件版本的备用数据库实际上是可以的。这是因为目录未在备用数据库上打开：目录驻留在 SYSTEM 的表空间中，并且已安装的数据库不打开任何数据文件。您可能还注意到，只有在您可以使用较新的二进制文件打开旧数据库的情况下，才能在主数据库上应用数据补丁，除非您永远无法更新此目录……

使用不同的二进制文件在 READ ONLY 模式下打开 Standby 没有风险，或者如果您使用的是 Active Guard 选项，但某些高级功能可能无法正常工作。