简介这是Oracle官方发布的PSU补丁集补丁号36575425适用于64位Linux平台上的Oracle Database 11.2.0.4长期支持版本面向数据库管理员、系统运维及升级实施人员。该补丁包汇集了2024年7月发布的关键安全更新、缺陷修复与性能改进可帮助企业将生产库平滑升级到最新补丁级别规避已知漏洞与稳定性风险尤其适合承担关键业务系统的数据库环境。压缩包共536MB内含2000个文件其中以.o目标文件、.so共享库等二进制组件为主辅以.sql安装脚本、.xml配置与元数据文件以及.jar工具程序这些文件分别用于代码编译、动态链接、数据库对象变更、配置记录与辅助工具运行结构清晰便于依据实际环境选择部署内容。还包含PatchSearch.xml等元数据辅助文件能快速核对补丁描述与适用范围。目前已有944人学习下载适合需要定期维护Oracle 11g R2生产环境的团队作为升级参考。1. p36575425-11204011.2.0.4 老库还值得打的季度 PSUoracle 11.2.0.4.240717.Linux64-补丁集database PSU p36575425-112040-Linux-x86-64 这个完整补丁名拆开看就是 2024 年 7 月 17 日构建、面向 Linux x86-64 平台的 11.2.0.4 数据库季度安全补丁集。很多 DBA 看到“11.2.0.4 还在出补丁”会先愣一下因为这个版本的主流程支持早就走完了但正是这个标题说明Oracle 并没有彻底抛弃它安全修复仍在按季度发布只是不再加新功能了。对还在跑 11.2.0.4 生产库、却被漏扫报告逼着限期消漏洞的团队来说这个 PSU 就是官方给出的标准答案版本先不升补丁照打风险窗口能关就关。适合手里有 11.2.0.4 单机或 RAC 库的 DBA也适合暂时没有升级预算、需要自己动手先补安全缺口的应用负责人照着做。2. 补丁包背后11.2.0.4 的补丁机制与 p36575425 选型确认2.1 为什么 2024 年的补丁号会落在 11.2.0.4 上Oracle 11.2.0.4 发布到现在已经很多年Premier Support 和 Extended Support 都结束了目前处于持续支持阶段但安全补丁还是有节奏地按季度发布。标题里的 240717 就是这个补丁的构建日期戳翻译成自然语言就是 2024 年 7 月 17 日发布。这类补丁不会像以前一样引入大功能变更主要修复安全漏洞所以补丁策略选择上回到了 PSU 这个命名不再叫 RU 或 RUR。很多生产系统卡在 11.2.0.4是因为周边中间件认证和升级改造周期太长业务侧不愿意为此停窗口于是安全团队会拿着新披露的漏洞清单去查对应版本有没有可用补丁查到 p36575425 之后就形成了从“漏洞通告”到“具体补丁号”的闭环。这个阶段要理解 11.2.0.4 的补丁体系最好先分清几个容易混的名字。CPU 是早期按季度发布的安全补丁集合PSU 是它后面延续出来的季度补丁集PSU 基本包含之前多个 CPU 的修复内容且会累积。12.2 及以后版本 Oracle 换成 RU/RUR 的发布节奏功能更新和安全补丁混在一起而 11.2.0.4 没有这个体系依然使用 PSU 作为季度安全补丁的承载方式。拿这个标题里的 p36575425 来说它就是一个标准的 11.2.0.4 PSU补丁号在官方支持站点可以直接检索到下载介质会严格按照平台区分例如 Linux-x86-64 就只适配对应架构的数据库 home。补丁概念使用位置特点CPU11.2.0.4 早期补丁阶段季度安全补丁集合按漏洞公告发布独立安装PSU11.2.0.4 后期及当前阶段季度累积安全补丁包含安全修复与少量稳定性修复RU/RUR12.2 及以后版本季度更新机制RU 贴近安全补丁RUR 为修订版对实际运维来说与其纠结它到底算 CPU 还是 PSU不如直接看补丁 README 的适用范围和依赖项。README 写的是 “Database PSU 11.2.0.4.240717”安装对象就是数据库软件的 ORACLE_HOME不带 grid 功能也不需要重建库。这一步能过滤掉一多半翻车场景。拿到 p36575425 之后不要急着解压先把当前环境的基线记录下来。通常我会用下面一段命令确认 ORACLE_HOME 路径、当前 OPatch 版本以及已有补丁清单跑完的输出截图留存一份作为后续核对依据。su - oracle export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 $ORACLE_HOME/OPatch/opatch version $ORACLE_HOME/OPatch/opatch lsinventory -detail代码里第一行切换为 oracle 用户不要用 root 做补丁操作否则权限错乱会带来后续排查困难第二行设置 ORACLE_HOME具体路径要按你机器实际安装位置改opatch version 查看 OPatch 自身版本opatch lsinventory -detail 会输出当前 home 下已经安装的补丁列表和产品信息。重点看已有补丁里有没有跟 p36575425 冲突的旧补丁以及当前 OPatch 版本是否低于 README 的要求这两点如果没确认就进入窗口大概率会在 apply 阶段收到前置检查失败。2.2 选型要确认的 4 件事平台、补丁类型、OPatch、补丁依赖第一件事是平台匹配。补丁包名字明确写了 Linux-x86-64安装方向必须是 x86-64 架构的 Linux 数据库 home。可以用 file 命令看 oracle 二进制本身的架构类型避免在下意识里把一个 32 位软件包或错误路径的 home 当目标。命令本身不费事但能在窗口里省下一次应用失败和排查时间。file $ORACLE_HOME/bin/oracle输出里如果包含 x86-64 字样说明当前 home 架构与补丁介质匹配如果显示的是 i386 或 IA-64那这个补丁就不能直接应用需要回官方支持站点下载对应平台介质。架构不匹配是前置检查阶段最容易发现的问题错误信息也会直接提醒但提前自查总比跑了一半再中断好。第二件事是补丁类型匹配。标题写的是 database PSU应用目标是数据库软件的 ORACLE_HOME。如果环境是 RACgrid home 的补丁需要单独下载因为数据库补丁和 grid infrastructure 补丁是两个不同介质不能拿 database 包去套 grid home。只打数据库 home 而不动 grid home在版本差异过大的时候CRS 或集群资源启动仍然可能报错所以 RAC 环境下要把两个 home 的补丁号一起确认再做窗口计划。单机数据库则相对简单只需要处理这一个 home。第三件事是 OPatch 版本。p36575425 这一类季度补丁包在 README 里会标注最低 OPatch 版本如果当前 home 的 OPatch 版本太老apply 会直接中断。OPatch 是 Oracle 官方的补丁管理工具11.2.0.4 的 home 里通常带着一个老版本如果长期没打过补丁这个版本往往不满足新补丁要求。处理方式是在官方支持站点下载对应 11.2.0.4 的 OPatch 更新包替换到 $ORACLE_HOME/OPatch 后再继续。替换前把旧 OPatch 目录改名备份这是成本最低的后悔药。第四件事是既有补丁状态和依赖关系。通过 opatch lsinventory -detail 能看到当前 home 已安装的补丁列表有些补丁与 p36575425 存在相互依赖有些则产生冲突。如果 README 明确要求先打某个前置补丁就先安装前置如果补丁列表里存在已知冲突补丁需要先与支持确认是否可以共存或者先回滚冲突项。不要在 README 还没读透的情况下强行 apply补丁冲突引发的间接问题往往比表面报错更隐蔽轻则数据字典版本混乱重则实例起不来还要靠备份恢复。这四件事看起来分散其实统一起来就是一句话打补丁前先把环境边界摸清楚。确认好平台、类型、OPatch 版本和既有补丁状态之后再进入实际业务窗口整个补丁安装流程就只剩下标准操作。3. 把 p36575425 装进 ORACLE_HOME可复现操作链路3.1 打补丁前的备份与停机盘查打这种老版本 PSU窗口内的操作顺序有讲究顺序反了会在补丁替换二进制时收到“实例还在运行”之类的提示甚至直接引发启动异常。我一般按这个顺序走先确认实例状态再做备份然后停监听、关库最后检查没有 oracle 进程残留。单机数据库环境的核心命令如下sqlplus / as sysdba select name, open_mode from v\$instance; shutdown immediate; exit lsnrctl stop ps -ef | grep -E ora_pmon|ora_smon | grep -v grep代码里 v$instance 里的反斜杠是为了防止 shell 把 $instance 当成变量来展开如果你直接在 SQL*Plus 里执行写select name, open_mode from v$instance;就行。第一步先看 open_mode 和实例名确任当前操作的库没有连错shutdown immediate 会等待活动事务结束一般几十秒内完成lsnrctl stop 停掉监听避免补丁过程中有新的客户端会话建立最后的 ps 检查是为了确认没有 oracle 后台进程残留看到输出为空再继续。备份层面我通常做两层数据库层面用 RMAN 做一次全备文件层面把 ORACLE_HOME 下最容易受影响的配置目录和核心二进制目录单独打包。不用 tar 整个 ORACLE_HOME因为目录太大而且 tar 过程中如果还有进程在读写反而制造不一致。mkdir -p /backup/orahome_$(date %Y%m%d) cd $ORACLE_HOME tar czf /backup/orahome_$(date %Y%m%d)/cfg_backup.tar.gz dbs network/admin tar czf /backup/orahome_$(date %Y%m%d)/bin_lib_backup.tar.gz bin lib第一行用 date 命令生成当天日期目录防止多次操作时覆盖旧备份第二行进入 ORACLE_HOME第三行打包参数文件、密码文件、监听配置等关键配置第四行打包 bin 和 lib这两个目录是补丁替换文件最集中的区域。数据库层面做 RMAN 全备比数据泵更稳妥因为数据库实时在写数据泵的一致性需要额外处理RMAN 备份配合归档日志能给后续恢复提供一个可靠底线。3.2 解压补丁并执行 opatch apply补丁包下载下来通常是一个 zip 文件解压前确认文件权限正确解压出来的目录属主是 oracle。之后进入补丁目录执行 opatch apply。完整命令如下mkdir -p /u01/oracle_patches unzip -q p36575425_112040_Linux-x86-64.zip -d /u01/oracle_patches cd /u01/oracle_patches/36575425 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOMEunzip 的 -q 参数表示安静模式解压进度不刷屏-d 指定解压目标目录这里我用补丁号 36575425 作为解压后的目录名方便后续对照。cd 进入补丁目录后执行 opatch apply-oh 参数显式指定 ORACLE_HOME避免机器上有多个 home 时打错目标。apply 过程中 OPatch 会在 home 下创建 .patch_storage 目录把即将被替换的旧文件备份进去这就是前面说的空间风险点。执行日志不要只盯着最后一行。一般现场操作时输出会非常多我的习惯是把标准输出和错误输出重定向到日志文件cd /u01/oracle_patches/36575425 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME 21 | tee /tmp/opatch_36575425.log运行结束之后用 grep 在日志里搜索 Error、Warning、Conflict 这几个关键词任何命中都要先停下来分析不能因为最后出现 succeeded 就忽略。日志文件保留下来还有一个好处后续如果磁盘或文件层出现问题可以快速回看当时到底改了哪些文件。opatch apply 常见参数作用使用建议-oh指定目标 ORACLE_HOME 路径多 home 环境必须使用避免打错目录-silent静默模式不进行交互询问第一次打补丁不建议使用交互模式更直观补丁执行时间通常在 20 到 60 分钟之间取决于机器 IO 能力、home 大小以及历史补丁数量。如果打到一半报错先看日志里的具体阶段不要立即重跑同一个 apply确认失败原因后再决定继续还是回滚。3.3 SQL 后处理catbundle 与失效对象重编译二进制层补丁完成后数据字典还停留在旧版本必须执行 SQL 脚本来让数据库内部结构与新二进制对齐。11.2.0.4 的 PSU 后处理标准动作是执行 catbundle.sql脚本位于 $ORACLE_HOME/rdbms/admin。先启动数据库到 open 状态再以 sysdba 身份执行cd $ORACLE_HOME/rdbms/admin sqlplus / as sysdba SQL startup; SQL catbundle.sql PSU apply SQL ?/rdbms/admin/utlrp.sql SQL select count(*) from dba_invalid_objects where owner not in (SYS,SYSTEM);startup 将实例拉起来catbundle.sql 后面的两个参数PSU 表示本次处理的是 PSU 补丁apply 表示执行应用方向不是回退方向utlrp.sql 是重编译失效对象的脚本可以反复执行直到 invalid 数量稳定下降不再变化。catbundle 执行过程中会在 rdbms/log 目录下生成日志文件日志里如果出现 ORA- 或 ERROR 字样一定要逐条查不能忽略。这里要特别提醒11.2.0.4 的 PSU 后处理方式和 19c 不同没有自动的 datapatch 帮你兜底必须手动执行 catbundle。执行时数据库必须处于 open 状态如果误在 mount 状态下跑了一半建议把库重启到 open 再完整执行一遍。有人图省事只跑 catbundle 不跑 utlrp结果 invalid 对象残留业务存储过程执行时报内部错误回头再补脚本反而更费窗口。3.4 重启监听与实例让补丁状态生效SQL 阶段完成后需要把监听和实例按正常方式拉起来让所有会话都基于新版本运行。单机环境的启动序列是sqlplus / as sysdba SQL startup; SQL select status from v\$instance; exit lsnrctl start lsnrctl statusstartup 后实例会用替换过的新二进制启动v$instance.status 显示 OPEN 就说明启动成功lsnrctl start 拉起监听lsnrctl status 查看服务状态。如果这里发现动态注册失败多半是 listener.ora 里写的 ORACLE_HOME 指向了别的目录或者监听服务名配置不匹配优先检查网络配置文件不需要重打补丁。到这个阶段已经完成了补丁安装的主体工作但还是不要急着关窗口。下一步需要做补丁状态验证因为文件层补丁成功和数据字典补丁成功是两个独立事件必须在同一个窗口里同时确认。3.5 打完立刻验证三处状态要一致补丁打完至少要验证三个位置文件系统里的补丁记录、数据字典里的 registry$history、运行中的实例状态。第一处用 opatch lsinventory 查看第二处用 registry$history 查询第三处通过 SQL*Plus 查看实例版本。$ORACLE_HOME/OPatch/opatch lsinventory | grep -E 36575425|Patch description sqlplus -S / as sysdba EOF set lines 160 col ACTION format a10 col NAMESPACE format a12 col ID format a15 select ACTION, NAMESPACE, ID, ACTION_TIME from registry\$history where ID like %36575425%; EOF第一段命令在补丁清单里查找 36575425能看到这条补丁记录就说明文件层已经标记完成第二段查询数据字典历史表返回一条 ACTION 为 PATCH 的记录标明数据字典已经升级到对应版本。两个查询结果同时存在并且 ID 与补丁号一致才算真正成功。如果 lsinventory 有记录但 registry$history 没有说明 SQL 后处理漏了或没生效反过来只有 registry$history 记录但 lsinventory 看不到通常意味着补丁文件和 home 目录对不上。两边都确认完再去看业务会话和查询是否正常。4. 打 p36575425 的避坑清单现象、排查与解决4.1 OPatch 版本过低apply 开始几分钟就退现象执行 opatch apply 后短时间内输出一段环境检查结果然后报 “OPatch version is too low” 或 “Prerequisite check failed”进程直接退出补丁目录中没有生成完整的 apply 日志。原因很多 11.2.0.4 的 ORACLE_HOME 从部署后就没更新过 OPatch而 p36575425 这类季度补丁对 OPatch 有最低版本要求另外某些环境曾经用低版本 OPatch 手工改过补丁记录导致 inventory 元数据不干净也会触发前置检查失败。解决先跑opatch version记录当前版本再从官方支持站点下载适配 11.2.0.4 的 OPatch 更新介质解压后覆盖到 $ORACLE_HOME/OPatch。覆盖之前把旧 OPatch 目录整体改名备份比如 mv OPatch OPatch_bak_20240717。替换完成后重新执行opatch version确认版本号上涨再回到补丁目录重新 apply。注意不要只把新 OPatch 放在临时目录里手动指定路径执行因为补丁前置检查会直接读取 ORACLE_HOME/OPatch 下的元数据文件覆盖到正确位置才有效。4.2 实例没停就 apply二进制替换后启动报错现象apply 过程中提示实例还在运行或某些文件被占用有的环境直接覆盖成功但随后 startup 时报加载共享库失败或者实例起一半就退出。原因运行中的 oracle 进程占用了原有二进制文件opatch 替换文件时要么写不进去要么写进去后新旧文件混用进程没有退出共享库缓存也没有刷新导致启动瞬间读取到的二进制状态不一致。解决apply 前必须按顺序执行lsnrctl stop和shutdown immediate再用ps -ef | grep -E ora_pmon|ora_smon确认没有 oracle 后台进程残留。如果已经中招先把补丁回滚到上一版本确认实例能正常启动后再重新走标准流程不要尝试在不一致的二进制上继续叠加操作那样故障现场会越搞越复杂。4.3 postinstall SQL 漏跑或只跑了一半现象补丁记录显示已应用但查询 dba_invalid_objects 有大量 INVALID 对象业务存储过程执行时报ORA-06553: PLS-801: internal errorv$instance 启动正常但应用侧调用异常。原因文件层补丁打完数据字典版本没跟上或者执行 catbundle.sql 时数据库没有处于 open 状态导致脚本中途退出而现场人员只看了补丁 apply 状态就关闭窗口。解决先确认数据库 open再完整执行 catbundle.sql PSU apply然后执行 utlrp.sql 重编译。执行时盯住 rdbms/log 下最新生成的日志文件搜索 ORA- 和 ERROR。补跑完成后重新查询 dba_invalid_objectsinvalid 数量应明显下降如果有对象仍然失效再根据对象的 owner 和 type 逐条排查。这个坑在 11.2.0.4 上特别容易踩因为很多人的习惯是从 19c 时代带来的以为打补丁会自动跑 SQL。4.4 回滚不是后悔药文件层和字典层要分开处理现象补丁应用过程中出现问题现场直接执行opatch rollback回滚完成后启动实例报版本不匹配或者数据字典里的对象和二进制对不上。原因OPatch 回滚只回滚文件层把二进制还原到补丁前版本但如果此时已经跑过 catbundle.sql数据字典已经记录了补丁版本的对象变更旧二进制加载新字典就会出现不一致。反过来先回滚文件再回滚字典顺序错了也会出问题。解决回滚前先看补丁 README 里有没有提供专门的回滚 SQL如果已经执行过数据字典变更回滚动作必须包含对应的字典回滚步骤。实际操作中如果应用阶段状态已经不明朗我一般不会依赖回滚而是使用窗口前的 RMAN 备份恢复数据库再重新验证版本状态。回滚适合文件层明确失败、字典层尚未动过的场景不适合字典变更执行了一半的现场。4.5 磁盘空间被 .patch_storage 耗尽现象opatch apply 进行中报 “No space left on device” 或 “Unable to create ... .patch_storage/backup”补丁中止ORACLE_HOME 目录出现半完成状态。原因OPatch 在替换文件前会把要覆盖的文件复制到 $ORACLE_HOME/.patch_storage这个备份目录和 ORACLE_HOME 位于同一文件系统。打补丁前只看了补丁 zip 包的大小没算 bin、lib 等目录现有文件的体量空间准备不足。解决打补丁前用df -h $ORACLE_HOME查看文件系统可用空间除了补丁包以外还要预留 bin/lib 被替换文件的备份空间至少留出数 GB 余量。如果已经中招先看当前补丁记录处于什么状态再用支持工具判断是继续 apply 还是清理重来不要用 root 直接删除 .patch_storage 目录下的文件权限错乱会带来二次问题。更稳妥的做法是先备份当前状态再腾出空间后重新执行 apply因为 OPatch 会跳过已经完成的前置步骤继续。5. 验证不只靠 lsinventory补丁落库后的检查习惯5.1 给验证加一道 registry$history 的基线打完 p36575425 之后光看 opatch lsinventory 是不够的。REGISTRY$HISTORY 记录了每个数据库经历过的补丁动作PSU 打完后这里会多出一行 ACTION 为 PATCH 的记录。我每次打完补丁都会记下这行的 ID、ACTION、ACTION_TIME因为它比 lsinventory 更能代表当前运行的数据库实际处于什么补丁状态。文件层补丁完成但 SQL 后处理漏跑时这条记录不会出现只有它存在且 ACTION 为 PATCH数据字典才算真正更新到位。sqlplus -S / as sysdba EOF set lines 160 col ACTION format a10 col NAMESPACE format a12 col ID format a15 select ACTION, NAMESPACE, ID, ACTION_TIME from registry\$history where ID like %36575425%; EOFID 列对应补丁包内的补丁号ACTION 列显示 PATCHACTION_TIME 是 SQL 后处理完成的时间点。如果查出来的 ACTION_TIME 比实际打补丁时间早很多说明你看到的是历史记录而不是本次应用记录需要再核对补丁包的日期版本。5.2 把验证固化为一个检查脚本我在维护 11.2.0.4 库时把补丁验证做成一个小函数打完补丁直接调用三个检查结果都正常才宣布窗口结束。脚本骨架如下check_psu() { local psu_id$1 echo 1. opatch lsinventory $ORACLE_HOME/OPatch/opatch lsinventory | grep ${psu_id} || echo NOT FOUND in opatch echo 2. registry\$history sqlplus -S / as sysdba EOF set heading off feedback off select PATCH_IN_DB||count(*) from registry\$history where id${psu_id} and actionPATCH; EOF echo 3. invalid object count sqlplus -S / as sysdba EOF select INVALID_CNT||count(*) from dba_invalid_objects; EOF }调用方式是check_psu 36575425。第一个检查确认文件层补丁记录第二个检查确认数据字典层补丁记录第三个检查观察失效对象数量是否在合理范围。脚本里 registry$history 的反斜杠是为了防止 shell 把 $history 当作变量展开。补丁状态三处一致之后再让应用连接做一次正常会话和查询确认没有权限或对象错误就可以关闭维护窗口。这个习惯让我在多次打补丁中都没有翻车少跑一次检查就多一分隔天被业务问起来的风险。希望帮到你。本文还有配套的精品资源点击获取