简介面向 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 是前提条件文档。它们各自的作用和注意点如下路径/文件作用注意点filesOPatch 要更新的实际文件不要手工改动etc补丁配置与 inventory 记录删除会导致 apply 后清单残缺actions.xml本次补丁所有动作步骤OPatch 版本太老时第一个报错点README.txt前提条件与操作流程以它为准不以上网教程为准阅读 README 时重点确认三件事补丁包里是否含独立的 OJVM 补丁RAC 环境要求滚动还是全部节点离线SQL 阶段要执行的脚本名。季度 PSU 经常是组合包解压后会看到多个子目录只盯着一个 apply 完就收工是典型的半成品操作。3. 应用补丁从停库到 opatch apply3.1 停监听、关数据库把系统状态收拾干净apply 过程中 Oracle Home 的二进制文件正在被替换实例必须全部关闭否则后台进程会占用文件句柄更新要么失败要么污染运行中的进程。先停监听是防止关库期间产生新的连接尝试顺序不要反。lsnrctl stop sqlplus / as sysdba EOF shutdown immediate; exit; EOFlsnrctl stop 停掉本节点 LISTENERshutdown 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 正式应用一切就绪切到补丁目录用绝对路径执行 opatchcd /u01/psu/33477185 $ORACLE_HOME/OPatch/opatch apply这条命令会先做前置检查补丁是否适用当前 Oracle Home、inventory 是否可写、磁盘空间是否足够、是否存在补丁冲突。检查通过后开始复制文件输出里会反复出现 Copy 和 Updating 字样最终以OPatch succeeded.收尾。单实例纯软件更新一般 15 到 30 分钟取决于磁盘 IO 速度。apply 一旦被终端断开会非常被动正常做法是挂 nohupnohup $ORACLE_HOME/OPatch/opatch apply /tmp/opatch_apply.log 21 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 statusINVALID;确认数量回到打补丁前的水平。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.0sys.registry$sqlpatch 没有新增记录。原因只执行了 opatch applySQL 阶段被跳过。这是半成品补丁的典型特征因为库能起来反馈不够痛所以很容易漏。解决数据库所有节点 OPEN 后用 4.1 的 catcon.pl 命令补跑 catpsu.sql。补跑不需要重新 apply 二进制只改数据字典。跑完按 4.2 验证 version 变成 11.2.0.4.220118 才算闭环。5.4 现象周边系统报 ORA-28040kettle 连不上库现象打完补丁重启后应用侧报协议协商错误排查后发现连接组件还是 32 位 oracle client或比较老的 ojdbc6.jar。原因数据库版本串从 11.2.0.4.0 变为 11.2.0.4.220118SQL*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 版本、无效对象数量记进运维台账下个季度打补丁直接对照基线和坑位省掉一半的排查时间。希望这些经验帮到你。本文还有配套的精品资源点击获取