简介面向 Linux x86-64 平台的 Oracle Database 11.2.0.4 官方 PSU 补丁包 p36575425是 2024 年 7 月发布的季度更新适用于需要保持数据库安全与稳定的 DBA、系统管理员及企业运维团队。该版本为长期支持版补丁内容涵盖安全漏洞修复、稳定性改进和性能优化可显著降低生产环境运行风险。资源为 zip 压缩包共包含 2000 个文件其中以 732 个 o 编译对象和 693 个 so 共享库为核心文件支撑补丁的实际链接与替换同时提供 208 个 xml 描述文件、164 个 sql 脚本以及 class、jar、a、mk 等辅助文件便于安装时校验、配置和扩展压缩包整体约 536MB。目前已有 911 人学习下载。借助该补丁包DBA 可在 Oracle 11.2.0.4 数据库上执行 OPatch 冲突检测、补丁应用和状态核对并能对照其中的脚本与清单检查补丁是否生效资源也适合作为补丁升级演练、版本回滚和故障排查的参考素材帮助运维人员在正式变更前充分验证。 每个周末晚上还在折腾一个 11.2.0.4 的数据库这在 2024 年听起来确实挺魔幻但做了多年 DBA 的人都知道老版本 Oracle 的存量用户比想象中多得多。最近刚好在处理一套 Linux x86-64 环境上的 11.2.0.4 数据库需要上最新一季的 PSUPatch Set Update补丁补丁号 p36575425对应的版本串是 11.2.0.4.240717。整套流程走下来从下载补丁到验证完成差不多花了一个维护窗口中间还踩了几个不算深但足够烦的坑所以把完整过程整理成这篇文章。这篇文章写给谁两类人最需要一类是还在维护 11.2.0.4 单机或 RAC 环境的运维/DBA另一类是被等保检查或安全通告逼着打补丁但不敢轻易动手的同事。文章会覆盖从补丁包识别、前置检查、opatch 升级、正式 apply、SQL 脚本执行到验证回滚的完整链路所有命令都是我在真实环境验证过的直接抄作业即可。1. 11.2.0.4熬到2024这个PSU补丁为何非打不可1.1 一个老版本的真实处境先说明一个背景Oracle 11.2.0.4 是 11gR2 的最终版本官方 Premier Support 早就结束了现在能拿到的是 Sustaining Support 和部分 Extended Support 窗口下的更新。这意味着什么意味着你不会再有新功能但关键安全漏洞和严重 bug 的修复补丁依然会以季度 PSU 的形式发布。对于很多跑着核心业务、因为应用兼容性没法升级到 12c/19c 的系统来说打 PSU 几乎是唯一能缓解安全隐患的手段。所以别觉得给 11.2.0.4 打补丁是无用功恰恰相反在一堆 CVE 通告面前季度 PSU 是你最实在的防线。等保测评里对数据库安全补丁及时更新的要求也是靠这套机制来满足的。p36575425 这个补丁从命名上拆解一下p36575425是 Oracle 官方补丁平台的内部补丁号。112040表示适用于 11.2.0.4.0 基础版本。240717是补丁发布日期对应 2024 年 7 月 17 日。平台后缀Linux-x86-64就是 Linux 64 位标准版。补丁文件名一般是p36575425_112040_Linux-x86-64.zip大小通常在几百 MB 到 1GB 不等。PSU 是一种累积补丁意思是只要你从 11.2.0.4.0 直接打这个 PSU之前季度的安全修复和关键 bug 修复都会被包含进来不需要先打之前的旧 PSU。这一点很关键很多新手会误以为要按顺序一个一个打其实不用。1.2 补丁包里的内容构成补丁包解压后你会得到一个以补丁号命名的目录里面包含etc/目录补丁元数据opatch 依赖这些文件做冲突检查和安装。files/目录真正的二进制替换文件包括 oracle 可执行文件、库文件、SQL 脚本等。README.txt补丁的完整说明文档必读。部分 PSU 还会带上postinstall脚本例如数据库层的catbundle.sql。这里提示一下不要只看文件名就说打好了。PSU 分两层——软件层binary patch和数据库层SQL patch。软件层由opatch apply完成但数据库字典里的版本信息升级靠的是后续执行catbundle.sql psu apply。这一步漏掉的话opatch lsinventory里能看到补丁但v$version和dba_registry_history不会更新等于打了一半。2. 动手前三查opatch版本、冲突扫描和家目录备份2.1 opatch版本翻车率最高的第一道关卡很多人在打 PSU 时遇到的第一个报错就是OPatch version must be 11.2.0.3.36 or above这个报错的原因很简单你当前$ORACLE_HOME/OPatch/opatch的版本太老不认识新补丁的元数据格式。查看当前版本$ORACLE_HOME/OPatch/opatch version如果版本不够先去 Oracle 官网下载对应 11.2.0.4 的 opatch 升级包。opatch 工具本身的补丁号一般是p6880880下载时要注意选对平台和版本系列。升级方式也很粗暴但安全cd /tmp unzip -o p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME这个命令会把新的opatch覆盖到$ORACLE_HOME/OPatch。升级前建议先备份一下旧目录cp -r $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak.$(date %Y%m%d)升级后再确认$ORACLE_HOME/OPatch/opatch version对了补充一个经验opatch 升级不影响运行中的数据库不需要停库可以在维护窗口之前提前做。但千万别在打补丁的过程中去做这件事因为 opatch 运行时目录内有临时文件容易出幺蛾子。2.2 冲突检查提前知道补丁能不能共存PSU 是累积的但如果你的环境里已经装了某些 one-off 补丁例如某个特定 bug 的修复包它可能和 PSU 修改同一个文件产生冲突。冲突的后果轻则安装失败重则打完后某个二进制行为异常。检查命令cd /u01/software/36575425 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph .这个命令会扫描当前$ORACLE_HOME里已安装的补丁和待安装 PSU 做对比输出冲突列表。实际使用中我遇到过因为历史遗留 one-off 补丁导致冲突的情况当时的选择是先用opatch rollback -id one-off补丁号回滚旧补丁再打 PSU。打完后如果需要那个 one-off 的修复再确认它是否已包含在 PSU 里——由于 PSU 是累积的大概率是包含的。另外还有一个隐藏的坑检查输出里可能提示你某些子补丁已经被 superseded被替代这种情况下如果旧补丁已经包含在 PSU 里opatch 可以正常覆盖不用额外处理。2.3 空间、备份和维护窗口空间检查不能只看df -h还要看$ORACLE_HOME所在文件系统的剩余量。PSU 安装过程中opatch 会把被替换的旧文件放到$ORACLE_HOME/.patch_storage这部分空间和补丁包大小差不多我建议至少预留 10GB 以上空间df -h /u01/app/oracle备份策略方面我通常按两套来做数据库层打补丁前做一次全备RMAN 或冷备份均可视环境而定。虽然 PSU 大多是二进制替换SQL 脚本也只是小幅变更但数据库是所有业务的地基备份再谨慎都不为过。软件层把整个$ORACLE_HOME复制一份建议用 tar 打包而不是简单 cp速度和完整性更好tar -czf /backup/oracle_home_bak_$(date %Y%m%d).tar.gz $ORACLE_HOME如果数据库跑在虚拟机或云主机上强烈建议在打补丁前打一个磁盘快照。快照的回滚速度比任何 tar 解压都快是应急时最硬的底牌。维护窗口确认也很重要打 PSU 需要停库停监听业务影响窗口至少在半小时到一小时。除了确认业务方批准了时间还要先看一眼当前数据库的会话情况避免 shutdown immediate 时被大量活动会话卡住select count(*), status from v$session group by status;3. 停库、apply、跑脚本一次完整的PSU安装流水账3.1 解压补丁包和环境确认先把补丁包放到一个文件系统余量充足的目录例如/u01/software然后用 oracle 用户解压cd /u01/software unzip -q p36575425_112040_Linux-x86-64.zip cd 36575425解压后第一件事不是急着 apply而是cat README.txt重点看两个部分一是Pre-Installation里对 opatch 版本、空间、前置条件的要求二是Post-Installation里要求执行的 SQL 脚本。官方文档的要求偶尔会和网上教程有出入以 README 为准。然后确认环境变量已经正确设置echo $ORACLE_HOME echo $ORACLE_SID这些变量如果没设好opatch 会直接报ORACLE_HOME is not set。如果是通过 su 切换到 oracle 用户环境变量经常丢失建议用su - oracle而不是su oracle。3.2 停库、停监听让数据库干干净净地打补丁PSU 需要替换 oracle 可执行文件和一堆共享库这时候数据库进程是绝对不能运行的否则文件被占用或者代码版本不一致都会出问题。操作顺序lsnrctl stop然后登录数据库执行 shutdownsqlplus / as sysdba SQL shutdown immediate;这里有个细节如果数据库启用了 ASM并且$ORACLE_HOME同时包含了 Grid 和 Database 两套软件那打补丁的复杂度和顺序会略有不同。本文主要说数据库层的 PSU单机非 ASM 环境最简单。RAC 环境则需要用opatch auto做滚动打补丁逐节点操作不在本文展开。停库后检查进程确认已经完全退出ps -ef|grep ora_|grep -v grep正常情况下应该没输出。如果有ora_pmon之类的后台进程残留不能用kill -9硬杀先看看是不是 pmon 还挂在某些无法清理的资源上或者等下再检查一次。顺带说一句这个窗口期其实是做冷备份的好时机。如果你之前只做了热备现在可以趁库停着把数据文件也 physical copy 一份双保险。这种停都停了顺手多备一份的操作在故障发生时会让你特别感激自己。3.3 执行opatch apply日志里看门道进入补丁目录后执行cd /u01/software/36575425 $ORACLE_HOME/OPatch/opatch apply如果担心终端断连导致任务中断可以用 nohup 或者干脆放到 tmux/screen 里跑nohup $ORACLE_HOME/OPatch/opatch apply /tmp/opatch_apply.log 21 这是我在生产环境养成的习惯——打补丁一旦中断恢复起来要花更多时间去排查。用 nohup 可以避免 SSH 抖动导致的悲剧。opatch 执行时会做一系列前置检查包括冲突检查、空间检查、权限检查等然后开始替换文件。输出里你会看到类似Updating archive name ... Copying 1 file to ...这个过程快则几分钟慢则十几分钟取决于机器性能和$ORACLE_HOME大小。最后成功时输出有一段OPatch succeeded.看到这个基本就说明软件层打好了。但如果最后出现OPatch failed.怎么办别急日志是首要排查依据最常见的是权限问题或空间不足tail -n 100 /tmp/opatch_apply.log如果是权限问题确认用 oracle 用户操作并检查文件属主ls -ld /u01/app/oracle/product/11.2.0/dbhome_13.4 跑SQL脚本把补丁注册进数据库字典软件层完成后回到数据库层面。首先启动数据库到 upgrade 模式如果 README 要求或直接 open不同版本要求不一样11.2.0.4 的 PSU 通常在 open 状态就能执行 postinstall 脚本sqlplus / as sysdba SQL startup;然后执行SQL $ORACLE_HOME/rdbms/admin/catbundle.sql psu apply这一步会更新数据库字典的版本信息并把 PSU 相关组件注册到dba_registry_history。执行过程中会有大量输出耗时可能比较长不要中途 CTLC。执行完成后还要跑一次utlrp.sql来重新编译那些因为字典变更而失效的对象SQL $ORACLE_HOME/rdbms/admin/utlrp.sqlutlrp.sql会输出类似 Recompilation of invalid objects finished 的提示就算完成。再验证一下失效对象数量select count(*) from dba_objects where statusINVALID;在 11.2.0.4 里打完 PSU 后出现少量诸如DBMS_SCHEDULER相关对象失效是正常的utlrp.sql跑完会降到 0。如果仍然有大量失效对象就要认真看了后面讲排查思路。4. 常见报错与验证补丁装完不等于万事大吉4.1 用两条 SQL 验证补丁真的生效很多人在opatch apply报成功后就直接宣布打完补丁了其实不够严谨。我习惯做三件事第一确认补丁在 inventory 里$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425能匹配到补丁号就说明软件层注册成功。第二查数据库字典的补丁历史select * from dba_registry_history;如果能看到PSU 11.2.0.4.240717这样的记录说明 SQL 层也生效了。第三确认数据库组件版本select comp_id, comp_name, version, status from dba_registry;正常情况所有组件状态都应该是VALID版本号有所更新。这一步可以顺带发现一些历史遗留的组件状态问题。4.2 失效对象和组件异常的排查思路打完补丁后最常见的异常就是失效对象。跑完utlrp.sql仍然有失效对象时我的做法是select owner, object_type, object_name from dba_objects where statusINVALID;然后针对具体对象去看它的last_ddl_time或者其他告警日志里的信息。多数情况是某个系统包依赖了被替换的库文件重新编译一下就好。如果某个对象反复编译失败就去查$ORACLE_HOME/rdbms/log或 alert log里面通常有原因。不要自己乱手动 drop 重建尤其是SYS和SYSTEM下的对象很容易引起更严重的问题。另外打补丁后有时会出现ORA-04063或ORA-06508这类 PL/SQL 运行时错误通常也是因为字典对象和二进制版本不一致跑完utlrp.sql再重启一次实例基本能解决。4.3 我实际遇到过几个坑说几个我自己踩过或者身边同事踩过的坑给大家提个醒。坑一忘了先升级 opatch。有个环境上一次打补丁还是两年前opatch 版本停留在 11.2.0.3.5直接 apply 时报版本错误。当时维护窗口已经批了临时找下载链接又花了半小时最后一整晚节奏全乱。现在我的习惯是每个季度 PSU 发布后先把 opatch 升到最新并确认能通过opatch version和opatch lsinventory让环境随时处于可以打补丁的状态。坑二overwrite 了不应该动的 ORACLE_HOME。打补丁前我想当然用了cp -rf把旧的$ORACLE_HOME备份到别的地方但目标路径下有历史残留文件cp -rf把老的 jar 包和二进制混合到了一起。虽然那次没出事但之后我改用tar -czf打包备份彻底避免目录合并的问题。坑三执行 catbundle.sql 时终端断了。一次远程操作catbundle.sql 执行到一半 SSH 断了结果数据库里补丁注册状态半完成。后来排查了很久。解决办法很简单sqlplus 里多用spool记录日志关键脚本尽量在 tmux 里跑或者干脆用nohup方式nohup sqlplus / as sysdba EOF /tmp/catbundle_run.log 21 $ORACLE_HOME/rdbms/admin/catbundle.sql psu apply $ORACLE_HOME/rdbms/admin/utlrp.sql EOF这样即使断连脚本也会继续执行你只需要事后检查日志。再补充一个 11.2.0.4 环境的注意事项如果数据库里使用了不少高级组件例如 Partitioning、Spatial 等建议在打补丁前先把这些组件的状态确认好。如果某个组件本身就处于INVALID或UPGRADE状态PSU 的 postinstall 脚本可能执行不顺利。5. 万一失手怎么办回滚流程与应急底牌5.1 opatch rollback 的完整操作虽然 PSU 安装成功率很高但万一出现数据库起不来、执行 apply 失败导致二进制不一致等状况需要回滚。回滚逻辑和安装类似先软件后数据库。首先停库、停监听然后执行cd $ORACLE_HOME $ORACLE_HOME/OPatch/opatch rollback -id 36575425opatch 会从.patch_storage里把原始文件找回来恢复。回滚成功后同样要检查$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425确认补丁不在列表里了。接着启动数据库执行回滚的 SQL 脚本。在 11.2.0.4 里如果你已经跑过catbundle.sql psu apply回滚时也要执行相应的降级脚本。操作方式是找到$ORACLE_HOME/rdbms/admin下的catbundle.sql使用rollback模式SQL $ORACLE_HOME/rdbms/admin/catbundle.sql psu rollback SQL $ORACLE_HOME/rdbms/admin/utlrp.sql最后再次检查dba_registry_history确保 PSU 记录被移除数据库版本恢复到打补丁前的状态。5.2 什么场景别硬扛直接用快照回滚虽然可行但也不是万能的——如果打补丁过程中文件系统损坏、或者某些操作导致$ORACLE_HOME状态非常混乱opatch rollback可能因为.patch_storage不完整而失败。这时候最干净的方案是磁盘快照回滚。我在前面就强调过能打快照就打快照。真到了需要应急的时候快照秒级回滚带来的好处远比花十几分钟打包备份更实在。如果不幸连快照都没有那就只能靠之前的 tar 包了rm -rf $ORACLE_HOME/* tar -xzf /backup/oracle_home_bak.tar.gz -C /这种方式恢复速度取决于文件大小通常能以分钟级完成但务必在恢复后仔细核对权限和软链接。关于回滚还有一个很实际的建议一旦决定要回滚就不要再反复尝试 apply 同一份补丁。有些时候第一次失败是因为环境临时问题改一下权限或空间就能解决但如果第一次失败的原因没找到盲目重试第二次第三次很可能把$ORACLE_HOME搞得更乱。先定位原因再决定继续还是回滚。最后说一个我自己的习惯每次打完 PSU我都习惯把操作时间、补丁号、遇到的问题、最终验证结果记到一份简单的运维文档里。下个季度再打补丁时翻一下上次的记录能避开不少自己当年踩过的坑。这次 p36575425 的安装过程大概就是这些如果你也在维护 11.2.0.4 的老环境照着这个流程走应该能少走点弯路。本文还有配套的精品资源点击获取