简介本资源为 Oracle 11.2.0.3 平台最后一版 GIGrid InfrastructurePSU 补丁包版本号 .15同时包含数据库组件适用于仍在使用该版本、需要完成安全加固与稳定性维护的 DBA 及运维人员。补丁以 zip 形式分发压缩包约 599.65MB内含 README 说明文档、PatchSearch.xml 与 bundle.xml 等 OPatch 元数据文件以及若干独立补丁编号目录分别承载安装指引、补丁清单与具体修复内容便于按官方流程完成预检查、应用与后处理。该补丁集成了自上一 PSU 以来的安全修复、性能优化与已知问题解决方案覆盖集群软件、ASM、OCR 与 Voting Disks 等关键组件可帮助读者在升级前评估兼容性、理解补丁依赖关系并借助随包文档降低安装风险。目前已有 399 人学习下载适合需要为老旧 11.2.0.3 环境做最终补丁收尾的读者参考。1. 为什么 11.2.0.3 的最后一个 GI PSU 值得单独拿出来说手里还压着 Oracle 11.2.0.3 这套库的人多半不是不想升而是升不动。业务系统绑死在老版本上迁移窗口排不出来可等保测评、季度巡检、漏洞扫描又一轮轮压过来逼着你必须把补丁打到位。这时候 p20996944 这个补丁号就会被反复翻出来——它是 11.2.0.3 这条线上 GIGrid Infrastructure加 DB 一起覆盖的 PSU版本号落在 11.2.0.3.15对应 Linux x86-64 平台的 p20996944_112030_Linux-x86-64.zip。说白了这是 11.2.0.3 时代补丁序列里靠后的一班车再往后官方对这条线的支持就基本收口了。这篇不聊升级路线也不劝你上 19c就锁定一件事拿到这个 zip怎么在 Linux x86-64 上把 GI 和 DB 的 PSU 干净地打进去参数怎么设、顺序怎么排、哪里最容易翻车。适合两类人一是手上真有 11.2.0.3 RAC 或单机 GI 环境、必须自己动手的 DBA二是刚接手老库、想搞清楚 PSU、GI、opatch 这套东西到底怎么咬合的运维。下面按「先搞懂补丁结构 → 再动手打 → 最后避坑」的顺序推。2. 拆开 p20996944GI 与 DB 补丁到底装了什么2.1 PSU、GI、DB 三者的关系先理清很多人第一次打这个补丁会懵为什么一个 zip 里既有 GI 的补丁又有 DB 的补丁这要从 Oracle 的补丁体系说起。PSUPatch Set Update是累积补丁按季度发布每个 PSU 有一个唯一的补丁号p20996944 就是 11.2.0.3 第 15 个季度的那个。而 GI 和 DB 虽然共享同一套二进制安装介质但它们的 ORACLE_HOME 是分开的——GI 装在 Grid HomeDB 装在 Database Home所以同一个 PSU 号下会挂两个子补丁分别对应两个 Home。补丁号后面的_112030表示基线版本是 11.2.0.3_Linux-x86-64表示平台。这里有个血泪经验11.2.0.3 的补丁是分平台的Linux x86-64 的补丁不能拿到 AIX 或 Solaris 上用反过来也一样。下载前先uname -m确认架构别下错了再回头找。补丁内部结构大致是这样目录/文件作用README.html补丁说明含前置补丁、冲突补丁、操作步骤etc/config/inventory.xmlopatch 识别用的补丁元数据patch_id/实际补丁文件GI 和 DB 各一套opatch/部分补丁包自带 opatch版本不够时用它2.2 打之前必须确认的四件事动手前先把这四项查清楚任何一项不满足后面都会卡住。第一opatch 版本。11.2.0.3 自带的 opatch 往往太老打这个 PSU 需要 opatch 11.2.0.3.12 以上。查版本# 在 GI 和 DB 两个 Home 下分别执行 $ORACLE_HOME/OPatch/opatch version如果低于要求用补丁包里的 opatch 替换或者单独下对应版本的 opatch。注意 GI 和 DB 的 opatch 要分别升级别只升一个。第二前置补丁。README 里会列 required patches11.2.0.3.15 通常要求先打上某些基础补丁。用 opatch 检查冲突和缺失# 检查当前 Home 已安装补丁 $ORACLE_HOME/OPatch/opatch lsinventory -detail # 检查补丁冲突在解压后的补丁目录下执行 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./第三空间。GI 和 DB 的 Home 各自需要预留至少 3~5GB 临时空间/tmp也要够opatch 会往那写临时文件。空间不够报的错很隐晦提前df -h看一眼。第四备份。GI Home 和 DB Home 都要做 tar 备份OCR 和 voting disk 也要备份。这一步没有后悔药打补丁失败回滚全靠它。提示11.2.0.3 的 GI 打补丁必须用 root 用户执行 root 脚本DB 补丁用 oracle 用户即可两个 Home 的操作顺序不能颠倒。3. 在 Linux x86-64 上把 GI PSU 打进去的完整步骤3.1 停集群与 GI 补丁的前置操作GI 补丁必须在集群停止的状态下打这是硬性要求。RAC 环境先停数据库实例再停集群# 用 grid 用户停集群RAC 环境 crsctl stop crs # 确认集群已停 crsctl check crs单机 GI 环境同样要停crsctl stop has或crsctl stop crs视配置而定。停完后确认没有残留进程ps -ef | grep -E ora_|crs_|asm_ | grep -v grep有残留就手动清掉否则 opatch 会报 Home 被占用。3.2 用 opatch apply 打 GI 补丁解压补丁包进入 GI 对应的子目录用 grid 用户执行 apply# 解压 unzip p20996944_112030_Linux-x86-64.zip -d /u01/patch # 进入 GI 补丁目录具体子目录名以解压结果为准 cd /u01/patch/20996944 # 用 grid 用户执行 $ORACLE_HOME/OPatch/opatch applyapply 过程中 opatch 会做冲突检查、文件校验最后提示是否继续。看到OPatch succeeded才算成功。如果中途报Patch 20996944 requires OPatch version 11.2.0.3.12说明 opatch 没升级回到 2.2 处理。参数说明opatch apply默认会做 prereq 检查如果环境有已知冲突想跳过不推荐可以加-skip_prereq但生产环境别这么干。想指定 inventory 位置用-invPtrLoc一般用不上。3.3 执行 root 脚本与验证 GI 补丁GI 补丁 apply 完opatch 会提示需要以 root 执行脚本。脚本路径通常在$ORACLE_HOME/OPatch/下名字类似custom/scripts/...具体以 opatch 输出为准# 切 root 执行 opatch 提示的脚本 su - root $ORACLE_HOME/OPatch/crs/patch11203.sh -patchdir $ORACLE_HOME -paramfile $ORACLE_HOME/OPatch/crs/patch11203_paramfile这个脚本会更新 GI 的二进制、重新链接、更新 OCR 里的补丁信息。执行完切回 grid 用户验证$ORACLE_HOME/OPatch/opatch lsinventory | grep 20996944能看到补丁号就说明 GI 侧打上了。然后启动集群crsctl start crs crsctl check crs集群起来后确认 ASM 和资源都正常再动 DB 补丁。4. DB 补丁怎么打顺序、参数与验证4.1 DB 补丁与 GI 补丁的先后关系GI 补丁打完、集群正常后才能打 DB 补丁。顺序反了会出现 GI 和 DB 二进制版本不一致集群可能起不来。DB 补丁在 Database Home 下操作用 oracle 用户不需要停集群但要停数据库实例# 停实例 srvctl stop database -d db_name # 或单实例 sqlplus / as sysdba SQL shutdown immediate;停完确认没有 pmon 残留再进 DB 补丁目录。4.2 opatch apply 打 DB 补丁并跑 datapatchDB 补丁的 apply 和 GI 类似但目录不同cd /u01/patch/20996944/db_patch_subdir $ORACLE_HOME/OPatch/opatch applyapply 成功后11.2.0.3 的 PSU 还需要跑 datapatch 来更新数据字典。这一步很多人漏掉导致补丁打了但 SQL 层面没生效# 启动实例到 open 状态 sqlplus / as sysdba SQL startup; # 跑 datapatch cd $ORACLE_HOME/OPatch ./datapatch -verbosedatapatch 会扫描$ORACLE_HOME/sqlpatch下的补丁 SQL逐个应用到数据库。输出里每个补丁显示SUCCESS才算完成。如果报ORA-错误看$ORACLE_HOME/cfgtoollogs/sqlpatch下的日志定位。参数说明-verbose输出详细过程排错时必加。-apply是默认行为-rollback用于回滚。datapatch 必须在实例 open 且没有其他会话干扰时跑最好在维护窗口做。4.3 验证 DB 补丁是否真正生效打完不能只看 opatch要查数据库里的补丁视图-- 查已应用的补丁 SELECT patch_id, patch_type, action, status, action_time FROM dba_registry_sqlpatch ORDER BY action_time DESC; -- 11.2.0.3 老版本可能用这个视图 SELECT * FROM registry$sqlpatch;status为SUCCESS且action为APPLY才算真正生效。同时确认版本号SELECT version, banner FROM v$version;banner 里会带上 PSU 版本信息。GI 侧再用crsctl query crs activeversion确认集群版本一致。5. 打这个补丁最容易翻车的几个地方5.1 现象opatch apply 报 OPatch version 不满足原因11.2.0.3 原始安装的 opatch 版本太低p20996944 要求 11.2.0.3.12 以上。解决用补丁包自带的 opatch 替换或单独下载对应版本。替换前备份原 opatch 目录替换后opatch version确认。GI 和 DB 两个 Home 都要换只换一个另一个还会报。5.2 现象root 脚本执行后集群起不来原因root 脚本没跑完就中断或者跑的时候集群没完全停干净。解决先crsctl stop crs -f强制停确认无残留进程重新跑 root 脚本。如果 OCR 损坏用备份恢复 OCR 再重跑。这个坑最要命所以打补丁前 OCR 备份是必须的。5.3 现象datapatch 报 ORA-04063 或包状态 INVALID原因补丁 SQL 执行时依赖的对象失效或者有会话占用导致 DDL 卡住。解决确认没有其他会话连库shutdown immediate后重启再跑 datapatch。如果还有 INVALID 对象用utlrp.sql重编译?/rdbms/admin/utlrp.sql重编译后再查dba_registry_sqlpatch确认状态。5.4 现象GI 和 DB 补丁版本不一致导致集群告警原因只打了 GI 没打 DB或反过来或者其中一个 apply 失败没发现。解决两个 Home 分别opatch lsinventory | grep 20996944确认缺哪个补哪个。集群版本用crsctl query crs activeversion和 DB 的v$version对比不一致就回滚重打。5.5 现象补丁打完空间暴涨或 /tmp 被写满原因opatch 和 datapatch 会在 Home 和 /tmp 下留大量临时文件和日志。解决打之前df -h确认空间打完清理$ORACLE_HOME/.patch_storage下的旧备份确认不需要回滚后再删。/tmp不够可以设TMP和TMPDIR环境变量指向大分区。6. 回滚与一个我常用的验证习惯补丁打翻车了回滚是最后的退路。GI 和 DB 的回滚都用 opatch# GI 回滚集群停止状态下 cd /u01/patch/20996944/gi_patch_subdir $ORACLE_HOME/OPatch/opatch rollback -id 20996944 # DB 回滚 cd /u01/patch/20996944/db_patch_subdir $ORACLE_HOME/OPatch/opatch rollback -id 20996944 # 回滚后跑 datapatch 回退数据字典 cd $ORACLE_HOME/OPatch ./datapatch -rollback -verbose回滚 GI 后同样要跑 root 脚本再启动集群。回滚不是万能的如果 root 脚本已经改了 OCR回滚后 OCR 里的补丁信息可能对不上这时候就得靠打补丁前的 OCR 备份恢复。所以再强调一次备份是回滚的前提没备份就别指望回滚。我自己的习惯是补丁打完不急着收工先做一轮「三查」查 opatch lsinventory 确认两个 Home 都有补丁号查 dba_registry_sqlpatch 确认 datapatch 状态 SUCCESS查 v$version 和 crsctl query crs activeversion 确认版本一致。这三查过了再让业务连上来跑一轮核心 SQL 验证。老库打补丁最怕的就是「看起来成功了」实际上某个 Home 没打上或者 datapatch 没跑等业务报错才发现那时候排查成本翻几倍。11.2.0.3 这条线已经走到尾声p20996944 作为靠后的 GIDB 合并 PSU能打就打别拖。打之前把 opatch 升到位、备份做扎实、顺序记清楚剩下的就是按步骤走。希望帮到你。本文还有配套的精品资源点击获取