Oracle 11.2.0.3 终极PSU .15：GI与DB合并补丁实战指南

简介本资源为 Oracle 11.2.0.3 平台最后一版 GIGrid InfrastructurePSU 补丁包版本号 .15同时包含数据库组件更新面向仍在使用该经典版本、需要完成集群与数据库安全加固的 DBA 与运维工程师。补丁以 zip 形式分发压缩包约 599.65MB内含 README 说明文档、OPatch 所需的 PatchSearch.xml 与 bundle.xml 元数据清单以及若干独立补丁编号目录便于按官方流程完成预检查、应用与后处理。该 PSU 汇集了自上一版本以来的安全修复、性能优化与已知问题解决方案覆盖集群软件、ASM、OCR 与 Voting Disk 等关键组件可帮助读者在无法升级大版本的前提下补齐补丁、提升系统稳定性与高可用能力。目前已有 399 人学习下载适合需要按官方指导完成补丁验证与部署的读者参考使用。1. 为什么 11.2.0.3 的 .15 PSU 是很多老 DBA 的最后一站如果你手上还跑着 Oracle 11.2.0.3 的 RAC 或者单实例而且 GI 和 DB 都还没升到 11.2.0.4那你大概率已经意识到一件事11.2.0.3 的补丁窗口早就关了能拿到的最后一个 GI DB 合并 PSU 就是版本 .15对应补丁号 p20996944Linux x86-64 平台的文件名是p20996944_112030_Linux-x86-64.zip。这个包不是普通的 DB PSU它同时覆盖 Grid Infrastructure 和 Database 两个 Home也就是说你打完这一个包CRS、ASM、RDBMS 二进制层面的安全修复和关键 bug 修复一次性到位。适合谁适合那些因为业务绑定、认证兼容、存储过程依赖等原因暂时不能上 11.2.0.4 或 12c 的环境尤其是还在用 ASM 管理数据文件、监听器跑在 GI Home 下的老系统。我见过太多人卡在“最后一个补丁到底能不能打、怎么打、打完会不会起不来”这三个问题上这篇就把这个包从解压到 opatch 到回退的完整链路拆开讲。2. 补丁包结构与 OPatch 前置检查别急着 unzip2.1 这个 zip 里到底装了什么拿到p20996944_112030_Linux-x86-64.zip之后先别急着往服务器上传。这个包的结构和普通 DB PSU 不一样它里面通常包含两个子目录一个对应 GI 的补丁目录一个对应 DB 的补丁目录外加一个 README.html 和 bundle.xml。README 里会明确写出当前版本号、需要的前置补丁、以及是否支持 rolling 还是只能 all-node 停机。我一般会先在本地解压看一眼目录树确认里面有没有etc/config动作脚本因为 GI 补丁的 opatch auto 流程依赖这些动作来更新 CRS 栈。# 本地解压后查看顶层结构确认 GI 和 DB 两个子目录都在 unzip -l p20996944_112030_Linux-x86-64.zip | head -40 # 输出里重点看是否有 20996944/ 和 20996944_GI/ 这类命名逻辑说明unzip -l只列内容不落盘避免在跳板机上产生一堆临时文件。参数上注意head -40只是看开头真正要确认的是有没有README.html和bundle.xml这两个文件决定了后面用 opatch auto 还是手动 apply。2.2 OPatch 版本不够是最常见的翻车点11.2.0.3 自带的 OPatch 通常是 11.2.0.3.x 的老版本而 .15 PSU 要求 OPatch 至少是 11.2.0.3.12 以上。如果你直接跑opatch apply大概率会报 “OPatch version not compatible” 或者 “prereq check failed”。血泪经验是先分别检查 GI Home 和 DB Home 的 OPatch 版本两个 Home 都要升不能只升一个。# 分别进入 GI 和 DB 的 ORACLE_HOME 检查 OPatch 版本 $GI_HOME/OPatch/opatch version $DB_HOME/OPatch/opatch version # 如果低于要求下载对应版本的 OPatch p6880880 并替换 # 替换前先备份旧目录 mv $GI_HOME/OPatch $GI_HOME/OPatch.bak unzip -q p6880880_112000_Linux-x86-64.zip -d $GI_HOME chown -R grid:oinstall $GI_HOME/OPatch逻辑说明opatch version输出里会带具体 build 号对照 README 里的最低要求。替换 OPatch 时一定要用chown把属主改回 grid 或 oracle否则 opatch auto 会因为没有权限写 inventory 而中途退出。参数上-d指定解压目标目录不要解压到/tmp再 cp容易丢软链接。2.3 用 opatch prereq 做一次 dry run正式打之前强烈建议跑一次opatch prereq CheckConflictAgainstOHWithDetail这一步不修改任何东西只告诉你当前 Home 里有没有冲突的补丁或者被覆盖的文件。GI 侧还要额外检查crsctl query crs activeversion和olsnodes -n确认所有节点都在线且版本一致。# 在 GI Home 下做冲突检查 cd $GI_HOME $GI_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./20996944 # 检查集群节点状态 crsctl query crs activeversion olsnodes -n逻辑说明-phBaseDir指向解压出来的补丁目录不是 zip 文件本身。如果这一步报出冲突补丁号先去 My Oracle Support 查该补丁是否已被 .15 包含包含的话用opatch rollback先回退再打不要强行-force否则 inventory 会乱。3. GI 与 DB 的 opatch auto 实操顺序错了就起不来3.1 为什么必须先 GI 后 DBGI Home 里跑着 CRS、ASM 和监听器DB Home 里跑着实例。opatch auto 的设计逻辑是先把 GI 栈停掉、打补丁、再拉起然后处理 DB Home。如果你反过来先打 DBGI 侧的 ASM 实例还在跑DB 补丁里的某些库文件替换会失败或者打完后实例起不来因为 ASM 版本不匹配。我一般会按这个顺序停应用 → 停 DB 实例 → 用 opatch auto 打 GI → 确认 CRS 正常 → 再用 opatch auto 打 DB。# 以 root 执行 opatch auto指定 GI 和 DB 两个 Home # 先打 GI $GI_HOME/OPatch/opatch auto /tmp/20996944 -oh $GI_HOME # 确认 CRS 起来后再打 DB $DB_HOME/OPatch/opatch auto /tmp/20996944 -oh $DB_HOME逻辑说明opatch auto第一个参数是补丁解压后的根目录-oh明确指定当前要处理的 Oracle Home。如果不加-ohopatch 会尝试自动识别在多 Home 环境下容易认错。执行过程中它会自动停 CRS、打补丁、再启动全程看屏幕输出出现 “OPatch Auto successful” 才算完。3.2 手动 apply 的适用场景与命令有些环境不允许 opatch auto 自动停集群比如核心库要求最短停机窗口这时候就得手动来。手动流程是先停 DB 实例和监听 → 停 CRS → 在 GI Home 下opatch apply→ 启动 CRS → 在 DB Home 下opatch apply→ 启动实例。手动方式更可控但每一步都要自己确认状态。# 手动打 GI 补丁 crsctl stop crs -f cd $GI_HOME $GI_HOME/OPatch/opatch apply /tmp/20996944/20996944 # 打完启动 CRS crsctl start crs crsctl check crs # 手动打 DB 补丁 srvctl stop database -d ORCL cd $DB_HOME $DB_HOME/OPatch/opatch apply /tmp/20996944/20996944 srvctl start database -d ORCL逻辑说明crsctl stop crs -f是强制停生产环境建议先crsctl stop crs不加-f等它优雅停。opatch apply后面的路径要精确到补丁子目录不是根目录。打完 GI 后必须crsctl check crs看到三个服务都 online 才能继续 DB 侧。3.3 打完补丁后的版本验证补丁打完不代表完事必须验证 inventory 和实际二进制版本。opatch lsinventory会列出已安装的补丁号opatch lspatches更直观直接显示补丁号和描述。GI 侧还要用crsctl query crs softwareversion确认 CRS 版本已经更新。# 验证 GI 和 DB 的补丁列表 $GI_HOME/OPatch/opatch lspatches $DB_HOME/OPatch/opatch lspatches # 确认 CRS 软件版本 crsctl query crs softwareversion crsctl query crs activeversion逻辑说明lspatches输出里应该能看到 20996944 这个号。如果 GI 侧看不到说明 opatch auto 中途失败但没报错需要查$GI_HOME/cfgtoollogs/opatch/下的日志。softwareversion和activeversion不一致时说明补丁只打了一半别重启节点。4. 避坑与排查那些让你半夜被叫醒的细节4.1 现象opatch auto 卡在 “Inventory” 不动原因GI Home 的 inventory 目录属主被改过或者中央 inventory 指向了不存在的路径。常见于之前手动替换过 OPatch 但没改回属主。解决检查/etc/oraInst.loc里的inventory_loc指向确认该目录存在且 grid 用户可写然后chown -R grid:oinstall整个 inventory 目录重新跑 opatch auto。4.2 现象打完 GI 后 CRS 起不来报 “CRS-4000”原因GI 补丁里的 OCR 或 voting disk 配置在 apply 过程中被覆盖或者 ASM 实例没起来导致 CRS 依赖失败。解决先crsctl start crs -excl -nocrs进独占模式查$GI_HOME/log/host/crsd/crsd.log确认是 OCR 问题还是 ASM 问题。如果是 ASM手动srvctl start asm再crsctl start crs。4.3 现象DB 补丁打完实例启动报 “ORA-12547: TNS:lost contact”原因DB Home 的oracle二进制权限在补丁过程中被重置或者$DB_HOME/bin/oracle的 setuid 位丢了。解决chmod 6751 $DB_HOME/bin/oracle然后chown oracle:oinstall再启动实例。这个坑在 11.2.0.3 的 PSU 里特别常见因为 opatch 替换二进制时不会自动保留 setuid。4.4 现象lspatches 显示补丁已打但应用连不上报 “ORA-01092”原因DB 实例的dbs目录下orapw文件或spfile在补丁过程中被备份后没恢复或者$ORACLE_HOME/rdbms/lib/config.c被覆盖导致内核参数不匹配。解决从备份恢复spfile和orapw然后relink all重新链接 Oracle 二进制。relink all在 11.2.0.3 下要跑 10 到 15 分钟别中途 CtrlC。4.5 现象回退补丁后 GI 无法启动原因回退时只回退了 DB 侧GI 侧的 inventory 还记录着已打补丁导致 CRS 启动时加载了不匹配的库。解决GI 和 DB 必须同时回退顺序是先 DB 后 GI回退命令用opatch rollback -id 20996944回退完同样要relink all并检查crsctl check crs。5. 补丁回退与版本锁定留好后悔药5.1 回退前的快照与备份打补丁之前我习惯做三件事备份$GI_HOME/OPatch和$DB_HOME/OPatch目录、备份inventory目录、记录当前lspatches输出。这三样东西在回退时能救命。尤其是 inventory如果回退过程中 inventory 损坏opatch 会直接不认任何补丁到时候只能重装 GI。# 打补丁前做快照 cp -rp $GI_HOME/OPatch $GI_HOME/OPatch.bak.$(date %Y%m%d) cp -rp $DB_HOME/OPatch $DB_HOME/OPatch.bak.$(date %Y%m%d) $GI_HOME/OPatch/opatch lspatches /tmp/gi_patches_before.txt $DB_HOME/OPatch/opatch lspatches /tmp/db_patches_before.txt逻辑说明cp -rp保留权限和软链接$(date %Y%m%d)加日期后缀方便区分。lspatches输出存到/tmp只是临时正式环境应该放到共享存储或备份服务器上。5.2 回退命令与顺序回退的顺序和打补丁相反先 DB 后 GI。DB 侧回退前先停实例GI 侧回退前先停 CRS。回退命令是opatch rollback -id 20996944执行完同样要relink all。如果回退后实例起不来检查$ORACLE_HOME/bin/oracle的权限和spfile是否还在。# 回退 DB srvctl stop database -d ORCL cd $DB_HOME $DB_HOME/OPatch/opatch rollback -id 20996944 $DB_HOME/bin/relink all # 回退 GI crsctl stop crs -f cd $GI_HOME $GI_HOME/OPatch/opatch rollback -id 20996944 $GI_HOME/bin/relink all crsctl start crs逻辑说明-id后面跟的是补丁号不是补丁目录。relink all必须在回退后执行否则二进制还是旧的。GI 侧relink all要在 CRS 停止状态下跑跑完再启动。5.3 版本锁定与后续升级路径打完 .15 之后11.2.0.3 就没有更新的 PSU 了。如果你后续要升 11.2.0.4 或 12c这个 .15 补丁不会成为障碍但要注意 11.2.0.4 的升级脚本会检查当前补丁级别。我一般会在升级前把lspatches输出存档作为升级前的基线。另外如果环境里有 Data Guard备库也要同步打这个补丁否则主备切换后会出现版本不一致导致 MRP 进程报错。操作命令关键检查点打 GI 补丁opatch auto /tmp/20996944 -oh $GI_HOMEcrsctl check crs 三个服务 online打 DB 补丁opatch auto /tmp/20996944 -oh $DB_HOMEsrvctl status database 实例 running验证opatch lspatches输出包含 20996944回退 DBopatch rollback -id 20996944relink all 后实例能起回退 GIopatch rollback -id 20996944crsctl start crs 无报错从那以后我每次打 GI PSU 都强制走一遍opatch prereq加lspatches存档哪怕再急也不跳过。希望帮到你。本文还有配套的精品资源点击获取