简介：面向 Oracle 11.2.0.4 数据库的官方 PSU 补丁包，适用于 Linux x86-64 平台，于 2022 年 1 月发布，对应补丁编号为 p33477185。该补丁属于 Oracle 定期安全更新系列，主要修复当前版本的安全漏洞、性能缺陷与已知问题，帮助 DBA 在不升级大版本的前提下维持数据库稳定与安全，尤其适合生产环境暂未整体升级的运维团队。补丁包内含完整安装文件，共 3658 个文件，核心组成包括 1619 个动态链接库、1421 个二进制目标文件、182 个元数据描述文件和 142 个 SQL 脚本，另附少量 Java 归档与过程模块等辅助组件；压缩包整体约 436.52 MB。已有 854 人学习或下载，适合需要离线部署补丁、梳理 PSU 内部结构或制定升级预案的数据库管理员。资源内除具体补丁程序外，还保留了补丁描述文件，可核对适用条件与安装要求；结合库文件和脚本，能直观了解补丁对数据库实例、网络组件及客户端工具的影响范围，为测试环境验证与生产变更提供可靠参考。
1. DB-PSU-11.2.0.4.220118：最后一版 11g 数据库的季度补丁怎么打
先给结论：DB-PSU-11.2.0.4.220118 是 Oracle 11.2.0.4 数据库在 2022 年 1 月 18 日发布的季度补丁包，补丁编号 p33477185，平台限定 Linux x86-64。很多人以为 11.2.0.4 过了主支持期就不用再管补丁，实际这类老库每个季度仍然有安全与稳定性修复要落地。真正让补丁翻车的往往不是 opatch apply 本身，而是被跳过的数据字典升级阶段。这篇笔记把完整路径拆开：核对补丁基线、应用二进制、跑 SQL 脚本、验证与回滚，适合还在跑 11g 单实例或 RAC、需要自己落地季度 PSU 的 DBA 和运维工程师。
2. 动手前先对齐：环境检查与补丁包结构
2.1 用 opatch lsinventory 确认 Oracle Home 与当前补丁基线
补丁在 Oracle 体系里是严格的叠加逻辑。11.2.0.4 的 PSU 按季度发布，目标机器上可能已经存在更早的季度补丁，也可能几年没动过，两种基线下的冲突规则完全不同。不看清楚就 apply，前置检查阶段大概率被挡回来，或者出现“补丁已存在”之类的模糊报错。所以第一步永远是拿事实，而不是依赖记忆。
登录方式按最常见做法走：先切到 oracle 操作系统用户，确认环境变量，再执行 opatch。
su - oracle echo "ORACLE_HOME=$ORACLE_HOME" echo "ORACLE_SID=$ORACLE_SID" $ORACLE_HOME/OPatch/opatch lsinventory -detail | tee /tmp/lsinv_$(date +%Y%m%d).log第一行切用户，生产库的 Oracle 软件与 inventory 目录都属主为 oracle，用 root 或普通用户执行 opatch 即使不报错，也可能把文件属主干乱，后患无穷。后面两条 echo 是为了确认当前会话到底注入了哪个 Oracle Home，多实例机器上 source 错 profile 会把补丁打到另一个目录。最后一条用-detail参数输出已装补丁的详细描述，并tee落盘一份日志，后续排错不用重跑。
输出里需要盯住两件事。第一是 Base version 是否为 11.2.0.4.0，第二是 Patch history 中是否已经存在更早的季度 PSU。如果机器曾经打过 2021 年某月的 PSU，本次 220118 是叠加上去；如果完全没打过，就是第一次入轨，冲突率反而低。多 Oracle Home 的机器可以用-oh /u01/app/oracle/product/11.2.0/dbhome_1显式指定，避免跑错目录。另外留意输出里历史补丁的中文描述出现乱码时不要紧张，那不影响 inventory 数据，第 5 章会专门讲环境类坑。
2.2 核对 OPatch 版本和磁盘空间，别让前置检查卡住
PSU 的 apply 动作本身依赖 OPatch 的新特性。老版本 OPatch 读不懂新补丁的 actions.xml，会在最开头就退出，甚至给出误导性的“OPatch failed”。11.2.0.4 的季度 PSU 在 README 里通常会写明最低 OPatch 版本要求，大部分批次要求 11.2.0.3.x 及以上。检查命令就四条：
$ORACLE_HOME/OPatch/opatch version df -h $ORACLE_HOME df -h /tmp df -h /u01/app/oraInventory第一条比对 README 里的硬性要求；后面三条分别看软件目录、临时目录、Central Inventory 所在文件系统。PSU apply 会先在 Oracle Home 内生成一份补丁前备份，文件量大，软件目录至少留 5GB；/tmp 是解压和 opatch 日志的默认落点，同样建议留 5GB。oraInventory 所在盘是最容易被忽略的，实际报空间不足时，很多是它满了而不是 Oracle Home 满了。
提示：不同批次的 PSU 对 OPatch 版本要求不同，以手头补丁包里的 README.txt 为准，不要拿上一次的检查结论想当然。
2.3 解压补丁包，看清 p33477185 里到底有什么
下载得到的文件通常是 p33477185_112040_Linux-x86-64.zip，解压后目录名可能是日期串，也可能是纯数字编号，两者都正常。我习惯把工作目录统一重命名成补丁号，后续日志引用和 rollback 都简单：
mkdir -p /u01/psu cd /u01/psu unzip -q p33477185_112040_Linux-x86-64.zip if [ -d "DB-PSU-11.2.0.4.220118" ]; then mv DB-PSU-11.2.0.4.220118 33477185; fi cd 33477185 ls -la cat README.txt | less-q让 unzip 静默解压；if 判断处理目录名差异，把工作目录固定为 33477185。补丁目录的结构是固定的：files 目录放着本次要替换的二进制，etc 目录记录补丁自身的配置与 inventory 录入信息，actions.xml 是 OPatch 执行动作的描述文件，README.txt 是前提条件文档。它们各自的作用和注意点如下：
| 路径/文件 | 作用 | 注意点 |
|---|---|---|
| files | OPatch 要更新的实际文件 | 不要手工改动 |
| etc | 补丁配置与 inventory 记录 | 删除会导致 apply 后清单残缺 |
| actions.xml | 本次补丁所有动作步骤 | OPatch 版本太老时第一个报错点 |
| README.txt | 前提条件与操作流程 | 以它为准，不以上网教程为准 |
阅读 README 时重点确认三件事：补丁包里是否含独立的 OJVM 补丁；RAC 环境要求滚动还是全部节点离线；SQL 阶段要执行的脚本名。季度 PSU 经常是组合包，解压后会看到多个子目录，只盯着一个 apply 完就收工是典型的半成品操作。
3. 应用补丁：从停库到 opatch apply
3.1 停监听、关数据库，把系统状态收拾干净
apply 过程中 Oracle Home 的二进制文件正在被替换，实例必须全部关闭，否则后台进程会占用文件句柄，更新要么失败要么污染运行中的进程。先停监听是防止关库期间产生新的连接尝试，顺序不要反。
lsnrctl stop sqlplus / as sysdba <<EOF shutdown immediate; exit; EOFlsnrctl stop 停掉本节点 LISTENER；shutdown immediate 会终止并回滚未提交事务、回收后台进程，一般几十秒到几分钟。如果遇到长时间不结束，先查select inst_id, sql_id, status from gv$session where username is not null;，判断是哪个会话拖着，再决定是配合业务切走还是手工 kill，不要上来就shutdown abort。单实例环境务必确认监听和实例都已停止再继续：lsnrctl status和ps -ef | grep ora_各跑一遍，看到无进程输出才放心。
3.2 单实例上用 opatch apply 正式应用
一切就绪，切到补丁目录，用绝对路径执行 opatch：
cd /u01/psu/33477185 $ORACLE_HOME/OPatch/opatch apply这条命令会先做前置检查：补丁是否适用当前 Oracle Home、inventory 是否可写、磁盘空间是否足够、是否存在补丁冲突。检查通过后开始复制文件，输出里会反复出现 Copy 和 Updating 字样，最终以OPatch succeeded.收尾。单实例纯软件更新一般 15 到 30 分钟，取决于磁盘 IO 速度。
apply 一旦被终端断开会非常被动，正常做法是挂 nohup：
nohup $ORACLE_HOME/OPatch/opatch apply > /tmp/opatch_apply.log 2>&1 & tail -f /tmp/opatch_apply.log这样断线不影响执行，日志实时可见。看到 succeeded 后不要急着走，后面还有 SQL 阶段和验证。如果 apply 失败，日志末尾会留下失败位置，常见两类：前置检查被卡住，或者中途文件写入失败。前置检查被卡时系统没有改动任何文件，安全；中途失败则 Oracle Home 处于半更新状态，需要先按 README 清理残留的备份目录，再重新 apply，不要在同一份脏状态上连续二次执行。
3.3 RAC 环境：滚动应用，每个节点一套动作
RAC 两个节点不能同时停，常见做法是滚动更新：节点 1 先完成 stop-apply-start，确认实例对外服务正常后，再操作节点 2。11.2.0.4 的季度 PSU 在 README 里明确支持滚动，核心就是每节点独立完成三步：
# 节点 1 srvctl stop instance -d orcl -i orcl1 lsnrctl stop cd /u01/psu/33477185 $ORACLE_HOME/OPatch/opatch apply srvctl start instance -d orcl -i orcl1 # 节点 2 等节点 1 的实例正常后再执行 srvctl stop instance -d orcl -i orcl2srvctl 只停实例不停 CRS，集群件保持存活，另一个节点继续承接业务。每个节点的 apply 耗时与单实例相当，滚动总时长接近各节点之和。整套二进制更新完成后，SQL 阶段只需要在一个节点执行，具体命令在第 4 章。
为什么不建议全部节点停止后统一打：RAC 节点虽然各自有 Oracle Home，但集群件和 SCN 同步依赖存活节点；全部停掉后，任一步出错都更难定位，回滚时也要所有节点重走一遍。滚动方式让每个节点在打补丁时集群里始终有两个以上存活节点，排错窗口宽松得多。
4. POST 步骤：跑 SQL 脚本才是补丁完成的另一半
4.1 用 catcon.pl 运行 catpsu.sql 的正确姿势
二进制更新只替换了程序文件，数据字典里的版本信息还停留在旧状态。11.2.0.4 的 PSU 会通过 catpsu.sql 更新数据字典，并把补丁记录写入 registry$sqlpatch。这一步不做，数据库能正常启动，但内核版本与字典版本不一致，后续再打更高补丁或做升级时会报兼容性问题。跑脚本前先确认数据库处于 OPEN 状态：
sqlplus / as sysdba select open_mode, status from v$database;确认 OPEN 后退出 sqlplus，进入 rdbms/admin 目录执行：
mkdir -p /tmp/psu_sql_log cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catcon.pl -n 12 -b psu_220118 -l /tmp/psu_sql_log catpsu.sqlcatcon.pl 是 Oracle 自带的多实例并发 SQL 脚本执行器，11.2 的 PSU 文档推荐用它而不是直接 sqlplus 跑，原因在于它能按实例拆分日志、控制并发，避免多实例同时执行互相干扰。-n 12表示最多 12 个并发连接，按 CPU 核数调整；-b psu_220118是日志基名，生成形如 psu_220118_<时间戳>.log 的文件；-l指定日志目录，需要提前创建。catpsu.sql 是入口脚本，会自动调用配套字典更新脚本。
RAC 场景只在一个节点执行即可，但所有节点必须处于 OPEN 状态，catcon.pl 会自动探测并连接所有实例。执行日志里会大量出现 Patching 和 updating 输出，属正常现象。跑完看日志结尾的错误汇总，只要没有 ORA- 错误就行；偶尔出现的 object already exists 类警告是幂等脚本在网络重试时产生的无害信息。
4.2 验证 SQL 阶段到底生效没有
catcon.pl 返回后，进入 sqlplus 查询补丁注册表：
col action_time for a32 col version for a20 col patch_id for a8 select patch_id, action, version, status, action_time from sys.registry$sqlpatch order by action_time desc;如果本次补丁生效，应看到一行 action 为 APPLY、status 为 SUCCESS、version 为 11.2.0.4.220118 的记录。查询结果为空说明 SQL 阶段没执行成功，回到 4.1 重新跑。11.2.0.4 建了 registry$sqlpatch 后一般也有 dba_registry_sqlpatch 同义词可用，我习惯直接查 sys 视图，避免同义词权限差异带来的麻烦。
接着检查无效对象。打补丁会重建部分公共对象，老库上本来就积累了一批历史无效对象，重点看数量有没有明显上升。数量异常增长时跑一遍重编译脚本：
sqlplus / as sysdba @?/rdbms/admin/utlrp.sqlutlrp.sql 会用 dbms_utility 并行重编译失效对象，日志会显示每个对象的编译状态。数量大的库把它安排在维护窗口里，执行期间会占用 CPU，不要在业务高峰做。跑完再查一次select count(*) from dba_objects where status='INVALID';，确认数量回到打补丁前的水平。
5. PSU 补丁常见坑与排查：现象、原因、解决
5.1 现象：opatch apply 一执行就退出，日志指向 OPatch 版本过低
现象：整个 apply 在最早几行就结束，日志里明确提示 OPatch 版本太低，无法解析补丁包。
原因：目标机器几年没动过，OPatch 停留在 11.2.0.3.0 甚至更早；季度 PSU 的 actions.xml 使用了新版 OPatch 才支持的语法，老版本不认识。
解决：按 README 要求下载匹配的 OPatch，替换前先备份：
mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak unzip -q p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME chown -R oracle:oinstall $ORACLE_HOME/OPatchp6880880 是 OPatch 工具的标准补丁号，后面版本段按 Oracle 版本和平台取对应 zip。替换后先跑opatch version确认，再重新 apply。旧的 OPatch_bak 在确认整个补丁流程没问题之前不要删，它是最快的后悔药。
5.2 现象：apply 中途写盘失败，日志出现 No space left
现象：进度走到一半报文件写入失败，查看 df 发现 Oracle Home 或 /tmp 已用 100%。
原因：补丁备份文件、日志、临时文件同时落在 Oracle Home 与 /tmp，两个盘的空间都被低估了，oraInventory 所在盘有时也参与写入。
解决：先df -h $ORACLE_HOME和df -h /tmp看哪个满了，清理历史安装包和旧日志。空间腾出来后，按 README 清除 apply 残留的中间目录，再重新执行 opatch apply。排查顺序固定为：$ORACLE_HOME、/tmp、/u01/app/oraInventory，多节点环境三块盘都要看。
5.3 现象：库能正常启动，但 registry 里查不到本次补丁
现象：实例正常对外服务，v$version 仍是 11.2.0.4.0，sys.registry$sqlpatch 没有新增记录。
原因：只执行了 opatch apply，SQL 阶段被跳过。这是半成品补丁的典型特征，因为库能起来，反馈不够痛，所以很容易漏。
解决：数据库所有节点 OPEN 后，用 4.1 的 catcon.pl 命令补跑 catpsu.sql。补跑不需要重新 apply 二进制，只改数据字典。跑完按 4.2 验证 version 变成 11.2.0.4.220118 才算闭环。
5.4 现象：周边系统报 ORA-28040，kettle 连不上库
现象：打完补丁重启后，应用侧报协议协商错误，排查后发现连接组件还是 32 位 oracle client，或比较老的 ojdbc6.jar。
原因：数据库版本串从 11.2.0.4.0 变为 11.2.0.4.220118，SQL*Net 版本协商对老客户端更严格，出现“没有匹配的验证协议”。
解决：把客户端和 JDBC 驱动统一升到 11.2.0.3 以上，最省事的是直接用 11.2.0.4 的客户端驱动。验证方法：在 kettle 里用 ojdbc6.jar 新建一个表输入步骤，执行select banner from v$version，能看到 11.2.0.4.220118 即通。这个锅不该扣回补丁，是环境里长期欠账的客户端版本问题。
5.5 现象：RAC 第二个节点 apply 时报冲突，补丁已在清单里
现象：节点 2 执行 opatch apply 被拒，提示补丁已经存在于 inventory。
原因：常见两种。一种是两个节点共享了同一套 Oracle Home，这种架构本身就不支持常规方式打补丁；另一种是节点 1 apply 时集群件的同步机制把变更带了过去。
解决：先确认 home 是否独立：ls -ld $ORACLE_HOME对比两节点的挂载点，独立 home 时两节点路径相同但 inode 不同。共享 home 的库要么按集群停库后的离线方式处理，要么把其中一个节点迁移到独立 home，不要硬扛。独立 home 遇到该报错时，检查两个节点的 oraInventory 位置是否一致，排查集群同步误触发的可能。
6. 验证与回滚：给 PSU 上道后悔药
6.1 三步验证补丁真的可用
打完别急着交付，按三个层面各验一遍：
# 1) 二进制层面：补丁在清单里 $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 33477185 # 2) 数据字典层面：版本被推高 sqlplus / as sysdba select version, status from sys.registry$sqlpatch; # 3) 服务层面：实例存活、监听正常 lsnrctl status三个层面都过了，再用 kettle 等 ETL 工具配 ojdbc6.jar 跑一条业务常见查询，确认对外连接无异常。二进制有、字典有、服务通，补丁才算真正完成。
6.2 回滚的边界条件
回滚先分清阶段。只在二进制层 apply、SQL 脚本没跑时，回滚是干净的：
cd /u01/psu/33477185 $ORACLE_HOME/OPatch/opatch rollback -id 33477185SQL 阶段一旦执行并成功，PSU 对数据字典的变更很多不支持直接逆，所以我的习惯是：apply 二进制后、跑 catpsu.sql 之前，先用 RMAN 或文件系统快照做一个快速备份点；SQL 阶段出问题，优先恢复备份而不是 rollback。这是血泪经验——我见过有人硬回滚，结果字典版本停在中间态，最后花了三倍时间重建。
打完季度 PSU，我会把补丁号、日志路径、registry 版本、无效对象数量记进运维台账，下个季度打补丁直接对照基线和坑位，省掉一半的排查时间。希望这些经验帮到你。
本文还有配套的精品资源，点击获取
