简介Oracle 11.2.0.3的GIGrid InfrastructurePSU补丁包、版本.15适用于Linux x86-64平台是数据库管理员维护Oracle高可用环境的稀缺资源。该补丁对应官方编号20996944同时覆盖GI与DB组件对集群管理、ASM、OCR及Voting Disk等核心模块带来安全修复与性能改进适合需要将11.2.0.3环境更新到最终补丁层级的运维人员。压缩包为zip格式大小约599.65MB包内主要包含HTML/文本说明文档、OPatch使用的PatchSearch.xml及bundle.xml等配置便于安装前核对补丁依赖与应用顺序。目前已有400人学习下载属于Oracle老版本维护中较受关注的补丁集合。获取后可获得完整的补丁文件、官方说明与元数据帮助规避安全漏洞并提升集群稳定性安装时可结合自身环境做好备份与预检查。1. 还在维护 11.2.0.3 的人为什么必须正视这个补丁包仍在生产环境维护 Oracle 11.2.0.3 RAC 的 DBA 都明白一个事实升级申请不是被业务部门压着就是被预算卡着而安全审计的漏洞清单却每个月都在变。能做的只有一件事——把当前版本能打的补丁全部打完而这个p20996944_112030_Linux-x86-64.zip就是 Oracle 11.2.0.3 上的最后一个 GI包含 DB的 PSU 补丁版本号走到 .15 彻底停更。换句话说如果你现在还在跑 11.2.0.3且短期无法迁移这篇文章讨论的就是你手里最后一张安全牌。接下来我从包结构、安装流程、验证手段到翻车记录把这个包讲透。2. 拆解 p20996944_112030GI 与 DB patch 的边界在哪里2.1 GI PSU 与 DB PSU一张补丁包的两种身份很多刚接触 Oracle 补丁体系的运维会混淆 GI 与 DB 的概念。GI 是 Grid Infrastructure承载集群件、ASM 实例、CSS 守护进程DB 则是数据库内核本身。PSUPatch Set Update是 Oracle 在一个大版本内发布的增量补丁集合既修安全漏洞也修功能性 bug。本次标题里的这个包同时覆盖 GI 和 DB意味着解压后的内容里既有集群组件的二进制修复也有数据库内核的修复文件。这个“包含”字眼在实际操作中有两层含义。第一层这个 zip 包内同时放了两套 patch 文件分别对应 GI home 和 DB home第二层这两套修复必须在两个不同的 ORACLE_HOME 里分别应用不能指望一条命令同时搞定。常见做法是先打 GI home再打 DB home顺序不能反。2.2 补丁包命名与检索规律补丁包的文件名有固定格式p补丁号_版本号_平台.zip。其中 20996944 是 MOS 上的补丁编号也是检索一切相关文档的关键字112030 表示这是 11.2.0.3 版本专用Linux-x86-64 限定操作系统与芯片架构x86_64 的 Linux 服务器只能选这个变体不能拿 Solaris 或 AIX 的包替代。末尾的 .15 指的是该版本的第 15 个 PSU 序列序号越靠后包含的修复越多。在 MOS 上检索时直接输入补丁号即可命中下载页而不要去翻 11.2.0.3 的总补丁列表。下载页里通常还附带 README 和安装说明它们是比任何第三方攻略都权威的指导书我后面讲的每一步第一参照物都是那个 README。2.3 一个容易踩的口头理解误区“包含 DB”四个字容易让新手误以为只需在 GI home 上跑一次 opatch applyDB 就自动完成修复了。但实际安装时必须分别在两个 home 上各自执行 apply。它们对 ORACLE_HOME 的判断依据是当前用户的环境变量而不是 zip 包自身的位置。也就是说同一个 zip 包可以被 grid 用户引用一次、被 oracle 用户再引用一次两次都合法但打进去的对象完全不同。所以规范的操作顺序是先以 grid 用户身份在 GI home 打 GI 部分再切换到 oracle 用户环境在 DB home 打 DB 部分。如果你跳过第二步只看 GI 的版本号变成 .15 就觉得完事那数据库内核的安全漏洞一个都没补上审计依然不会通过。3. 打补丁前站OPatch 版本、备份与冲突检查必做清单3.1 升级 OPatch比所有检查都先一步11.2.0.3 时代自带的 OPatch 版本往往偏低直接对高版本 PSU 执行 apply 会报版本不满足或 OPATCH-7200 错误。老 DBA 的习惯是先把 OPatch 升到 MOS 上对应 11.2 的最新版本再动补丁包。这个步骤虽然朴素却能省下大量排查时间。以我自己的经历某个库就是在第一次 apply 时被 OPatch 版本卡住浪费了一个完整的维护窗口。升级流程是下载 OPatch 压缩包先备份旧目录再把新目录替换过去。注意环境变量必须指到当前实际使用的 ORACLE_HOME否则替换错目录是常有的事。# 以 grid 用户备份并升级 GI home 下的 OPatch cd $ORACLE_HOME mv OPatch OPatch_$(date %Y%m%d_%H%M%S) unzip -q /stage/p6880880_latest.zip -d $ORACLE_HOME chown -R grid:oinstall $ORACLE_HOME/OPatch # 完成后确认版本 $ORACLE_HOME/OPatch/opatch version这里的 p6880880 是 OPatch 工具在 MOS 上的通用补丁号下载时同样需要选择与 11.2 版本匹配的最新迭代。替换后注意属主和权限目录属主必须与 home 属主一致否则后续执行会出现权限拒绝的诡异现象。升级完 GI home 的 OPatch 后DB home 下也要重复一遍同样的操作两个 home 的工具版本最好保持一致。3.2 备份盘点OCR、GI home 和数据库打补丁前不做备份等于把系统安全交给运气。对 11.2.0.3 RAC 来说至少需要三条备份线OCR / OLM 配置、GI home 目录、数据库本身。OCR 保存着集群和 ASM 的核心配置一旦补丁过程中发生配置损坏没有导出文件几乎是无法手工重建的。导出命令在 root 或 grid 用户下执行都可以但输出文件要放到共享存储之外。# 以 root 导出 OCR 配置 $GI_HOME/bin/ocrconfig -export /backup/ocr_$(date %Y%m%d_%H%M%S).bak # 检查导出结果 $GI_HOME/bin/ocrcheck数据库层面如果条件允许做一次完整的 RMAN 全备份最稳妥如果时间窗口不够至少要把控制文件、spfile 和最新的归档日志单独备份出来。GI home 的目录备份用 tar 打包到本地磁盘即可注意要排除监听和日志目录下的临时文件否则包会异常膨胀。备份的本质是给操作上后悔药宁可多花半小时不要在故障后花一晚上恢复。3.3 冲突与预检不想在维护窗口里翻车就多做两步补丁冲突是最常见却又最容易被忽略的拦截条件。如果你的环境里此前打过某个 interim patch一次性小补丁而 PSU 的修复内容与之重叠apply 会直接拒绝执行并提示冲突文件。解决的方式是先用 opatch 做预检把冲突消灭在维护窗口之前。11.2.0.3 的 OPatch 支持 prereq 参数可以对比软件仓库中已有的补丁。# 解压补丁包后的预检注意 phBaseDir 指向的是解压后的实际补丁目录 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /stage/20996944/20996944 # 也可以直接做 dryRun模拟 apply 但不实际写入 $ORACLE_HOME/OPatch/opatch apply -dryRun -phBaseDir /stage/20996944/20996944两条命令的差别在于prereq 只做冲突检查dryRun 会执行更完整的 apply 前置模拟包括空间检查、二进制可写性和依赖关系的校验。遇到空间不足OPatch 会准确报出哪个目录缺多少 M比你手工统计快得多。这两种预检都要在 grid 和 oracle 两个用户的 home 下分别跑一遍缺一个环境维护窗口内就会多一次心跳加速。4. 实战安装从解压到 opatch apply 的标准流程4.1 解压补丁包与生成 OCM 响应文件拿到 zip 后先不要急着在任意目录解压。规范做法是把它放到一个专门的补丁目录例如/stage解压后找到真正的补丁子目录。11.2 的补丁包解压后会有两级目录结构外层是补丁号目录内层才是 opatch 真正读取的 patch 目录很多第一次操作的人把路径指错导致 opatch 报“提供的路径不是有效补丁”。# 在 grid 用户环境下解压 mkdir -p /stage/20996944 unzip -q p20996944_112030_Linux-x86-64.zip -d /stage/20996944 # 查看解压后的目录结构 ls -la /stage/20996944/20996944解压后必须确认目录内包含etc、files等标准结构并存在README.txt。这个目录就是后面所有 opatch 命令的-phBaseDir指向对象。OCM 响应文件是 Oracle 配置管理器的应答文件用于替代交互式输入。标准做法是从任一已存在的同类文件复制或通过 MOS 下载模板填上站点信息即可apply 时用-ocmrf参数引用它。4.2 GI Home 打补丁以 grid 用户执行第一个 applyGI 部分的打补丁是整个维护窗口的核心步骤。执行前要确认节点间的补丁状态差异Opatch 会自动识别 RAC 环境但如果你打算滚动执行还必须先看 README 是否支持 rolling。11.2.0.3 的 GI PSU 通常支持滚动但包含 DB 的整包升级不建议滚动因为 DB 部分的 apply 不支持滚动模式硬要拆开会造成两节点补丁级别暂时不一致给后续问题排查增加变量。# 以 grid 用户执行切换到 GI home 的环境变量 export ORACLE_HOME/u01/app/11.2.0/grid export PATH$ORACLE_HOME/bin:$PATH cd $ORACLE_HOME/OPatch ./opatch apply -ocmrf /stage/ocm.rsp -phBaseDir /stage/20996944/20996944apply 执行期间OPatch 会依次读取补丁文件、克隆目录、更新 inventory耗时通常在 20 到 40 分钟之间取决于存储性能。期间不要并行执行其他运维操作尤其不要手动启停集群服务。如果补丁内容涉及 ACFS 驱动更新OPatch 会输出提示要求你用 root 执行生成的脚本此时按提示切换用户执行即可不要跳过。4.3 DB Home 打补丁同一个 zip 的第二站GI home 打完并确认无误后切换到 oracle 用户把 ORACLE_HOME 指向数据库 home再用同一个 zip 包执行第二次 apply。这一次针对的是数据库内核的修复文件。执行前同样先做一次 dryRun确认 DB home 下的 OPatch 版本与 GI home 一致然后进入正式 apply。# 以 oracle 用户执行ORACLE_HOME 切换为数据库 home export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch apply -ocmrf /stage/ocm.rsp -phBaseDir /stage/20996944/20996944这次 apply 完成后数据库 home 的 opatch lsinventory 输出里就能看到对应 PSU 条目。注意这里不会立即改变数据库字典内的版本信息还需要最后一步 datapatch。如果你只做到 lsinventory 显示 .15 就觉得收工后遗症是数据字典里的REGISTRY_SQLPATCH仍是旧版本后续业务若触发了已修复的 bug问题依旧会出现。4.4 运行 datapatch把版本号真正落进数据字典datapatch 是 11.2.0.3 之后负责把补丁的 SQL 部分写入数据库的工具它读取补丁清单中的postinstall脚本在实例上执行 SQL 变更。这一步必须在数据库处于 open 或至少 mount 状态下执行且 ORACLE_SID 必须指向正被维护的实例。常见做法是在两节点的第一节点上执行它会自动把 SQL 应用到所有实例相关的字典变更。# 以 oracle 用户执行先确认 SID 正确 export ORACLE_SIDORCL cd $ORACLE_HOME/OPatch ./datapatch -verbosedatapatch 执行完毕后会输出每一条 SQL 的应用状态若有失败项会打印具体语句和错误信息。这时不要直接重跑先看错误是权限问题还是对象已存在前者需要检查执行用户权限后者通常意味着之前已部分应用过可以直接跳过。全部成功后数据库的版本号才算真正走到了 .15。5. 打补丁避坑五条真实环境的翻车记录5.1 OPatch 版本不满足apply 第一轮就失败现象执行 opatch apply 后立即报错提示 OPatch 版本过低或与补丁要求的最低版本不匹配整个维护窗口被迫推迟到下一轮。原因补丁包 release 时间晚于当前 OPatch 工具版本OPatch 本身不具备向后兼容性。解决在维护窗口前提前完成升级并把opatch version的输出与补丁 README 中的最低版本要求逐字核对。我曾经因为在两节点只升级了其中一个的 OPatch导致第二个节点 apply 报错白白多花了一个小时。5.2 打完 GI 补丁后 OCR 不一致告警现象全部 apply 成功后crsctl stat res -t显示部分资源异常ocrcheck报告配置与二进制版本不一致。原因GI PSU 在节点间轮流应用时若某一个节点提前重启了集群服务而另一个节点还没打补丁会导致 OCR 记录的版本信息和实际二进制对不上。解决严格按 README 的步骤顺序执行若非必要不要做滚动升级打完所有节点后按规范依次重启集群让 OCR 同步新版本。重启前务必确认所有节点的 patch 都已应用完毕。5.3 datapatch 连接实例失败报 ORACLE_SID 错误现象执行 datapatch 时提示无法连接到实例或找不到 SID但数据库明明在运行。原因当前 shell 的 ORACLE_SID 与实测实例名不一致或数据库处于 restricted 模式。解决先用ps -ef | grep smon查看实际实例名再 export 正确 SID若实例是 restricted用 sqlplus 登录执行alter system disable restricted session;后再运行 datapatch。这个小坑能让熟手都怀疑人生但它就是环境变量的问题跟补丁本身无关。5.4 apply 后 lsinventory 仍是 .14补丁像没打一样现象apply 全程无报错但 lsinventory 输出里看不到新 PSU 条目查opatch lsinventory -detail才发现 apply 作用在了一个空的临时目录。原因-phBaseDir指向了解压后的外层目录而不是内层真正的补丁目录OPatch 静默地读取了另一个子目录中的补丁定义。解决apply 前用ls /stage/20996944/20996944确认存在 files 目录再执行。这个检查值不值钱值它避免了一次“成功”的假操作。5.5 数据库补丁级别与 GI 不一致审计又被卡现象GI home 已显示 .15但 v$version 和数据字典仍是旧版本。原因只执行了 GI home 的 apply跳过了 DB home 的第二次 apply 和 datapatch。解决把 4.3 和 4.4 当成不可分割的整体任何一步缺失都会导致这种半吊子状态。这类问题在审计阶段最头疼因为报表里只会写“数据库版本未达标”排查起来却要翻两个 home 的 inventory。6. 打完补丁别急着收工datapatch 与 SQL 变更的验证技巧6.1 版本三板斧别只信一个输出验证补丁是否成功不能只看 opatch lsinventory 一个结果三处输出必须同时确认。第一处是 GI home 的 lsinventory第二处是 DB home 的 lsinventory第三处是数据库字典内的版本记录。只看前两个无法确认 SQL 变更是否已生效只看第三个无法确认二进制是否已替换。-- 检查数据字典内的补丁记录 SELECT PATCH_ID, PATCH_TYPE, ACTION, STATUS, ACTION_TIME FROM DBA_REGISTRY_SQLPATCH WHERE PATCH_ID 20996944 ORDER BY ACTION_TIME;这条 SQL 是判断 SQL 变更落地的最终证据。如果返回多条记录注意看 ACTION 字段APPLY 且 STATUS 为 SUCCESS 才是正确状态。若有 FAILED 记录就要翻看 datapatch 的输出日志定位具体是哪条脚本没跑完。6.2 巡检基线把补丁状态写进日常打完补丁后的第一周我建议每天看一次 alert 日志重点抓 ORA-600 和 ORA-7445 两类内部错误。11.2.0.3 这种快被 Oracle 遗忘的版本新补丁引入的问题虽然少但并非不可能。把以下查询存成脚本放进巡检清单里每次版本变更后对比一次比临上线才查靠谱得多。-- 对比两个 home 的补丁级别 SELECT GI, PATCH_ID, ACTION, STATUS FROM DBA_REGISTRY_SQLPATCH UNION ALL SELECT DB, TO_NUMBER(REGEXP_SUBSTR(comments, [0-9])), INSTALLED, SUCCESS FROM v$version WHERE banner LIKE Oracle Database 11g%;6.3 我的习惯一次补丁一次档案这些年打过的补丁不少我养成的最实用习惯是每次 patch 后把三个版本的输出截图或存文本归档起名带上补丁号和日期放进共享目录。等审计来查时翻出文件夹就能把整个链讲清楚。这个习惯在 11.2.0.3 这种老库上尤其重要因为补丁路径不可复现查一次少一次。希望你也能在动手前把归档目录建好打完顺手存个档——老库维护细节决定生死希望这些经验能帮到你少走一趟弯路。本文还有配套的精品资源点击获取