补丁：将网格基础结构（GI）版本更新（RU）应用于新的ORACLE_HOME（就地修补）

原创 eternity 2022-10-12

984

本文给出了一个将网格基础设施（GI）发布更新（RU）应用于新ORACLE_HOME以进行Real Application Clusters（RAC）安装的示例。这被称为不适当的修补。

在进行任何修补之前，应始终检查修补程序注释。始终有可能引入了一些更改，使过程与此处介绍的不同。

假设
环境
应用修补程序
已关闭PDB上的数据修补程序
清理
检查修补程序历史记录
回滚修补程序
利弊

假设

本文做了一些假设。

我们现有Oracle 19c或21c RAC安装。
我们有数据库和所有ORACLE_HOME的备份。
我们已经下载了本季度的相关OPatch和补丁文件，如下所示。

环境

设置环境。这包括OPatch和修补程序文件名以及路径。请注意OPatch是如何添加到PATH环境变量的，如果在用户之间切换，请记住重置这些值。

export SOFTWARE_DIR=/u01/software
export ORACLE_BASE=/u01/app/oracle

# 19c
export OLD_GRID_HOME=/u01/app/19.0.0/grid
export NEW_GRID_HOME=/u01/app/19.16.0/grid
export OLD_DB_HOME=${ORACLE_BASE}/product/19.0.0/dbhome_1
export NEW_DB_HOME=${ORACLE_BASE}/product/19.16.0/dbhome_1
export OPATCH_FILE="p6880880_190000_Linux-x86-64.zip"
export PATCH_FILE="p34130714_190000_Linux-x86-64.zip"
export PATCH_TOP=${SOFTWARE_DIR}/34130714

# 21c
export OLD_GRID_HOME=/u01/app/21.0.0/grid
export NEW_GRID_HOME=/u01/app/21.7.0/grid
export OLD_DB_HOME=${ORACLE_BASE}/product/21.0.0/dbhome_1
export NEW_DB_HOME=${ORACLE_BASE}/product/21.0.0/dbhome_1
export OPATCH_FILE="p6880880_210000_Linux-x86-64.zip"
export PATCH_FILE="p34155589_210000_Linux-x86-64.zip"
export PATCH_TOP=${SOFTWARE_DIR}/34155589

export ORACLE_HOME=${OLD_GRID_HOME}
export PATH=${ORACLE_HOME}/OPatch:${PATH}

应用修补程序

除非另有说明，否则作为网格所有者用户发布以下命令。

保留现有OPatch的副本，并在集群的所有节点上解压缩最新版本的OPatch。您可能必须以网格主目录的根用户身份执行此操作，但请确保解压缩后得到的OPatch目录的所有权与原始所有权相匹配。

cd ${OLD_GRID_HOME}
mv OPatch OPatch.`date +"%Y"-"%m"-"%d"`
unzip -oq ${SOFTWARE_DIR}/${OPATCH_FILE}

cd ${OLD_DB_HOME}
mv OPatch OPatch.`date +"%Y"-"%m"-"%d"`
unzip -oq ${SOFTWARE_DIR}/${OPATCH_FILE}

解压缩集群所有节点上的GI版本更新修补程序软件。

cd ${SOFTWARE_DIR}
unzip -oq ${PATCH_FILE}

以网格所有者身份运行以下命令，检查修补程序冲突。修补程序编号将根据您使用的GI版本更新而有所不同。

# 19c
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34133642
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34160635
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34139601
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34318175
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/33575402

# 21c
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34160444
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34172227
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34172231
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34174046
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34320616
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ${PATCH_TOP}/34327014

检查是否有空间完成修补。创建一个名为“/tmp/patch_list_gihome.txt”的文件，其中包含补丁列表，然后作为网格所有者运行空间检查。修补程序编号将根据您使用的GI版本更新而有所不同。

# 19c
cat > /tmp/patch_list_gihome.txt <<EOF
${PATCH_TOP}/34133642
${PATCH_TOP}/34160635
${PATCH_TOP}/34139601
${PATCH_TOP}/34318175
${PATCH_TOP}/33575402
EOF

# 21c
cat > /tmp/patch_list_gihome.txt <<EOF
${PATCH_TOP}/34160444
${PATCH_TOP}/34172227
${PATCH_TOP}/34172231
${PATCH_TOP}/34174046
${PATCH_TOP}/34320616
${PATCH_TOP}/34327014
EOF

opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt

它应该报告“Prereq”checkSystemSpace“passed.”消息。如果没有，请提供更多可用空间。

在补丁目录中创建一个“clone.properties”文件，其中包含old home和new home之间的映射。

cd ${PATCH_TOP}

cat > clone.properties <<EOF
${OLD_GRID_HOME}=${NEW_GRID_HOME}
${OLD_DB_HOME}=${NEW_DB_HOME}
EOF

在运行补丁之前，我们可以选择运行分析，检查补丁是否合适，但不会影响任何东西。

cd ${PATCH_TOP}

opatchauto apply -analyze

如果有任何错误，我们可以更正问题，并使用以下命令恢复修补程序。

opatchauto resume

假设修补完成且没有错误，请在集群的其余节点上运行修补程序。可以同时修补其余节点。只有第一个节点必须自己打补丁。从可用性的角度来看，最好一次只修补一个节点，所以我们在任何时候都只有一个节点不起作用。

opatchauto apply ${PATCH_TOP} -outofplace -silent ./clone.properties

完成后，确保所有服务都按预期运行。

${NEW_GRID_HOME}/bin/crsctl stat res -t

此时，您的补丁应该已经完成。

检查所有节点上的PDB是否按预期运行。

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

已关闭PDB上的数据修补程序

在正常情况下，不需要执行此步骤，因为它是作为opatchauto的一部分自动运行的。如果您有一些已关闭或处于装载模式的PDB，则可能需要分别对其应用数据修补程序。

export ORACLE_SID=cdbrac1
# Apply
export ORACLE_HOME=${NEW_DB_HOME}
# Rollback
#export ORACLE_HOME=${OLD_DB_HOME}
export PATH=${ORACLE_HOME}/bin:$PATH

确保所有可插拔数据库都已打开并运行datapatch./p>

sqlplus / as sysdba <<EOF
alter pluggable database all open;
exit;
EOF

cd $ORACLE_HOME/OPatch
./datapatch -verbose

重新编译所有无效对象。

$ORACLE_HOME/perl/bin/perl \
    -I$ORACLE_HOME/perl/lib \
    -I$ORACLE_HOME/rdbms/admin \
    $ORACLE_HOME/rdbms/admin/catcon.pl \
    -l /tmp/ \
    -b postpatch_${ORACLE_SID}_recompile \
    -C 'PDB$SEED' \
    $ORACLE_HOME/rdbms/admin/utlrp.sql

检查所有节点上的PDB，确保它们按预期运行。

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

如果有任何已关闭或标记为已安装，则值得检查PDB_PLUG_IN_VIOLATIONS视图，这可能会告诉我们原因。通常，我们可以重新启动它们来修复状态。

alter pluggable database pdb1 close;
alter pluggable database pdb1 open;

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

清理

清理修补程序软件。

cd ${SOFTWARE_DIR}
rm -Rf ${PATCH_TOP}
rm -Rf ${OPATCH_FILE}
rm -Rf ${PATCH_FILE}
rm -Rf PatchSearch.xml

检查修补程序历史记录

我们可以通过在节点上的相关主页上运行以下命令来检查修补程序历史记录。

opatch lsinventory

回滚修补程序

以root用户身份在集群的每个节点上运行以下命令。

cd ${PATCH_TOP}

export ORACLE_HOME=${NEW_GRID_HOME}
export PATH=${ORACLE_HOME}/OPatch:${PATH}

opatchauto rollback -switch-clone

完成后，确保所有服务都按预期运行。

${OLD_GRID_HOME}/bin/crsctl stat res -t

检查所有节点上的PDB，确保它们按预期运行。

sqlplus / as sysdba

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

如果有任何已关闭或标记为已安装，则值得检查PDB_PLUG_IN_VIOLATIONS视图，这可能会告诉我们原因。通常，我们可以重新启动它们来修复状态。

sqlplus / as sysdba

alter pluggable database pdb1 close;
alter pluggable database pdb1 open;

show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
SQL>

利弊：

好处：

通过修补新的ORACLE_HOME，实例离线的时间更短。请记住，我们一次只修补一个节点，所以数据库在整个操作中都是可用的。
如果我们确实需要回滚修补程序，回滚操作会更快，因为原始的ORACLE_HOME仍然存在。

弊端：

我们需要额外的磁盘空间来安装新的ORACLE_HOME。
如果我们有任何其他环境文件或脚本包含包含ORACLE_HOME的路径，则需要对其进行调整。
我们需要在某个时候清理旧的ORACLE_HOME。

有关详细信息，请参见：

Critical Patch Updates, Security Alerts and Bulletins
Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to Existing ORACLE_HOMEs

希望能帮到你。

原文标题：Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to New ORACLE_HOMEs (Out-Of-Place Patching)
原文链接：https://oracle-base.com/articles/misc/apply-gi-release-update-to-new-oracle-homes-out-of-place-patching

oracle 墨力翻译

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

关注作者

补丁：将网格基础结构（GI）版本更新（RU）应用于新的ORACLE_HOME（就地修补）

假设

环境

应用修补程序

已关闭PDB上的数据修补程序

清理

检查修补程序历史记录

回滚修补程序

利弊：

评论