大多数企业客户对其任务关键型应用程序的正常运行时间有很高的要求。他们的企业承受不起应用程序宕机的代价，并且要求应用程序和数据库具有最小或接近零的宕机修补能力。后端Oracle数据库用于这些业务关键型应用程序的基础架构必须能够支持这些高正常运行时间需求。在将此类工作负载迁移到AWS时，客户还希望通过将其数据库移动到托管数据库服务产品（如针对Oracle的Amazon关系数据库服务（Amazon RDS）或针对Oracle的亚马逊RDS定制）来实现现代化并减少运营开销。
Amazon RDS Custom是一种托管数据库服务，用于需要访问底层操作系统和数据库环境的遗留、自定义和打包应用程序。Amazon RDS Custom for Oracle提供了定制数据库、底层服务器和操作系统配置的灵活性，以支持需要此类定制的应用程序。Amazon RDS custom for Oracle的自定义引擎版本（CEV）是数据库引擎和特定Amazon机器映像（AMI）的二进制卷快照。您将数据库安装文件存储在Amazon Simple Storage Service（Amazon S3）中。Amazon RDS Custom使用安装文件为您创建CEV。要对RDS Custom DB实例进行小版本升级，您必须使用季度发布更新（RU）补丁创建一个新的CEV，然后修改RDS Cutom实例以使用新CEV。这种方法需要完全停机才能将实例升级到下一个次要版本。
在本文中，我们展示了数据库管理员和数据架构师如何使用Oracle data Guard Standby First Patch Apply方法在RDS Custom for Oracle实例中应用季度RU，以减少修补停机时间。我们还讨论了在Amazon RDS Custom中使用此方法时的最佳实践和注意事项。
解决方案概述
Oracle Data Guard Standby First Patch Apply支持主数据库与其物理备用数据库之间的不同数据库主软件，以便在备用和主实例上一次应用和验证一个Oracle修补程序，同时将主数据库的风险降至最低。这有助于减少修补停机时间。
Oracle数据库季度RU包含数据库修补程序和Java修补程序（JVM）。如果Oracle数据库已启用JVM选项，则需要应用JVM修补程序。Oracle没有将JVM修补程序（过去六个季度RU的每个修补程序自述文件）归类为Data Guard Standby First Installable。在下面的部分中，我们将讨论在启用和不启用JVM的情况下将季度RU应用于数据库的场景。
在场景1中，当数据库中未启用JVM选项时，高级步骤包括：
-
1.暂停RDS自定义自动化。
-
2.使用Data Guard Standby First Patch Apply应用季度RU，其中停机时间等于切换所需的时间。
-
3.恢复RDS自定义自动化。
在场景2中，当数据库中启用JVM选项时，高级步骤包括：
-
1.暂停RDS自定义自动化。
-
2.请参阅Oracle修补程序自述文件，如果JVM修补程序不是可首先安装的备用修补程序，则需要完全停止主修补程序和辅助修补程序，并应用季度RU。
-
3.恢复RDS自定义自动化。
使用Data Guard Standby First Patch Apply时的注意事项
使用Data Guard Standby First Patch Apply时，请考虑以下事项：
-
请参阅Oracle Data Guard Best Practices，以在Amazon RDS Custom中配置、调优和故障排除Data Guard部署。
-
本文中描述的过程仅适用于Oracle归类为Data Guard Standby First Installable的修补程序，这在修补程序自述中有所提及。
-
有关何时选择Data Guard Standby First Patch Apply的注意事项，请参阅Oracle Doc 2217053.1。
-
本文的目的是演示在RDS Custom中使用Data Guard Standby First Patch Apply for applicable patches，而不是测试Data Guard待机优先功能的功能。
-
使用Data Guard Standby First Patch Apply时，您负责验证此功能的修补程序，并测试应用程序的行为，尤其是在数据修补期间。在测试这篇博客文章的过程中，按照补丁自述中的说明，数据补丁是在开放模式下应用数据库的。
-
本文描述的过程已经在RDS Custom for Oracle 19c数据库实例上进行了测试。
-
这是一个手动配线过程；您必须在现有Oracle_HOME上应用Oracle季度RU，以便RDS自定义自动化不会中断。
-
使用这种手动方法，我们的控制平面不知道数据库实例上的补丁级别。因此，如果您以后决定通过创建新的CEV来通过次要版本修补来进行修补，那么您必须处理任何一次性修补程序，并记住您使用的是什么Oracle RU版本。
-
作为最佳实践，我们建议在开始此修补过程之前手动拍摄快照。如果遇到任何问题并且需要回退到开始此活动之前的时间，可以将此快照用作回退策略。当自动化设置为ALL_PAUSED时，Amazon RDS Custom暂停已存档重做日志的上载。此处也适用于RDS Custom for Oracle的PITR注意事项中所述的相同PITR考虑事项。
-
由于修补程序是使用Oracle本机opatch进程应用的，因此如果必须还原修补程序，也可以使用opatch rollback命令。有关回滚过程的更多详细信息，请参阅Oracle修补程序自述文件。
-
当数据保护角色转换作为切换过程的一部分发生时，主端点将更改。因此，要实现无缝客户端连接，可以使用两种方法：
-
TNS别名–此方法适用于使用tnsnames的应用程序。您可以定义两个基于角色的数据库服务，以支持读/写和只读工作负载。例如，demo_rw是读/写服务，始终打开，并在主数据库上运行。demoro是只读服务，它在以只读方式打开的备用数据库上运行。有关如何使用数据库服务为Data Guard连接配置客户端故障切换的详细信息，请参阅Oracle Doc ID 1429223.1。创建一个数据库触发器，以便在数据库重新启动时启动这些服务。
-
DNS CNAME–在此方法中，您可以在Amazon Route 53中创建专用托管区域，并为主要RDS Custom端点创建CNAME。发生Data Guard切换时，可以使用新主节点的端点详细信息更新CNAME。这样，可以避免在端点连接更改时在应用程序级别进行更改。
-
先决条件
要继续阅读本文，请完成以下先决条件。在本例中，我们使用2021 4月和7月的RU创建了19c Oracle数据库，类似的方法也可以用于其他版本。
1.创建一个RDS Custom for Oracle DB实例，19c April 2021 RU，未安装JVM。对于这篇文章，让我们称之为demodb1_a。有关说明，请参阅使用RDS Custom For Oracle。
2.使用副本API为demodb1_a实例创建读取副本。复制副本将在装载模式下创建。让我们称之为demodb1_b。有关说明，请参阅使用RDS Custom For Oracle的读取副本。
3.使用19c 2021 4月RU和JVM补丁为Oracle DB实例创建另一个RDS自定义，称为Demob2\u a。
4.使用副本API为demodb2_a实例创建读取副本。复制副本将在装载模式下创建。让我们称之为demodb2_b。
5.Data Guard代理可以管理Data Guard配置。
注：此解决方案涉及创建和利用新的AWS资源。因此，它将在您的账户上产生费用。有关更多信息，请参阅AWS定价。
场景1：将19c 2021 7月RU应用于未安装JVM的DB实例
在这个测试场景中，我们将Demob1 RDS自定义数据库实例从2021 4月19日升级到2021 7月19日。demodb1实例没有任何JVM补丁，因此我们使用备用的第一个补丁应用方法来升级该实例。使用这种方法，您可以显著减少修补停机时间；实际停机时间等于切换过程所需的时间。
在开始为Oracle定制Amazon RDS Custom之前，必须暂停自动化，以确保您的定制不会干扰RDS定制自动化框架。您可以使用Amazon RDS控制台或AWS命令行界面（AWS CLI）暂停自动化。有关更多信息，请参阅暂停和恢复RDS自定义自动化。
1.使用以下AWS CLI命令暂停RDS Custom实例demodb1_a及其副本demodb2_b的自动化：
aws rds modify-db-instance --db-instance-identifier custom-ORCL --automation-mode all-paused --resume-full-automation-mode-minute 120 --region us-east-2复制
2.要连接数据库，您需要使用SSH密钥或AWS Systems Manager连接到底层的Amazon Elastic Compute Cloud（Amazon EC2）实例（请参阅使用AWS Systems Manager连接到RDS Custom DB实例）。
3.一旦您以ec2用户身份登录，就可以切换到rdsdb用户，该用户拥有数据库二进制文件。
4.然后，您应该能够使用sysdba权限连接到实例：
$sudo su - rdsdb $sqlplus / as sysdba复制
接下来，从AWS Secrets Manager检索Amazon rds Custom for Oracle的sys/system和rds_dataguard用户的数据库密码。
5.在Amazon RDS控制台的导航窗格中，选择数据库，然后选择主数据库。
6.选择Configuration并记录资源ID（其格式为db-R4ZMRQ7YJQGY7EL7I3AUVVRGVA）。
7.在Secrets Manager控制台上，选择与不删除自定义-<resource_id>-xxxx（sys用户）和不删除自定义-<resources_id>-xxxx dg（对于rds_dataguard）同名的机密
8.选择Retrieve secret value并记下数据库用户的密码。
9.停止备用实例上的侦听器：
-bash-4.2$ lsnrctl stop l_demodb1_001 LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 17-NOV-2021 07:03:57 Copyright (c) 1991, 2020, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=x.x.0.253))) The command completed successfully复制
10.停止备用实例上Data Guard的侦听器：
bash-4.2$ lsnrctl stop l_demodb1_dg LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 17-NOV-2021 07:03:51 Copyright (c) 1991, 2020, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1140)(HOST=x.x.0.253))) The command completed successfully复制
11.关闭备用实例：
-bash-4.2$ dgmgrl DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Nov 17 10:53:45 2021 Version 19.10.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb1_b; Connected to "DEMODB1_B" Connected as SYSDG. DGMGRL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. Connected to an idle instance. DGMGRL> exit复制
12.运行opatch prereq以确保没有冲突。请参阅修补程序自述文件，以确保修补程序是Standby First patch Installable。
bash-4.2$unzip p32545013_190000_Linux-x86-64.zip bash-4.2$ cd 32545013 bash-4.2$ pwd /tmp/32545013 bash-4.2$ export PATH=$ORACLE_HOME/OPatch:$PATH bash-4.2$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.23复制
13.通过在备用实例上运行以下命令来安装修补程序（此时不要运行数据修补程序）：
bash-4.2$ opatch apply Oracle Interim Patch Installer version 12.2.0.1.23 Copyright (c) 2021, Oracle Corporation. All rights reserved. Oracle Home : /rdsdbbin/oracle Central Inventory : /rdsdbbin/oraInventory from : /rdsdbbin/oracle/oraInst.loc OPatch version : 12.2.0.1.23 OUI version : 12.2.0.7.0复制
14.将补丁应用于备用数据库ORACLE_HOME后，重新启动备用实例：
DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb1_b; Connected to an idle instance. Connected as SYSDG. DGMGRL> startup mount Connected to "DEMODB1_B" ORACLE instance started. Database mounted.复制
Data Guard broker将自动重新启动媒体恢复。
15.通过在备用实例上运行以下命令，验证修补程序是否已成功安装：
opatch lsinventory复制
16.在备用实例上启动数据库侦听器：
bash-4.2$ lsnrctl start l_demodb1_001复制
17.在备用实例上启动Data Guard侦听器：
bash-4.2$ lsnrctl start l_demodb1_dg复制
停机时间从这里开始，相当于Data Guard实例切换时间。
18.验证备用数据库以查看它是否准备好进行切换，然后将主数据库切换到备用数据库：
Connect to standby -bash-4.2$ dgmgrl DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Nov 17 10:37:02 2021 Version 19.10.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb1_b; Connected to "DEMODB1_b" Connected as SYSDG. ***Validate the status DGMGRL> validate database verbose demodb1_b Database Role: Physical standby database Primary Database: demodb1_b Ready for Switchover: Yes Ready for Failover: Yes (Primary Running) Flashback Database Status: demodb1_b: Off demodb1_a: Off Capacity Information: Database Instances Threads demodb1_b 1 1 demodb1_a 1 1 Managed by Clusterware: demodb1_b: NO demodb1_a: NO Validating static connect identifier for the primary database demodb1_a... The static connect identifier allows for a connection to database "demodb1_a". Temporary Tablespace File Information: demodb1_b TEMP Files: 1 demodb1_a TEMP Files: 1 Data file Online Move in Progress: demodb1_b: No demodb1_a: No Standby Apply-Related Information: Apply State: Running Apply Lag: 0 seconds (computed 0 seconds ago) Apply Delay: 0 minutes Transport-Related Information: Transport On: Yes Gap Status: No Gap Transport Lag: 0 seconds (computed 0 seconds ago) Transport Status: Success Connect to Primary database: DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb1_a; Connected to "DEMODB1_A" Connected as SYSDG. Switchover to standby database DGMGRL> switchover to demodb1_b Performing switchover NOW, please wait... Operation requires a connection to database "demodb1_b" Connecting ... Connected to "DEMODB_B" Connected as SYSDG. New primary database "demodb1_b" is opening... Operation requires start up of instance "DEMODB" on database "demodb1_a" Starting instance "DEMODB"... Connected to an idle instance. ORACLE instance started. Connected to "DEMODB1_A" Database mounted. Connected to "DEMODB1_A" Switchover succeeded, new primary is "demodb1_b" DGMGRL> Downtime ends here.复制
19.重复步骤9–17，在新的备用（旧的主）实例上应用修补程序。
20.连接到处于打开和读/写模式的主数据库，然后运行datapatch。请注意以下事项：
a.按照补丁自述中的步骤进行操作。
b.将修改后的SQL文件加载到数据库中。
c.运行datapatch以完成正在安装的修补程序的安装后SQL部署。在主站点上应用数据修补程序。
% cd $ORACLE_HOME/OPatch % ./datapatch -verbose复制
21.所有活动完成后，我们可以通过运行以下AWS CLI命令恢复RDS Custom实例的自动化：
aws rds modify-db-instance --db-instance-identifier flex-instance-s --automation-mode full --region us-west-2复制
场景2：将19c 2021 7月RU应用于安装了JVM的DB实例
在第二个场景中，我们将启用JVM的DemoB2 RDS自定义数据库实例从2021 4月19日升级到2021 7月19日。Oracle将季度更新作为一个组合补丁发布，其中包括数据库补丁和JVM补丁。数据库修补程序通常是Standby First Patch Installable，但Oracle不会将JVM修补程序归类为Standby Forst Installable，因此在启用JVM选项时，不建议使用Standby-First Patch Apply方法。在这种情况下，停机时间更长，因为在应用这些JVM补丁时，主服务器和备用服务器都应该停机。有关更多详细信息，请参阅Oracle Doc ID 2217053.1。
1.使用以下AWS CLI命令暂停RDS Custom实例demodb2_a及其副本demodb2_b的自动化：
aws rds modify-db-instance --db-instance-identifier custom-ORCL --automation-mode all-paused --resume-full-automation-mode-minute 120 --region us-east-2复制
2.使用SSH密钥或Systems Manager连接到底层EC2实例。
3.以ec2用户身份登录后，切换到rdsdb用户，该用户拥有数据库二进制文件。
4.使用sysdba权限连接到实例：
$sudo su - rdsdb $sqlplus / as sysdba复制
接下来，从Secrets Manager检索Amazon rds Custom for Oracle的sys/system和rds_dataguard用户的数据库密码。
5.在Amazon RDS控制台的导航窗格中，选择数据库，然后选择主数据库。
6.选择Configuration并记录资源ID（其格式为db-R4ZMRQ7YJQGY7EL7I3AUVVRGVA）。
7.在Secrets Manager控制台上，选择与不删除自定义-<resource_id>-xxxx（sys用户）和不删除自定义-<resources_id>-xxxx dg（对于rds_dataguard）同名的机密。
8.选择Retrieve secret value并记下数据库用户的密码。
9.停止备用实例上的侦听器：
-bash-4.2$ lsnrctl stop l_demodb2_001 LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 17-NOV-2021 07:03:57 Copyright (c) 1991, 2020, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=x.x.0.253))) The command completed successfully复制
10.停止备用实例上Data Guard的侦听器：
bash-4.2$ lsnrctl stop l_demodb2_dg LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 17-NOV-2021 07:03:51 Copyright (c) 1991, 2020, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1140)(HOST=x.x.0.253))) The command completed successfully复制
11.关闭备用实例：
-bash-4.2$ dgmgrl DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Nov 17 10:53:45 2021 Version 19.10.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb2_b; Connected to "DEMODB2_B" Connected as SYSDG. DGMGRL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. Connected to an idle instance. DGMGRL> exit复制
12.运行opatch prereq以确保没有冲突。（请参阅修补程序自述中的步骤。）
在下面的示例中，我们展示了JVM补丁（32876380）；您可以使用opatch以类似的方式应用数据库修补程序：
bash-4.2$unzip p32876380_190000_Linux-x86-64.zip bash-4.2$ cd 32876380 bash-4.2$ pwd /tmp/32876380 bash-4.2$ export PATH=$ORACLE_HOME/OPatch:$PATH bash-4.2$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.2.0.1.23复制
13.通过在备用实例上运行以下命令来安装修补程序（此时不要运行datapatch）。
在下面的示例中，我们展示了JVM补丁（32876380）；您可以使用opatch以类似的方式应用数据库修补程序：
-bash-4.2$ pwd /tmp/32876380 -bash-4.2$ opatch apply Oracle Interim Patch Installer version 12.2.0.1.27 Copyright (c) 2022, Oracle Corporation. All rights reserved. Oracle Home : /rdsdbbin/oracle Central Inventory : /rdsdbbin/oraInventory from : /rdsdbbin/oracle/oraInst.loc OPatch version : 12.2.0.1.27 OUI version : 12.2.0.7.0复制
14.通过运行以下命令验证修补程序是否已成功安装:
opatch lsinventory复制
15.关闭服务器上运行的主实例和侦听器（此时开始停机）。
-bash-4.2$ dgmgrl DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Nov 17 10:53:45 2021 Version 19.10.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb2_a; Connected to "DEMODB2_A" Connected as SYSDG. DGMGRL> shutdown immediate bash-4.2$ lsnrctl start l_demodb2_dg复制
16.重复步骤9-14，在主实例上应用修补程序。
17.通过运行以下命令验证修补程序是否已成功安装：
opatch lsinventory复制
18.启动主数据库和侦听器:
DGMGRL> connect RDS_DATAGUARD/dg_12345$@demodb2_a; Connected to an idle instance. Connected as SYSDG. DGMGRL> startup open Connected to "DEMODB2_A"复制
19.在主实例上启动数据库侦听器（此时停机结束）:
$ lsnrctl start l_demodb2_001复制
20.在主实例上启动Data Guard侦听器:
$ lsnrctl start l_demodb2_dg复制
21.连接到主数据库所在的主机，该主机处于打开状态并处于读/写模式，然后运行datapatch实用程序。请注意以下事项：
a.按照补丁自述中的步骤进行操作。
b.将修改后的SQL文件加载到数据库中。
c.运行datapatch以完成正在安装的修补程序的安装后SQL部署。在主站点上应用数据修补程序。
% cd $ORACLE_HOME/OPatch % ./datapatch -verbose复制
22.启动备用数据库和侦听器。
23.使用以下AWS CLI命令在RDS Custom实例上恢复自动化：
aws rds modify-db-instance --db-instance-identifier flex-instance-s --automation-mode full --region us-west-2复制
Oracle Data Guard Standby First Patch Apply不需要任何附加许可证；它与Oracle Data Guard或Active Data Guard配合使用，后者仅在Oracle Enterprise Edition上受支持。Oracle Active Data Guard是Oracle Enterprise Edition之上的一个附加许可选项。有关更多详细信息，请参阅Oracle数据库产品允许的功能、选项和管理包。从AWS的角度来看，在副本中使用Oracle Data Guard Standby First Patch Apply没有额外成本。您可以在所有支持Amazon RDS Custom for Oracle的商业AWS地区的RDS自定义实例上使用Oracle Data Guard Standby First Patch Apply。Oracle Data Guard Standby First Patch Apply在Oracle支持的所有数据库版本上都受支持，在Amazon RDS Custom上也受支持，包括12c、18c和19c版本。
总结
在本文中，我们展示了如何使用Oracle的Data Guard Standby First Patch Apply方法在RDS Custom for Oracle实例中应用季度发布更新或一次性更新，以减少修补停机时间。我们还介绍了在Amazon RDS Custom for Oracle中使用此方法时应遵循的一些最佳实践，并回顾了在AmaAmazon RDS Custom of Oracle中使用该方法时的定价和许可注意事项。在评论部分分享你的想法。
关于作者
Yamuna Palasamudram是Amazon Web Services的高级数据库专家解决方案架构师。她与AWS RDS团队合作，专注于Oracle等商业数据库引擎。她喜欢与客户合作，帮助设计、部署和优化AWS上的关系数据库工作负载。
Manash Kalita是东盟亚马逊网络服务高级数据库专家解决方案架构师，在企业云架构方面拥有丰富经验。
原文标题：Reduce database patching downtime in Amazon RDS Custom for Oracle using Oracle Data Guard Standby-First Patch Apply
原文作者：Yamuna Palasamudram and Manash Kalita
原文链接：https://aws.amazon.com/blogs/database/reduce-database-patching-downtime-in-amazon-rds-custom-for-oracle-using-oracle-data-guard-standby-first-patch-apply/
