简介本资源为 Oracle 11.2.0.3 版本最后一个 GIGrid InfrastructurePSU 补丁包版本号 .15同时包含数据库组件适用于仍在使用该版本、需要完成安全加固与稳定性维护的 DBA 及运维人员。补丁包文件名 p20996944_112030_Linux-x86-64.zip面向 Linux x86-64 平台是集群软件、ASM、OCR 与 Voting Disks 等核心组件的重要更新集合。压缩包整体约 599.65MB内含 README 说明文档、PatchSearch.xml 与 bundle.xml 等 OPatch 元数据文件以及若干独立补丁编号目录便于按官方流程完成预检查、应用与后处理。目前已有 400 人学习下载适合需要为老旧 11.2.0.3 环境补齐最后一批官方修复、提升高可用性与性能的读者参考使用。1. Oracle 11.2.0.3 最后的 GI PSU为什么这个补丁包值得单独存档手里还跑着 Oracle 11.2.0.3 这套老库的同行大概率都经历过一个尴尬时刻想给 Grid Infrastructure 打最后一个官方补丁翻遍内部归档和镜像站发现 p20996944 这个包要么链接失效要么只剩一个孤零零的 zip 没人敢确认它到底能不能用。Oracle 11.2.0.3 的 GI PSU 到 15 这个版本就基本收尾了后面再想往上走就得整体升级到 12c 甚至更高而很多生产环境因为业务绑定、认证兼容、停机窗口这些现实原因短期内根本动不了大版本。所以这个 p20996944_112030_Linux-x86-64.zip 就成了一个封顶补丁——它同时包含 GI 和 DB 两部分的 PSU 内容是 11.2.0.3 这条线上最后一个能一次性把集群件和数据库补丁都覆盖到的整合包。这篇文章不聊升级路线只聊这个包本身它里面装了什么、怎么在 Linux x86-64 上把它打进去、opatch 冲突怎么排、以及为什么很多人第一次打会翻车。2. 拆开 p20996944GI 与 DB 双补丁的结构与前置校验2.1 这个包到底包含哪些组件p20996944 是 Oracle 在 11.2.0.3 末期推出的整合 PSU版本号对应 11.2.0.3.15。它和早期那种 GI、DB 分开下载的补丁不一样一个 zip 里同时带了 Grid Infrastructure 侧的补丁和 Database 侧的补丁安装时需要分别对 GI Home 和 DB Home 执行。这一点很关键因为很多人拿到包之后只打了一遍就以为完事了结果集群件还是旧版本后面各种诡异问题就来了。从目录结构上看解压后通常能看到两个顶层目录一个对应 GI 的补丁集一个对应 DB 的补丁集各自带独立的 README 和 patch 目录。README 里会写明适用的平台、前置补丁要求、以及是否需要先打某个 overlay 补丁。我一般拿到包的第一件事不是急着 opatch apply而是先把 README 通读一遍尤其是Prerequisites和Known Issues两节这两节能省掉后面至少一半的排查时间。需要提前确认的环境信息包括当前 GI 和 DB 的 opatch 版本、当前已安装的 PSU 列表、以及两个 Home 的 ORACLE_HOME 路径。这三样东西决定了你能不能直接打这个包还是得先补前置补丁。2.2 打补丁前的环境快照与 opatch 版本检查在动手之前先做一次完整的环境快照。这不是形式主义而是万一打完之后集群起不来你至少知道回退到什么状态。下面这几条命令我每次都会跑一遍输出存成文件留档。# 分别对 GI Home 和 DB Home 执行确认 ORACLE_HOME 指向正确 echo $ORACLE_HOME echo $ORACLE_HOME/OPatch/opatch version # 查看当前已安装的补丁列表重点看有没有冲突的 overlay 或已存在的 PSU $ORACLE_HOME/OPatch/opatch lsinventory -detail # 记录集群当前状态作为回退参照 crsctl stat res -t /tmp/crs_before_patch.txt这几条命令的逻辑很直接opatch version确认补丁工具本身够不够新11.2.0.3 打 PSU 15 一般要求 opatch 在 11.2.0.3.5 以上太老的话 opatch 自己就会报错拒绝执行。lsinventory -detail是排查冲突的核心依据如果里面已经存在某个和 p20996944 冲突的补丁opatch apply 会直接失败。crsctl stat res -t则是留一份集群资源状态打完补丁后对比能快速判断有没有资源没起来。参数上没什么可调的-detail建议加上虽然输出长但能看到每个补丁影响的组件比默认的简略列表有用得多。输出文件建议按时间戳命名别用固定名字不然打第二次的时候把第一次的记录覆盖了回退时就抓瞎。2.3 解压与补丁目录的确认拿到 zip 之后解压路径有讲究。不要解压到 ORACLE_HOME 里面也不要用 root 去解压用 oracle 用户解到一个独立的临时目录比如 /tmp/patch_work 或者 /u01/soft/p20996944。原因是 opatch 在执行时会检查补丁目录的权限和属主如果目录属主是 rootopatch 会报权限错误。# 用 oracle 用户操作解压到独立目录 mkdir -p /u01/soft/p20996944 cd /u01/soft/p20996944 unzip p20996944_112030_Linux-x86-64.zip # 解压后确认目录结构找到 GI 和 DB 两个补丁子目录 ls -l find . -maxdepth 2 -name README* -o -name etc -type d解压完成后你会看到类似 20996944 这样的数字目录里面再分 GI 和 DB 的子目录。每个子目录下都有 etc/config 和 files 结构这是标准 opatch 补丁格式。确认目录属主是 oracle:oinstall权限至少 755否则后面 opatch 会以各种奇怪的理由拒绝。这里有个容易忽略的点如果你的环境同时有多个 ORACLE_HOME比如 GI Home 和 DB Home 分开一定要记清楚哪个补丁目录对应哪个 Home。打反了的话opatch 可能不报错但实际什么都没打进去或者报一个含糊的组件不匹配错误。3. 对 GI Home 和 DB Home 分别执行 opatch apply 的完整流程3.1 先停集群还是先打补丁顺序不能乱11.2.0.3 的 GI PSU 打补丁标准做法是先停掉集群件相关的资源但不是把整个 CRS 都停了。正确的顺序是先停 DB 实例和监听再停 ASM 实例如果 ASM 独立于 GI最后对 GI Home 执行 opatch。GI Home 的补丁在 apply 之后需要重启集群才能生效所以整个流程是停资源 → 打 GI 补丁 → 打 DB 补丁 → 重启集群 → 起资源。很多人图省事直接 crsctl stop crs 把整个集群停了再打这样也能打进去但重启后如果某个资源起不来你很难判断是补丁本身的问题还是停机顺序导致的。我一般会按资源逐个停留一份清晰的停止日志。# 以 root 执行停 DB 实例和监听具体实例名按实际环境替换 srvctl stop database -d db_name srvctl stop listener # 确认 ASM 状态如果 ASM 由 GI 管理不需要单独停 srvctl status asm # 停 GI 相关的高可用服务保留 CRS 本身运行以便 opatch 能操作 crsctl stop resource -allcrsctl stop resource -all会把所有资源停掉但保留 CRS 守护进程这样 opatch 对 GI Home 操作时不会因为 CRS 在跑而报文件占用。这一步做完确认crsctl stat res -t里所有资源都是 OFFLINE 状态再往下走。3.2 GI Home 的 opatch apply 与冲突处理GI Home 的补丁是第一步也是最容易出问题的一步。执行前先 cd 到 GI 对应的补丁子目录然后 opatch apply。注意要用 GI Home 的 opatch不是 DB Home 的。# 切换到 GI Home 的 opatch export ORACLE_HOME/u01/app/11.2.0/grid cd /u01/soft/p20996944/GI补丁子目录 # 执行 apply-local 表示只打本节点RAC 环境逐节点打 $ORACLE_HOME/OPatch/opatch apply -local # 如果报冲突用 -analyze 先看冲突详情 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./opatch apply -local里的-local在 RAC 环境下很重要它表示只对当前节点生效避免 opatch 尝试去操作远程节点导致权限或通信问题。RAC 环境的标准做法是逐节点滚动打打完一个节点确认集群正常再打下个节点。如果 apply 报 Patch 20996944 conflicts with... 这类错误说明当前 Home 里已经有一个和它冲突的补丁。这时候不要强行加-force先用prereq CheckConflictAgainstOHWithDetail看清楚冲突的是哪个补丁。常见冲突是之前打过某个 overlay 补丁比如 11.2.0.3 的某个 one-off需要先回退那个 overlay 再打这个 PSU。强行 force 的后果是组件版本混乱后面 lsinventory 里会出现重复条目回退时非常痛苦。apply 成功后opatch 会提示你运行opatch lsinventory确认并且 GI Home 需要执行$ORACLE_HOME/root.sh有些版本是roothas.pl。这一步别漏漏了的话补丁文件虽然拷进去了但权限和链接没更新集群重启后可能起不来。3.3 DB Home 的补丁与数据字典更新GI Home 打完并确认 root.sh 执行成功后再打 DB Home。DB Home 的补丁流程类似但多了一步数据字典更新——也就是跑 catbundle.sql 或者对应的 datapatch 脚本。11.2.0.3 时代还没有 datapatch 这个工具datapatch 是 12c 才引入的所以 DB 侧的字典更新要靠手工执行 catbundle.sql。# 切换到 DB Home export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 cd /u01/soft/p20996944/DB补丁子目录 # 对 DB Home 执行 apply $ORACLE_HOME/OPatch/opatch apply -local # apply 成功后启动数据库到 upgrade 模式执行字典更新 sqlplus / as sysdba SQL startup upgrade SQL ?/rdbms/admin/catbundle.sql psu apply SQL shutdown immediate SQL startupcatbundle.sql psu apply这个参数组合是关键psu表示更新 PSU 相关的字典信息apply表示执行应用而不是回退。执行过程中会输出大量日志重点看有没有 ORA- 错误。如果中途报错不要直接 shutdown先看错误内容有些错误是幂等的比如某个对象已存在可以忽略继续有些则是致命的需要回退补丁。字典更新完成后查dba_registry_history确认 PSU 版本已经更新到 11.2.0.3.15。这个视图里的 action 列会显示 APPLYversion 列显示 11.2.0.3.15action_time 是你执行的时间。如果这里没更新说明 catbundle 没跑成功后面应用连上来可能遇到各种奇怪的权限或包编译错误。3.4 重启集群与资源验证两个 Home 都打完、字典也更新完之后按停止的逆序把资源起回来。先起 CRS 管理的资源再起 ASM最后起 DB 实例和监听。# 以 root 执行启动所有 CRS 资源 crsctl start resource -all # 确认集群资源状态和打补丁前的快照对比 crsctl stat res -t # 启动 DB 实例和监听 srvctl start listener srvctl start database -d db_name # 验证数据库版本和 PSU 版本 sqlplus / as sysdba SQL select version from v$instance; SQL select * from dba_registry_history where actionAPPLY;crsctl stat res -t的输出要和之前存的/tmp/crs_before_patch.txt对比重点看有没有资源状态从 ONLINE 变成了 OFFLINE 或者 UNKNOWN。如果有先看crsctl stat res 资源名 -p的详细信息再查对应日志。常见的是 VIP 或 SCAN 资源起不来多半是网络配置在补丁过程中被重置了需要重新确认oifcfg和srvctl config network。数据库起来之后除了查版本建议再跑一次utlrp.sql编译无效对象。PSU 更新后有些包和视图会失效不编译的话应用连上来可能报 ORA-04063 之类的错误。SQL ?/rdbms/admin/utlrp.sql -- 编译完成后查无效对象数量 SQL select count(*) from dba_invalid_objects;这个 count 最好是 0如果不是 0看具体是哪些对象大部分情况下再跑一次 utlrp 就能解决少数需要手工重建。4. 打这个补丁最容易翻车的几个地方4.1 现象opatch apply 报 Cannot find any patch to apply原因通常是补丁目录选错了或者解压不完整。p20996944 解压后顶层是数字目录但真正的补丁在下一级子目录里如果你在顶层直接跑 opatch apply它会找不到 etc/config。解决方法是 cd 到包含 etc 目录的那一级再执行用ls etc/config确认一下。4.2 现象GI Home 打完补丁后集群起不来crsctl 报 CRS-4535这个多半是 root.sh 没执行或者执行失败。GI Home 的补丁 apply 之后必须用 root 跑一次$ORACLE_HOME/root.sh它会更新一些二进制文件的权限和属主。如果漏了集群守护进程启动时会因为权限问题挂掉。解决方法是补跑 root.sh然后crsctl stop crs -f再crsctl start crs。4.3 现象DB 侧 catbundle.sql 执行到一半报 ORA-00955 对象已存在这是幂等性问题不是致命错误。catbundle.sql 里有些 create 语句在重复执行时会报对象已存在但脚本本身会继续往下跑。判断标准是看脚本最后有没有输出 PL/SQL procedure successfully completed 和字典更新完成的提示。如果最后有成功提示中间这些 ORA-00955 可以忽略。如果脚本中途中断了那就得看具体中断在哪一步可能需要手工补跑。4.4 现象打完补丁后应用连上来报 ORA-01031 权限不足这个通常是字典更新没跑完或者 utlrp 没跑。PSU 更新会修改一些系统包的权限和定义如果 catbundle 没执行或者执行失败这些包的权限还是旧的应用调用时就会报权限错误。解决方法是重新跑 catbundle.sql 和 utlrp.sql然后确认dba_registry_history里的版本已经更新。4.5 现象RAC 环境一个节点打完正常另一个节点打的时候报通信错误RAC 滚动打补丁时如果第一个节点打完还没完全起来就去打第二个节点opatch 可能会因为集群通信异常而报错。正确做法是第一个节点打完、集群资源全部 ONLINE、数据库能正常连接之后再操作第二个节点。每个节点打完都要做一次完整的资源状态确认不要图快连着打。5. 补丁打完之后的验证习惯与一个回退技巧补丁打完不是终点验证才是。我一般会做三层验证第一层是 opatch lsinventory 确认补丁在列表里且没有冲突条目第二层是数据库层面的 dba_registry_history 和组件版本查询第三层是应用层面的——挑几个核心业务 SQL 跑一遍确认执行计划没有因为 PSU 更新而发生剧烈变化。11.2.0.3 的 PSU 有时候会引入优化器行为的微调虽然概率不高但生产环境值得多这一步。回退方面opatch 提供了 rollback 能力但前提是你保留了打补丁前的 inventory 快照和补丁目录。回退命令是opatch rollback -id 20996944对 GI 和 DB 分别执行。但要注意DB 侧回退之后还需要跑 catbundle.sql 的回退模式catbundle.sql psu rollback否则字典里的版本信息和实际文件不一致后面再打补丁会报冲突。# 回退示例先回退 DB Home再回退 GI Home export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 cd /u01/soft/p20996944/DB补丁子目录 $ORACLE_HOME/OPatch/opatch rollback -id 20996944 -local # 回退后启动数据库到 upgrade 模式跑字典回退 sqlplus / as sysdba SQL startup upgrade SQL ?/rdbms/admin/catbundle.sql psu rollback SQL shutdown immediate SQL startup回退的坑在于如果你打补丁之后又打了别的 one-off回退这个 PSU 之前得先把后面的 one-off 回退掉否则 opatch 会报依赖冲突。所以打完补丁之后建议把补丁目录和 inventory 快照一起归档别打完就删。我见过太多人打完补丁把 zip 删了结果出问题想回退的时候找不到补丁文件只能硬着头皮往前修。还有一个习惯每次打完 PSU把opatch lsinventory -detail的输出、crsctl stat res -t的输出、dba_registry_history的查询结果三样东西存到一个以日期命名的目录里。这个目录就是你的后悔药下次再打补丁或者出问题排查时翻出来一对比很多问题一眼就能定位。从那以后我每次给 11.2.0.3 打 PSU 都强制走一遍这个留档流程希望帮到你。本文还有配套的精品资源点击获取
