暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 补丁：将网格基础结构（GI）版本更新（RU）应用于现有ORACLE_HOME

补丁：将网格基础结构（GI）版本更新（RU）应用于现有ORACLE_HOME

原创 eternity 2022-10-12
492

本文给出了一个将网格基础设施（GI）发布更新（RU）应用于现有ORACLE_HOME以进行Real Application Clusters（RAC）安装的示例。

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

  • 假设

  • 环境

  • 应用修补程序

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

  • 清理

  • 检查修补程序历史记录

  • 回滚修补程序

  • 利弊

相关文章。

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

假设

本文做了一些假设。

  • 我们现有Oracle 19c或21c RAC安装。

  • 我们有数据库和所有ORACLE_HOME的备份。我们正在将修补程序应用于现有的ORACLE_HOME，因此如果出现无法通过回滚修补程序修复的问题，我们需要一种方法来回退。

  • 我们已经下载了本季度的相关OPatch和补丁文件，如下所示。

环境

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

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

# 19c
export GRID_HOME=/u01/app/19.0.0/grid
export DB_HOME=${ORACLE_BASE}/product/19.0.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 GRID_HOME=/u01/app/21.0.0/grid
export 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=${GRID_HOME}
export PATH=${ORACLE_HOME}/OPatch:${PATH}

应用修补程序

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

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

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

cd ${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.”消息。如果没有，请提供更多可用空间。

以root用户身份在集群的第一个节点上运行修补程序。我们还可以添加“-inplace”标志，但这不是必需的。

opatchauto apply ${PATCH_TOP}

假设此操作完成且没有错误，请在集群的其余节点上运行修补程序。可以同时修补其余节点，只有第一个节点必须自己打补丁。

opatchauto apply ${PATCH_TOP}

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

${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
export ORACLE_HOME=${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用户身份在集群的每个节点上运行以下命令。

opatchauto rollback ${PATCH_TOP}

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

${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需要更多的停机时间，因为修补家庭时服务必须脱机。由于RAC节点一次打一个补丁，因此数据库在整个操作过程中都保持运行，这抵消了这一事实。

  • 如果出现无法通过回滚修补程序修复的错误，我们可能需要从备份中恢复ORACLE_HOME以恢复原始运行实例。

有关详细信息，请参见：

  • Critical Patch Updates, Security Alerts and Bulletins
  • Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to New ORACLE_HOMEs (Out-Of-Place Patching)

希望能帮助到你。

原文标题：Patching : Apply a Grid Infrastructure (GI) Release Update (RU) to Existing ORACLE_HOMEs
原文链接：https://oracle-base.com/articles/misc/apply-gi-release-update-to-existing-oracle-homes

oracle墨力翻译
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论