通信对抗原理：加密、跳频与IDS/IPS的防御体系
2026/10/18 10:22:12
简介：本资源为 Oracle 11.2.0.3 版本最后一个 GI（Grid Infrastructure）PSU 补丁包，版本号 .15，同时包含数据库组件，适用于仍在使用该版本、需要完成安全加固与稳定性维护的 DBA 及数据库运维人员。补丁包文件名 p20996944_112030_Linux-x86-64.zip，面向 Linux x86-64 平台，是集群软件、ASM、OCR 与 Voting Disks 等核心组件的重要更新集合。压缩包整体约 599.65MB，内含 README 说明文档、PatchSearch.xml 与 bundle.xml 等 OPatch 元数据配置，以及 20760997、17592127 等独立补丁编号目录，便于按官方流程完成预检查、应用与后处理。目前已有 400 人学习下载，适合需要为老旧 11gR2 环境补齐最后一批修复、提升高可用性与性能的读者参考使用。
1. 从一次 Grid Infrastructure 打补丁翻车说起：为什么 11.2.0.3 的最后一个 PSU 值得单独写一篇
给 Oracle 11.2.0.3 的 Grid Infrastructure 打 PSU，是很多老 DBA 心里的一根刺。这套环境在不少存量业务里还在跑，RAC 双节点、ASM 存储、监听器全挂在 GI 上，一旦补丁打歪，集群起不来，业务直接躺平。而 p20996944 这个补丁包，是 11.2.0.3 分支上 GI 加 DB 的最后一个 PSU，版本号 .15，Linux x86-64 平台，文件名p20996944_112030_Linux-x86-64.zip。说它是“收官补丁”一点不夸张——打完这个，11.2.0.3 的补丁线基本就走到头了。我见过太多人栽在“先打 GI 还是先打 DB”“opatch 版本没换”“补丁冲突没查”这几个坑上，所以这篇不聊虚的，就按我实际操作的顺序，把环境、解压、GI 打补丁、DB 打补丁、验证、排错一条线走完。适合手里还维护着 11.2.0.3 RAC 环境、需要把 GI 和 DB 一起推到 .15 的运维和 DBA。
2. 打补丁前的环境清点：版本、opatch 和空间一个都不能少
2.1 确认 GI 和 DB 的当前版本
补丁不是随便往上怼的，第一步永远是确认你现在到底在哪个版本。GI 和 DB 的版本要分开查，因为两者可能不一致。
# 查 GI 版本，在 GI 的 ORACLE_HOME 下执行 $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep -i "Oracle Grid Infrastructure" # 查 DB 版本，在 DB 的 ORACLE_HOME 下执行 $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep -i "Oracle Database"逻辑说明：opatch lsinventory -detail会列出当前 ORACLE_HOME 下所有已安装的补丁和组件版本。GI 的 ORACLE_HOME 通常是/u01/app/11.2.0/grid，DB 的通常是/u01/app/oracle/product/11.2.0/dbhome_1。参数-detail比不加时输出更全，能看到具体补丁号。如果 GI 和 DB 版本不一致，比如 GI 是 11.2.0.3.0 而 DB 是 11.2.0.3.8，那打补丁的顺序和冲突检查要更小心。
2.2 opatch 版本必须换到补丁要求的版本
这是最容易翻车的地方。11.2.0.3 自带的 opatch 版本往往太老，打 .15 这种后期 PSU 会直接报错。补丁包里通常带了一个OPatch目录，或者你需要单独下载对应版本的 opatch。
# 备份旧 opatch mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak # 解压补丁包里的 opatch（假设补丁包已解压到 /tmp/p20996944） cp -r /tmp/p20996944/OPatch $ORACLE_HOME/OPatch # 验证 opatch 版本 $ORACLE_HOME/OPatch/opatch version逻辑说明：mv是给旧 opatch 留后悔药，万一新 opatch 有问题可以回滚。cp -r把补丁包里的 OPatch 目录整个复制过去。opatch version确认版本号，11.2.0.3 的 .15 PSU 一般要求 opatch 在 11.2.0.3.12 以上。GI 和 DB 两个 ORACLE_HOME 都要换，别只换一个。
2.3 检查磁盘空间和补丁冲突
补丁解压和安装过程会占用大量临时空间，GI 的 ORACLE_HOME 和/tmp都要看。
# 检查关键目录空间 df -h $ORACLE_HOME /tmp # 检查补丁冲突 cd /tmp/p20996944 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./逻辑说明：df -h看剩余空间，GI 的 ORACLE_HOME 建议至少留 5G 以上，/tmp至少 2G。opatch prereq CheckConflictAgainstOHWithDetail -ph ./是打补丁前的标准动作，-ph指定补丁目录，./表示当前目录。如果报冲突，先解决冲突再往下走，别硬打。
提示：GI 和 DB 的补丁冲突检查要分别在各自的 ORACLE_HOME 下做，因为两者已安装的补丁集不同。
3. 解压与 GI 补丁安装：先停集群再动手
3.1 解压补丁包并确认目录结构
拿到p20996944_112030_Linux-x86-64.zip后，先解压到一个干净的目录。
# 创建解压目录 mkdir -p /tmp/p20996944 cd /tmp/p20996944 # 解压补丁包 unzip p20996944_112030_Linux-x86-64.zip # 查看解压后的结构 ls -l逻辑说明：解压后通常会看到一个以补丁号命名的目录，里面包含README.html、etc、files等。README.html一定要读，里面写了这个补丁适用的版本、前置补丁、以及 GI 和 DB 分别怎么打。我一般会先把 README 里的“Patch Installation”章节过一遍，确认有没有特殊步骤。
3.2 停止 GI 相关进程
打 GI 补丁必须停集群，这是硬性要求。顺序是先停 DB 实例，再停 GI。
# 以 grid 用户执行，停止集群 $GRID_HOME/bin/crsctl stop cluster -all # 确认集群已停 $GRID_HOME/bin/crsctl check cluster -all逻辑说明：crsctl stop cluster -all会停掉所有节点上的集群服务，包括 ASM、监听器、OCR 等。crsctl check cluster -all用来确认状态，如果返回 “CRS-4537: Cluster Ready Services is offline” 之类的信息，说明停干净了。停之前最好把 DB 实例也停了，避免实例还在跑而 GI 被停导致异常。
3.3 在 GI 的 ORACLE_HOME 下应用补丁
这是核心步骤，用 opatch apply 打补丁。
# 切换到 grid 用户，设置 GI 的 ORACLE_HOME export ORACLE_HOME=/u01/app/11.2.0/grid export PATH=$ORACLE_HOME/OPatch:$PATH # 进入补丁目录 cd /tmp/p20996944/20996944 # 应用补丁 $ORACLE_HOME/OPatch/opatch apply逻辑说明：opatch apply会自动读取当前目录下的补丁信息并应用。执行过程中会提示确认，一般输入y继续。如果补丁包要求指定-local或-all_nodes，按 README 来。打完后 opatch 会输出 “OPatch succeeded” 之类的成功信息。如果中途报错，先看日志，日志路径通常在$ORACLE_HOME/cfgtoollogs/opatch/下。
3.4 验证 GI 补丁并重启集群
打完补丁后，先验证再重启。
# 验证补丁是否已应用 $ORACLE_HOME/OPatch/opatch lsinventory | grep 20996944 # 重启集群 $GRID_HOME/bin/crsctl start cluster -all # 检查集群状态 $GRID_HOME/bin/crsctl check cluster -all $GRID_HOME/bin/crsctl stat res -t逻辑说明：opatch lsinventory | grep 20996944能看到补丁号就说明 GI 补丁打上了。crsctl start cluster -all重启集群，crsctl stat res -t看所有资源状态，重点确认 ASM、监听器、VIP 都是 ONLINE。如果有资源起不来，先看crsctl stat res <资源名> -t的详细输出，再查对应日志。
4. DB 补丁安装：GI 起来之后再动数据库
4.1 确认 DB 的 ORACLE_HOME 和 opatch
GI 补丁打完并确认集群正常后，再处理 DB 补丁。DB 的 ORACLE_HOME 和 GI 是分开的，opatch 也要确认版本。
# 切换到 oracle 用户，设置 DB 的 ORACLE_HOME export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/OPatch:$PATH # 确认 opatch 版本 $ORACLE_HOME/OPatch/opatch version逻辑说明：DB 的 opatch 如果之前没换，这里也要换成补丁包里的版本。步骤和 GI 一样，备份旧的，复制新的。确认版本符合 README 要求后再往下走。
4.2 停止 DB 实例和监听器
打 DB 补丁前，实例要停，监听器也要停。
# 停止 DB 实例 srvctl stop database -d <db_name> # 停止监听器 srvctl stop listener # 确认实例已停 srvctl status database -d <db_name>逻辑说明：srvctl stop database -d <db_name>停掉整个数据库，<db_name>换成你的数据库名。srvctl stop listener停监听器。srvctl status database -d <db_name>确认实例状态是 “not running”。如果实例停不下来，可以用sqlplus / as sysdba进去shutdown immediate。
4.3 应用 DB 补丁
和 GI 类似，在 DB 的 ORACLE_HOME 下执行 opatch apply。
# 进入补丁目录 cd /tmp/p20996944/20996944 # 应用补丁 $ORACLE_HOME/OPatch/opatch apply逻辑说明：DB 补丁的 apply 过程和 GI 基本一致。注意如果补丁包里 GI 和 DB 的补丁是分开的目录，要进对目录。打完后同样看 “OPatch succeeded”。如果报 “Patch 20996944 not applicable to Oracle Home”，说明补丁号和你的 ORACLE_HOME 不匹配，检查是不是进错了目录或者 ORACLE_HOME 设错了。
4.4 执行 post-patch 脚本
DB 补丁打完通常要跑catbundle.sql或类似的脚本，更新数据字典。
# 启动实例到 mount 状态 sqlplus / as sysdba SQL> startup mount; SQL> @?/rdbms/admin/catbundle.sql psu apply SQL> alter database open;逻辑说明：catbundle.sql是 PSU 补丁的标准 post-patch 脚本，psu apply是参数，表示应用 PSU。执行时间可能较长，取决于数据库大小。跑完后alter database open打开数据库。如果脚本报错，先看错误号，常见的是因为实例没在 mount 状态或者权限不对。
4.5 重启 DB 和监听器并验证
补丁和脚本都完成后，重启服务并验证。
# 启动监听器 srvctl start listener # 启动数据库 srvctl start database -d <db_name> # 验证 DB 补丁 $ORACLE_HOME/OPatch/opatch lsinventory | grep 20996944 # 查数据字典版本 sqlplus / as sysdba SQL> select * from registry$history;逻辑说明：srvctl start listener和srvctl start database把服务拉起来。opatch lsinventory确认 DB 补丁已应用。registry$history是数据字典里的补丁历史表，能看到catbundle.sql的执行记录。如果这里没有记录，说明 post-patch 脚本没跑成功，要回头补。
5. 避坑与排查：这五个坑我踩过至少三个
5.1 现象：opatch apply 报 “OPatch failed with error code 73”
原因：opatch 版本太老，不支持这个补丁的格式。11.2.0.3 自带的 opatch 往往是 11.2.0.3.0 附近的版本，而 .15 PSU 要求更高的 opatch。
解决：从补丁包里提取 OPatch 目录，替换掉 ORACLE_HOME 下的旧 opatch。GI 和 DB 都要换。换之前备份旧目录，换之后opatch version确认。
5.2 现象：GI 补丁打完集群起不来，ASM 资源 OFFLINE
原因：补丁过程中 OCR 或 voting disk 状态异常，或者补丁没打完整。
解决：先看crsctl stat res -t和crsctl stat res ora.asm -t的详细输出，再查 ASM 的 alert 日志。如果是 OCR 问题，用ocrcheck检查。实在不行，用crsctl stop cluster -all再crsctl start cluster -all重启一次。还不行就考虑回滚补丁。
5.3 现象：DB 补丁打完，catbundle.sql执行报 ORA-04063 或 ORA-00904
原因：数据字典对象无效，或者补丁和当前 DB 版本不匹配。
解决：先确认 DB 版本和补丁版本对应。如果版本对，尝试重新编译无效对象：@?/rdbms/admin/utlrp.sql。如果还报错，看具体错误号，可能是某个组件没打前置补丁。
5.4 现象：补丁冲突检查报 “Patch 20996944 conflicts with patch XXXXX”
原因：当前 ORACLE_HOME 里已经装了和这个补丁冲突的补丁。
解决：看冲突补丁号，如果是更早的 PSU，通常可以继续打，因为新 PSU 会覆盖旧的。但如果是其他类型的补丁，比如某个 one-off patch，就要先回滚那个补丁再打。回滚用opatch rollback -id <补丁号>。
5.5 现象：打补丁后监听器起不来，报 “TNS-12541: TNS:no listener”
原因：监听器配置在补丁过程中被覆盖，或者监听器进程没起来。
解决：先lsnrctl status看状态，如果没起来，lsnrctl start手动起。如果报配置错误，检查$ORACLE_HOME/network/admin/listener.ora是否被改。GI 环境下的监听器通常由srvctl管理，用srvctl start listener而不是lsnrctl start。
6. 装完怎么验证：三个必须走一遍的检查
补丁打完、服务起来，不代表就完事了。我一般会强制走三个检查，确认这套环境真的稳了。
第一个检查是 opatch 的补丁清单。GI 和 DB 两个 ORACLE_HOME 都要查，确认 20996944 在列表里。
# GI $GRID_HOME/OPatch/opatch lsinventory | grep -E "20996944|Patch" # DB $ORACLE_HOME/OPatch/opatch lsinventory | grep -E "20996944|Patch"逻辑说明：grep -E同时匹配补丁号和 “Patch” 关键字，输出更清晰。如果 GI 和 DB 都显示 20996944，说明补丁应用到位。
第二个检查是集群资源状态。crsctl stat res -t的输出里，所有资源都应该是 ONLINE，尤其是 ASM、监听器、VIP、OCR。
$GRID_HOME/bin/crsctl stat res -t逻辑说明：重点看ora.asm、ora.LISTENER.lsnr、ora.<db_name>.db这几行。如果有 OFFLINE 或 INTERMEDIATE，先看详细状态再查日志。
第三个检查是数据库层面的补丁历史。连进数据库查registry$history和dba_registry_sqlpatch（如果版本支持）。
-- 查补丁历史 select action, namespace, version, id, comments, action_time from registry$history order by action_time desc; -- 查组件版本 select comp_id, version, status from dba_registry where comp_id in ('CATALOG','CATPROC');逻辑说明：registry$history里应该有catbundle.sql的执行记录，action是APPLY，comments里能看到 PSU 信息。dba_registry里CATALOG和CATPROC的status应该是VALID。如果CATPROC是INVALID，跑utlrp.sql重新编译。
这三个检查走完，基本可以确认这套 11.2.0.3 的 GI 加 DB 已经推到 .15 了。从那以后我每次打完 PSU，不管多顺，都会把这三个检查强制走一遍——因为曾经有一次偷懒没查registry$history，结果catbundle.sql其实没跑成功，过了两周才发现数据字典版本不对，又得重新补。希望帮到你。
本文还有配套的精品资源，点击获取