简介本资源为 Oracle 11.2.0.3 版本 Grid Infrastructure含数据库组件的最后一个 PSU 补丁包版本号 .15对应补丁号 p20996944适用于 Linux x86-64 平台。面向需要为老旧 11g RAC 环境做安全加固与稳定性维护的 DBA 及运维人员解决集群软件、ASM、OCR 与 Voting Disk 等核心组件的已知缺陷与安全问题。压缩包为 zip 格式整体约 599.65MB内含 README 说明文档、PatchSearch.xml 与 bundle.xml 等 OPatch 元数据文件以及若干子补丁目录便于按官方流程完成预检查、应用与后处理。目前已有 399 人学习下载。作为 11.2.0.3 的收官 PSU它一次性汇总了此前累积的安全修复与性能优化可帮助读者在无法升级大版本的前提下以最小变更获得更稳定的集群运行状态并借助包内说明文档理清依赖关系与安装顺序降低打补丁过程中的风险。1. 为什么 11.2.0.3 的 .15 补丁被叫作「最后的 GIDB 合并 PSU」如果你手上还压着一套 Oracle 11.2.0.3 的 RAC 或者单实例 GI 环境大概率听过一句话11.2.0.3 的 PSU 到 .15 就基本收尾了再往后要么升 11.2.0.4要么直接上 12c/19c。p20996944_112030_Linux-x86-64.zip就是这条收尾线上的那个包——它同时包含 Grid Infrastructure 和 Database 两部分的 PSU 内容版本号对应 11.2.0.3.15。很多做等保整改、老系统维稳、oracle 数据库安装和配置收尾的同行最后卡的就是这一步补丁号对不上、opatch 版本太老、GI 和 DB 的补丁顺序搞反结果opatch lsinventory里一堆ORA-报错。这篇不聊虚的就把这个包从「是什么」到「怎么打、坑在哪」讲清楚适合还在维护 11.2.0.3 的 DBA 和刚接手老库的运维。补丁本身不复杂复杂的是老版本环境里那些玄学依赖。2. 拆开 p20996944 这个包GI 和 DB 到底谁先谁后2.1 补丁号、版本号和 zip 命名的对应关系先把命名规则理清楚不然下载完都不知道自己拿的是不是对的。p20996944_112030_Linux-x86-64.zip拆开看p20996944是 My Oracle Support 上的补丁编号112030代表目标版本 11.2.0.3Linux-x86-64是平台。这个包的特殊之处在于它是 GI 和 DB 合并的 PSU也就是说解压后你会看到两个子目录一个给 Grid Infrastructure一个给 Database。组成作用范围典型目录是否必须GI PSU 部分CRS、ASM、集群ware解压后 GI 子目录RAC 环境必须DB PSU 部分数据库实例、数据字典解压后 DB 子目录所有环境必须OPatch 要求补丁工具本身独立升级必须提前升版本号11.2.0.3.15lsinventory 可见核对用常见做法是先确认当前opatch lsinventory里的版本再决定是否需要先升 OPatch。11.2.0.3 环境里 OPatch 版本低于 11.2.0.3.6 的直接打这个 PSU 大概率翻车报OPatch failed with error code 73之类。我一般会先把 OPatch 升到对应版本再动 PSU。2.2 为什么 GI 必须先于 DB 打这是血泪经验GI 层的补丁如果不先打DB 层打完再打 GI会出现 CRS 和数据库二进制不一致集群重启后crsctl stat res -t里资源起不来。正确顺序是停止所有数据库实例和 ASM 实例RAC 下用srvctl stop database和srvctl stop asm。在 GI 的$GRID_HOME下用 OPatch 应用 GI 部分补丁。在 DB 的$ORACLE_HOME下应用 DB 部分补丁。跑datapatch或catbundle.sql更新数据字典。重启集群和数据库验证版本。# 以 grid 用户操作 GI 层 export ORACLE_HOME/u01/app/11.2.0/grid export PATH$ORACLE_HOME/OPatch:$PATH cd /tmp/p20996944/GI opatch apply # 检查 GI 层补丁是否生效 opatch lsinventory | grep 20996944这段命令的关键是ORACLE_HOME必须指向 GI 的 home不是数据库的。opatch apply会自动读取当前目录下的patch信息。参数上没什么可调的但要注意-oh和-invPtrLoc在老环境里偶尔需要显式指定尤其是oraInst.loc不在默认路径时。2.3 DB 层补丁和 datapatch 的配合DB 层打完二进制补丁只是第一步数据字典没更新dba_registry里还是旧版本。11.2.0.3 时代还没有现在这么顺手的datapatch很多环境用的是catbundle.sql。-- 以 sysdba 登录后执行 ?/rdbms/admin/catbundle.sql psu apply -- 验证 registry 版本 select action, version, status from dba_registry_history;catbundle.sql后面的psu apply是固定写法表示应用 PSU 类型。执行完看dba_registry_history如果 status 是SUCCESS且 version 显示 11.2.0.3.15说明数据字典更新到位。这一步失败最常见的原因是 DB 层二进制补丁没打全或者$ORACLE_HOME/sqlpatch目录权限不对。3. 在 Linux x86-64 上把补丁打进去的完整步骤3.1 打补丁前的环境检查和备份老环境打补丁后悔药就是备份。至少做三件事备份$ORACLE_HOME和$GRID_HOME的OPatch目录、备份oraInventory、确认root.sh能跑。检查清单如下opatch lsinventory -detail记录当前补丁列表。crsctl query crs activeversion确认集群版本。确认/tmp空间足够解压后大概几个 G。确认oracle和grid用户的ulimit没被改过。# 备份 OPatch 和 inventory cp -rp $ORACLE_HOME/OPatch /backup/OPatch_db_bak cp -rp $GRID_HOME/OPatch /backup/OPatch_gi_bak cp -rp /u01/app/oraInventory /backup/oraInventory_bak # 解压补丁包 unzip p20996944_112030_Linux-x86-64.zip -d /tmp/p20996944 ls /tmp/p20996944解压后目录结构里会有GI和DB两个子目录别搞混。unzip的-d指定解压路径路径里不要有中文和空格老版本 OPatch 对路径敏感。3.2 GI 层补丁应用和 root 脚本GI 层打完opatch apply后会提示你用 root 执行root.sh。这一步在 RAC 下每个节点都要跑顺序不能乱。# root 用户执行 cd $GRID_HOME/rdbms/admin $GRID_HOME/perl/bin/perl -I$GRID_HOME/perl/lib -I$GRID_HOME/crs/install $GRID_HOME/crs/install/rootcrs.pl -patch # 单实例 GI 用 root.sh $GRID_HOME/root.shrootcrs.pl -patch是 RAC 环境的标准动作单实例 GI 直接跑root.sh。跑完检查crsctl stat res -t所有资源应该是ONLINE。如果ora.asm起不来先看$GRID_HOME/log/hostname/alerthostname.log。3.3 DB 层补丁和版本验证DB 层相对简单但要注意$ORACLE_HOME切换干净。# 以 oracle 用户操作 DB 层 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$PATH cd /tmp/p20996944/DB opatch apply # 验证 opatch lsinventory | grep -i 20996944\|11.2.0.3.15打完 DB 层后启动数据库到 mount 状态跑catbundle.sql再正常打开。验证版本用select * from v$version; -- 或者 select version from dba_registry_history where actionPSU;v$version里 BANNER 会显示 11.2.0.3.15 字样。如果还是旧版本说明二进制补丁没生效回头查opatch lsinventory。4. 打这个补丁最容易翻车的几个地方4.1 OPatch 版本太低导致 apply 直接失败现象opatch apply报OPatch failed with error code 73或提示The opatch component is not installed。原因11.2.0.3 自带的 OPatch 版本太老不认这个 PSU 的补丁格式。解决先下载对应版本的 OPatch替换$ORACLE_HOME/OPatch和$GRID_HOME/OPatch再重新 apply。替换前记得备份旧 OPatch。4.2 GI 和 DB 补丁顺序颠倒导致集群资源异常现象先打 DB 后打 GI重启后crsctl stat res -t里ora.asm或ora.database显示INTERMEDIATE或OFFLINE。原因GI 层二进制和 DB 层不一致CRS 无法正确拉起资源。解决严格按 GI 先、DB 后的顺序重打或者回滚 DB 层补丁后重新按顺序来。回滚用opatch rollback -id 20996944。4.3 catbundle.sql 执行报 ORA-04063 或 ORA-00904现象跑catbundle.sql psu apply时报对象无效或视图不存在。原因DB 层二进制补丁没打全或者$ORACLE_HOME/rdbms/admin下的脚本被旧版本覆盖。解决确认opatch lsinventory里 DB 层补丁已生效再检查catbundle.sql文件时间戳必要时从补丁目录重新拷贝。4.4 root.sh 跑完 CRS 起不来现象root.sh执行完提示成功但crsctl stat res -t报CRS-4535或CRS-4000。原因oraInventory权限不对或者/etc/oraInst.loc指向了错误的 inventory 路径。解决检查/etc/oraInst.loc里的inventory_loc是否和实际一致权限设为grid:oinstall 775再重跑root.sh。4.5 补丁打完版本号没变现象opatch lsinventory显示补丁已应用但v$version还是旧版本。原因数据库实例没重启或者catbundle.sql没跑。解决重启数据库实例确认dba_registry_history里有 11.2.0.3.15 记录。如果还没有手动跑catbundle.sql。5. 补丁后的验证技巧和长期维护习惯打完补丁不算完验证才是收尾。我一般会做三层验证第一层看opatch lsinventory确认二进制补丁在第二层看dba_registry_history确认数据字典更新第三层跑一个业务 SQL 确认功能正常。三层都过才算真正打完。-- 三层验证的 SQL 片段 -- 1. 二进制层 select * from v$version; -- 2. 数据字典层 select action, version, status, action_time from dba_registry_history order by action_time desc; -- 3. 功能层跑一个业务查询 select count(*) from 你的业务表 where rownum 10;dba_registry_history里如果有多条记录看最新的那条。action_time能帮你确认是不是这次打的。功能层查询随便找个业务表能正常返回就说明基本没问题。长期维护上11.2.0.3 这个版本已经不再有新的 PSU.15就是终点。我的习惯是打完这个补丁后把opatch lsinventory和dba_registry_history的输出存档下次接手的人一看就知道环境状态。另外老环境的oraInst.loc和OPatch目录单独备份一份换人维护时能省很多事。补丁本身不难难的是老版本环境里那些说不清的依赖和顺序按 GI 先 DB 后、OPatch 先升、catbundle 收尾这三步走基本不会出大问题。希望帮到你。本文还有配套的精品资源点击获取
