简介本资源为 Oracle 11.2.0.3 版本最后一个包含数据库组件的 GIGrid InfrastructurePSU 补丁包版本号 .15对应补丁编号 p20996944适用于 Linux x86-64 平台。面向需要维护 Oracle 集群与数据库环境、进行安全加固与稳定性升级的 DBA 及运维人员可解决集群软件、ASM、OCR 与 Voting Disks 等核心组件的已知缺陷与安全问题。压缩包为 zip 格式整体约 599.65MB内含 README 说明文档、PatchSearch.xml 与 bundle.xml 等 OPatch 元数据文件以及 ATP_lfp 和若干独立补丁编号目录便于按官方流程完成预检查、应用与后处理。目前已有 400 人学习下载适合作为 11.2.0.3 环境收尾维护的补丁参考帮助读者掌握补丁组成结构、依赖关系与安装验证要点提升系统安全性与运行效率。1. 为什么我还在给 Oracle 11.2.0.3 打 GI PSU一次版本选择的翻车记录上周帮一个朋友处理一套老库Oracle 11.2.0.3 的 RAC两节点跑在一个很旧的 Linux x86-64 环境上。他问我能不能顺手把 GI 和 DB 的 PSU 一起升一下我第一反应是“这版本还有人用”结果登上去一看opatch lsinventory里补丁列表干净得像刚装完连最基础的 PSU 都没打。他这套环境是某公司内部一个模拟项目X的测试库平时没人管但最近要做数据迁移验证必须先把补丁基线对齐。Oracle 11.2.0.3 这个版本很特殊它是 11g 里最后一个支持直接打 GI PSU 的版本线再往后 11.2.0.4 的补丁策略就变了。而.15这个 PSU对应补丁号 p20996944是 11.2.0.3 的最后一个 GI PSU包含 DB 部分也就是说打完这一个补丁GI 和 DB 的补丁就都到位了。很多人卡在“到底先打 GI 还是先打 DB”“要不要停库”“opatch 版本够不够”这几个问题上装不好轻则补丁冲突重则集群起不来。这篇就按我实际操作的顺序把环境、下载、安装、配置、验证和排错完整走一遍适合还在维护 11.2.0.3 的运维也适合第一次接触 GI PSU 的开发者照着复现。2. 环境准备版本、依赖和 opatch 的硬性门槛2.1 确认 GI 和 DB 的当前版本打补丁前第一件事不是下载是确认你现在的版本到底是不是 11.2.0.3以及 GI 和 DB 的 home 路径。很多人把 GI 和 DB 装在同一台机器但不同 ORACLE_HOME补丁要分别打顺序不能乱。# 查看 GI 版本注意用 grid 用户执行 su - grid $ORACLE_HOME/opatch/opatch lsinventory -detail | head -30 # 查看 DB 版本用 oracle 用户执行 su - oracle $ORACLE_HOME/opatch/opatch lsinventory -detail | head -30逻辑说明lsinventory会列出当前 ORACLE_HOME 下已安装的补丁和组件版本。重点看两处一是Oracle Database 11g Release 11.2.0.3.0这行确认基础版本二是Patch 20996944是否已经存在。如果 GI 和 DB 的 home 是分开的两个用户都要查。参数-detail会展开组件列表不加也能看补丁号但加了好排查冲突。常见做法是先把两个 home 的opatch版本都升到最新11.2.0.3 至少需要 opatch 11.2.0.3.6 以上否则打 PSU 时会报 “OPatch version not supported”。opatch 的升级包在 Oracle 支持站点上单独下载替换$ORACLE_HOME/OPatch目录即可替换前先备份原目录。2.2 检查系统依赖和空间GI PSU 对系统包有依赖尤其是libaio、compat-libstdc这些。我一般会先跑一遍cluvfy或者手动确认关键包。# 检查关键依赖包不同 Linux 发行版包名略有差异 rpm -qa | grep -E libaio|libstdc|compat-libcap|make|binutils|gcc # 检查 GI 和 DB home 的可用空间PSU 解压后大概 1.5G 左右 df -h $GRID_HOME $ORACLE_HOME /tmp逻辑说明rpm -qa列出已安装包缺libaio会导致集群启动时报 “error while loading shared libraries”。df -h看三个路径GI home、DB home 和/tmp。/tmp至少留 1Gopatch 解压和日志会写这里。如果/tmp空间不够可以设置TMPDIR环境变量指向大分区但要在打补丁前 export别中途改。提示如果 GI 和 DB 在同一台机器两个 home 的补丁要分别打但 GI 必须先打因为 GI 的补丁会更新集群warehouseDB 补丁依赖 GI 的版本状态。2.3 下载 p20996944 补丁包补丁包文件名是p20996944_112030_Linux-x86-64.zip这是 11.2.0.3 的 GI PSU .15 版本包含 DB 部分。下载后先校验文件完整性再解压。# 上传到 /u01/soft 目录校验 zip 完整性 cd /u01/soft unzip -t p20996944_112030_Linux-x86-64.zip # 解压到独立目录不要直接解到 ORACLE_HOME mkdir -p /u01/soft/20996944 unzip p20996944_112030_Linux-x86-64.zip -d /u01/soft/20996944 ls /u01/soft/20996944逻辑说明unzip -t只测试不解压确认 zip 没损坏。解压后目录里会有README.html、etc/、files/等README.html一定要看里面写了本次 PSU 的前置补丁和已知问题。不要直接把 zip 解到$ORACLE_HOMEopatch 需要从独立目录读取补丁元数据解错位置会导致opatch apply找不到补丁。3. 打 GI PSU从停集群到 opatch apply 的完整命令3.1 停集群和 DB 的顺序打 GI PSU 必须停集群但停的顺序有讲究。我一般按“先停 DB 实例再停集群最后停 GI 栈”的顺序来避免资源残留。# 1. 停 DB 实例用 oracle 用户 su - oracle srvctl stop database -d db_name -o immediate # 2. 停集群资源用 grid 用户 su - grid crsctl stop crs # 3. 确认所有进程已停 ps -ef | grep -E ora_|crs_|asm_ | grep -v grep逻辑说明srvctl stop database会停掉所有实例-o immediate相当于 shutdown immediate比 abort 安全。crsctl stop crs停掉整个集群栈包括 ASM 和监听。最后用ps确认没有残留的ora_进程如果有说明某个资源没停干净强行打补丁会报 “resource busy”。常见做法是等 30 秒再确认一次ASM 的卸载有时会慢。3.2 用 opatch 打 GI 补丁GI 补丁要用 grid 用户执行opatch apply的路径指向解压后的补丁目录不是 zip 文件。# 切换到 grid 用户设置环境变量 su - grid export PATH$ORACLE_HOME/OPatch:$PATH cd /u01/soft/20996944/20996944 # 先做冲突检查 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ # 正式打补丁 $ORACLE_HOME/OPatch/opatch apply逻辑说明opatch prereq CheckConflictAgainstOHWithDetail是打补丁前的必做检查它会扫描当前 ORACLE_HOME 里是否有冲突的补丁或组件。如果输出里有 “Conflict” 字样先解决冲突再 apply。opatch apply会交互式确认输入y继续。打完后 opatch 会提示 “OPatch succeeded”但别急着起集群先看日志里有没有 warning。参数说明-ph指定补丁目录./表示当前目录。如果补丁目录层级不对opatch 会报 “Not a valid patch location”。我一般会在 apply 前先cd到补丁目录确认里面有etc/config/inventory.xml这类文件。3.3 打完后更新 GI 的 inventoryGI 补丁打完需要更新 inventory 并确认补丁已注册。# 确认补丁已安装 $ORACLE_HOME/OPatch/opatch lsinventory | grep 20996944 # 如果有多个节点每个节点都要打 # 在节点2上重复 3.1 到 3.2 的步骤逻辑说明lsinventory里出现20996944说明补丁已注册到 GI home。RAC 环境下每个节点的 GI home 都要打不能只打一个节点。如果节点2的 GI home 是共享的那打一次就行但 11.2.0.3 的 GI home 通常是本地的每个节点独立。打完所有节点后再统一启动集群。4. 打 DB PSU和 GI 补丁的先后关系及参数差异4.1 为什么 DB 补丁要在 GI 之后打GI PSU 包含集群warehouse的更新DB PSU 依赖 GI 的版本状态。如果先打 DB 再打 GIGI 的补丁会覆盖部分 DB 的二进制文件导致 DB 补丁失效。我一般按“GI 全部节点打完 → 启动集群 → 再打 DB”的顺序。# 启动集群用 grid 用户 su - grid crsctl start crs # 确认集群状态正常 crsctl stat res -t逻辑说明crsctl start crs启动集群栈crsctl stat res -t列出所有资源状态重点看ora.asm、ora.db_name.db是否 ONLINE。如果 ASM 没起来DB 补丁打完后实例也起不来。常见做法是等crsctl stat res -t里所有资源都变成 ONLINE 再继续别急着打 DB 补丁。4.2 用 opatch 打 DB 补丁DB 补丁用 oracle 用户执行补丁目录和 GI 是同一个但 opatch 会识别当前 ORACLE_HOME 是 DB home。# 切换到 oracle 用户 su - oracle export PATH$ORACLE_HOME/OPatch:$PATH cd /u01/soft/20996944/20996944 # 冲突检查 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./ # 打补丁 $ORACLE_HOME/OPatch/opatch apply逻辑说明DB 补丁的 opatch 命令和 GI 一样但执行用户不同。opatch apply会更新 DB 的二进制文件和 inventory。打完后同样用lsinventory确认20996944出现在 DB home 的补丁列表里。如果 DB home 和 GI home 在同一台机器但不同路径两个 home 的补丁互不影响但都要打。参数说明如果 DB 是 RAC 多实例每个节点的 DB home 都要打但可以滚动打不用一次性全停。我一般先打节点1验证实例能起来再打节点2。滚动打补丁时srvctl stop instance停单个实例打完再srvctl start instance。4.3 执行 datapatch 完成 SQL 层更新opatch apply 只更新二进制SQL 层的补丁要用datapatch完成。11.2.0.3 的 datapatch 在$ORACLE_HOME/OPatch/datapatch。# 确认 DB 实例已启动 srvctl status database -d db_name # 执行 datapatch cd $ORACLE_HOME/OPatch ./datapatch -verbose逻辑说明datapatch -verbose会扫描$ORACLE_HOME/sqlpatch目录下的补丁 SQL并应用到数据库。输出里会显示每个补丁的 apply 状态重点看有没有 “ERROR”。如果报 “datapatch failed”先看$ORACLE_HOME/cfgtoollogs/sqlpatch下的日志。常见做法是 datapatch 前先确认实例是 OPEN 状态MOUNT 状态会报错。5. 避坑与排查5 个我实际踩过的坑5.1 opatch 版本太低导致 apply 直接失败现象opatch apply报 “OPatch version 11.2.0.3.0 is not supported for this patch”补丁根本打不进去。原因11.2.0.3 自带的 opatch 版本太老p20996944 要求 opatch 至少 11.2.0.3.6。解决从支持站点下载最新 opatch 包替换$ORACLE_HOME/OPatch目录。替换前先mv OPatch OPatch_bak替换后opatch version确认。GI 和 DB 两个 home 都要替换。5.2 集群没停干净导致 resource busy现象opatch apply报 “Cannot apply patch because resource is busy” 或 “ORACLE_HOME is in use”。原因某个ora_进程没停或者 ASM 还在挂载状态。解决ps -ef | grep ora_找到残留进程用kill -9强杀然后crsctl stop crs -f强制停集群。如果 ASM 还挂着用asmcmd umount手动卸载。确认ps干净后再 apply。5.3 datapatch 报 “ORA-04021 timeout”现象datapatch -verbose执行到一半报 “ORA-04021: timeout occurred while waiting to lock object”。原因数据库里有其他会话持有锁或者 datapatch 执行时实例负载太高。解决先shutdown immediate再startup确保没有其他会话连接。如果还报检查dba_registry_sqlpatch视图里是否有失败的补丁记录用datapatch -rollback回滚后重试。我一般会在 datapatch 前把实例重启一次避免锁冲突。5.4 GI 补丁打完集群起不来现象crsctl start crs后crsctl stat res -t显示ora.asm是 OFFLINE或者ora.db.db起不来。原因GI 补丁更新了集群warehouse但某些节点的 inventory 没同步或者 OCR 备份没更新。解决先看$GRID_HOME/log/hostname/alerthostname.log找 “error” 关键字。如果是 OCR 问题用ocrcheck确认 OCR 状态。常见做法是打完 GI 补丁后先crsctl stop crs再crsctl start crs重启一次让集群重新加载补丁后的二进制。5.5 补丁打完后 DB 实例起不来现象srvctl start database报 “ORA-01078: failure in processing system parameters” 或 “ORA-01565: error in identifying file”。原因DB 补丁更新了二进制但 spfile 或密码文件没同步或者datapatch没执行完。解决先确认datapatch是否成功再看$ORACLE_HOME/dbs下的 spfile 和密码文件是否存在。如果 spfile 丢失用create spfile from pfile重建。我一般会在打 DB 补丁前备份$ORACLE_HOME/dbs目录出问题直接恢复。6. 装完怎么验证三个必须跑一遍的检查补丁打完不是看 opatch 输出 “succeeded” 就完事我一般会跑三个检查确认 GI 和 DB 都真正生效。第一个检查是opatch lsinventory的补丁列表。GI 和 DB 两个 home 都要查确认20996944出现在Patch列表里并且Oracle Database 11g Release 11.2.0.3.0的组件版本有更新。如果只看到补丁号但组件版本没变说明补丁没完全 apply需要重新跑opatch apply。# GI home 检查 su - grid $ORACLE_HOME/OPatch/opatch lsinventory | grep -A2 20996944 # DB home 检查 su - oracle $ORACLE_HOME/OPatch/opatch lsinventory | grep -A2 20996944第二个检查是datapatch的 SQL 层状态。连到数据库里查dba_registry_sqlpatch视图确认补丁的STATUS是SUCCESS。-- 用 sysdba 登录后执行 set lines 200 col patch_id format 99999999 col status format a10 col action format a10 select patch_id, status, action, description from dba_registry_sqlpatch order by patch_id;逻辑说明dba_registry_sqlpatch记录每个 SQL 补丁的应用状态。STATUS为SUCCESS表示 SQL 层更新完成ACTION为APPLY表示是应用而非回滚。如果STATUS是FAILED需要看$ORACLE_HOME/cfgtoollogs/sqlpatch下的日志找到具体报错再处理。第三个检查是集群和实例的启动状态。crsctl stat res -t确认所有资源 ONLINEsrvctl status database -d db_name确认实例在运行。我一般还会跑一个简单的select count(*) from dba_objects;确认数据库能正常查询避免补丁后出现数据字典损坏。# 集群资源状态 su - grid crsctl stat res -t # 实例状态 su - oracle srvctl status database -d db_name # 简单查询验证 sqlplus / as sysdba EOF select count(*) from dba_objects; exit EOF这三个检查跑完基本能确认 GI PSU .15 已经完整落地。从那以后我每次打完补丁都会强制走一遍lsinventorydba_registry_sqlpatchcrsctl stat res -t这三步少一步都可能漏掉 SQL 层没生效的玄学问题。希望帮到你。本文还有配套的精品资源点击获取