Oracle 11.2.0.4 PSU补丁p36575425安装实战指南

简介Oracle 11.2.0.4.240717 是针对 64 位 Linux 平台的数据库补丁集亦是官方于 2024 年 7 月发布的 PSU补丁集更新p36575425面向 Oracle 11.2.0.4 数据库管理员与运维人员。该版本属长期支持系列新增关键安全修复、稳定性改进与性能优化适合正在维护生产环境或准备升级补丁的 DBA 使用。压缩包共 2000 个文件容量 536.32MB以 .o 目标文件、.so 共享库、.sql 补丁脚本、.xml 元数据等为主可配合 opatch 完成 PSU 部署。已有 938 人浏览/学习。通过获取此包可一次性拿到截至 2024 年 7 月的累积修复内容避免逐月收集补丁包内结构完整适合在测试环境先行演练后再对生产库打补丁有助于降低升级风险。1. 2024 年还在给 11.2.0.4 续命的 DBA都在盯这个补丁包手头还有 Oracle 11.2.0.4 库的同行想必都有同感版本早过了 Premier Support但业务系统就是动不了数据库得继续跑安全漏洞也不能不修。这个标题里的 oracle 11.2.0.4.240717.Linux64 补丁集 database PSU p36575425-112040-Linux-x86-64就是 Oracle 在 2024 年 7 月 17 日发布的 11.2.0.4 季度补丁集更新。对还在生产环境维护老库的人来说这是每年要面对的例行操作也是唯一能同时补安全漏洞和稳定性问题的途径。这篇文章不讲虚的直接拆解这个 PSU 补丁包的结构、打补丁的完整命令流以及我在 Linux 服务器上实操时踩过的那些坑。2. 先看懂 p36575425 补丁包再决定要不要打2.1 PSU、CPU、RU 的区别为什么生产环境最终选了 PSUOracle 的季度补丁体系有过几次演变。11.2.0.4 时代最常见的是 PSUPatch Set Update也就是季度补丁集更新累积了上一个 PSU 以来的安全修复和少量高价值 bugfix经过完整测试后发布。CPUCritical Patch Update则更偏向安全补丁只修安全漏洞不包含功能性修复。到了 12.2 以后Oracle 又用 RURelease Update和 RURRelease Update Revision取代了 PSU 体系。但像 11.2.0.4 这类老版本官方仍然以 PSU 形式持续发布安全补丁直到 Extended Support 彻底结束。为什么生产环境最终都选 PSU 而不是只打 CPU原因很实际CPU 补丁覆盖范围窄只修安全漏洞但生产库跑久了总会遇到一些 Oracle 内部 bug比如 ORA-600、ora-04031这些同样需要修。PSU 是累积的把之前多个季度的问题修复一起收进来测试一次就覆盖了所有已知问题。代价是 PSU 涉及的文件多、变更面大打完后需要更新数据字典至少要经历一次停库和重启。我在生产环境的原则是不追最新只看补丁包发布日期和自身维护窗口。像 p36575425 这种命名里带 240717 的说明是 2024 年 7 月 17 日发布的补丁那它包含的是 2024 年 4 月及之前的已知问题修复。如果你的库已经滞后一两个季度直接打最新的 PSU 通常是最省事的因为它是累积的不用一个个按顺序补。2.2 从补丁文件名读出全部关键信息这个标题的补丁文件名信息量很大拆解一下文件名片段含义oracle 11.2.0.4Oracle 数据库 11g R2 的 11.2.0.4.0 基础版本240717补丁发布日期格式 YYMMDD即 2024 年 7 月 17 日Linux64目标平台为 64 位 LinuxPSU补丁类型为 Patch Set Updatep36575425补丁编号MOS 文档里搜这个号能找到对应的 README112040版本号简写对应 11.2.0.4.0Linux-x86-64平台架构的详细写法x86-64 架构这里最容易被忽略的是版本号简写 112040。有的 DBA 会把它和补丁号搞混实际上它代表的是这个补丁适用的数据库版本基线。如果你的库是 11.2.0.4那这个补丁一定能打如果库是 11.2.0.3 或更早就必须先升级基础版本不能直接跳级打补丁。p36575425 是补丁的唯一标识在 Oracle Support 网站上搜索这个编号可以下载到 zip 包以及对应的 README.html 说明文档。补丁包下载下来后我的习惯是先看 README不看清楚不碰生产。README 里会写明本补丁包含的 bug 修复列表、推荐的 opatch 最低版本、已知问题以及 RAC 环境下的打补丁方式。这些信息比任何第三方教程都准确。2.3 打补丁前必须完成的五个检查项很多翻车现场在检查阶段就能避免。我在打 p36575425 这类 PSU 前固定执行以下检查缺一不可# 1. 确认数据库版本是 11.2.0.4 sqlplus -s / as sysdba EOF select version from v\$instance; EOF # 2. 检查 OPatch 版本是否满足补丁要求 $ORACLE_HOME/OPatch/opatch version # 3. 检查 ORACLE_HOME 磁盘空间是否充足建议至少留 3-5GB df -h $ORACLE_HOME # 4. 检查数据库所有实例的运行状态 ps -ef | grep pmon | grep -v grep lsnrctl status # 5. 检查 sys/system 用户是否锁定、数据库是否开启归档 sqlplus -s / as sysdba EOF select log_mode from v\$database; select username, account_status from dba_users where username in (SYS,SYSTEM); EOF这几个检查项的逻辑是版本不符会导致打补丁直接被拒OPatch 版本过旧会让补丁脚本无法解析补丁内容ORACLE_HOME 空间不足会导致解压失败或打到一半中断数据库实例还在运行会导致文件被占用归档模式未开启则无法在打补丁前做完整的备份。我见过最典型的翻车是有人跳过了 OPatch 版本检查结果 opatch apply 一开始就报 OPatch version is older than the minimum required整个维护窗口白白浪费掉。补充一个细节11.2.0.4 的 PSU 补丁包要求 OPatch 版本不低于 11.2.0.3.32但具体还是要以 README 里的要求为准。如果本机 OPatch 版本不够需要先从 MOS 下载对应的 opatch 工具更新这属于补丁包之外的前置操作。3. 在 Linux64 上打 p36575425从停库到字典升级的完整命令流3.1 环境准备备份、克隆 ORACLE_HOME、检查 opatch打 PSU 第一件事不是停库而是备份。PSU 补丁会替换掉 ORACLE_HOME 下的大量二进制文件一旦中途失败回滚虽然可行但过程痛苦。我给生产库打补丁的常规做法是先做一个 ORACLE_HOME 的冷克隆再配合数据库全量备份双保险。# 以 oracle 用户执行先记录当前环境 echo $ORACLE_HOME echo $ORACLE_SID # 停掉数据库和监听 sqlplus / as sysdba EOF shutdown immediate; exit; EOF lsnrctl stop # 备份 ORACLE_HOME按实际路径修改注意排除备份文件本身 tar -czf /backup/oracle_home_before_psu_$(date %Y%m%d).tar.gz \ --exclude$ORACLE_HOME/dbs \ --exclude$ORACLE_HOME/network/log \ -C / $ORACLE_HOME这里把 dbs 和 network/log 排除掉是因为这两个目录存放的是实例参数文件、密码文件、监听日志等运行时数据每天都有变化不属于补丁涉及的文件范围不需要备份。补丁本身不会改动 spfile 和密码文件所以排除后备份大小能小一截恢复时也不会影响实例配置。备份完成后再次确认 OPatch 版本和补丁解压后的路径。补丁包解压不要放在 ORACLE_HOME 里面我一般放在 /u01/app/psu 或 /tmp 下避免补丁文件被误判为 ORACLE_HOME 的组成部分。# 解压补丁包p36575425 是补丁编号 cd /u01/app/psu unzip -q p36575425_112040_Linux-x86-64.zip ls -la 36575425/ # 检查补丁目录里的内容 cat 36575425/etc/config/actions.xml | head -50退出码 0 才算成功这一步解压失败通常说明 zip 包损坏或磁盘空间不足。查空间用 Linux 常用命令 df -h 即可不用额外工具。解压后看补丁目录里的 actions.xml能大致了解补丁会改动哪些文件、触发哪些动作虽然日常不需要逐个读但遇到 apply 阶段报错时这个文件是排查线索之一。3.2 停库与打补丁opatch apply 的参数和输出怎么看备份完成了接下来进入真正的补丁应用阶段。这一步的核心命令是 opatch apply但打得稳不稳取决于前面的准备是否到位。# 确认数据库处于 shutdown 状态 ps -ef | grep pmon | grep -v grep # 进入补丁目录执行 apply cd /u01/app/psu/36575425 $ORACLE_HOME/OPatch/opatch apply -silent # apply 成功时的日志关键行 # Verifying the patch... Done. # Patch 36575425 successfully applied.opatch apply -silent 是非交互模式不在终端里逐条提问适合维护窗口内无人值守执行。但生产环境我更推荐先直接跑一次 opatch apply不带 -silent让它在询问阶段停下来确认问题后再交互确认。二者的区别在于silent 模式如果遇到需要人工选择的场景会直接失败交互模式则有回旋余地。不过 opatch 在检测到冲突补丁或前置条件不满足时会主动报错退出所以遇到错误先读日志不要反复重试。apply 过程会先做冲突检测检查补丁包要覆盖的文件是否已经被其他补丁改过。如果有冲突opatch apply 会直接报 Patch has a conflict with already installed patch 并停止。这种情况通常说明库上已经手动打过某个单独补丁而这个补丁的修复已经被包含在 PSU 中需要先把旧补丁 rollback 再 apply。我遇到过多次处理方式是在 MOS 上查冲突补丁的文档按说明回滚旧的再重新 apply PSU。apply 完成后opatch lsinventory 可以用来验证补丁是否已经记录在 inventory 里。但注意二进制层面打完了数据字典还没升级此时直接启动数据库会报错或产生失效对象所以不能急着开库。3.3 更新数据字典catcon.pl 的正确用法和常见参数PSU 打完后必须更新数据字典把新增或变更的内部对象同步到数据库里。11.2.0.4 环境下Oracle 提供的标准做法是用 $ORACLE_HOME/rdbms/admin 下的 catcon.pl 脚本执行 catupgrd.sql。这个步骤如果漏掉数据库可以启动但后续会出现各种诡异的内部错误比如 ORA-06553、PLS-00201 等。# 以 oracle 用户启动数据库到 upgrade 模式 sqlplus / as sysdba EOF startup upgrade; exit; EOF # 执行字典升级脚本-b 指定日志前缀-c 指定连接串 cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catcon.pl -b catupgrd -d $ORACLE_HOME/rdbms/admin catupgrd.sql # 升级完成后重启数据库到正常模式 sqlplus / as sysdba EOF shutdown immediate; startup; EOF这里有几个参数很关键。catcon.pl 脚本是用 Perl 写的11.2.0.4 自带 Perl 环境直接调用 $ORACLE_HOME/perl/bin/perl 是为了避免系统 Perl 版本不兼容导致的执行失败。catupgrd.sql 是用 upgrade 模式执行的它会创建新的字典对象并把旧的字典信息迁移过来这个过程不能在中途被打断否则数据库字典可能处于不一致状态。catcon.pl 执行完毕后可以查日志确认是否有报错。日志文件叫 catupgrd0.log0 是数据库编号单实例通常是 0存放在当前目录下。用 Linux 常用命令 grep 搜一下关键字grep -iE error|ora- catupgrd0.log | grep -v ORA-00000 | head -30这个过滤器是排除 ORA-00000 正常退出码把真正需要关注的错误列出来。没有命中说明字典升级这一关过了。字典升级耗时取决于库的大小小库几分钟几十 GB 以上的库可能半小时维护窗口要提前预估。3.4 RAC 环境滚动打补丁节点差异与参数说明RAC 环境打 PSU 的情况比单实例复杂但也是实际生产中最常遇到的场景。11.2.0.4 的 PSU 支持滚动打补丁即一次只打一个节点不影响整个集群的对外服务。滚动打补丁会让被打节点的实例先关闭其他节点继续对外提供服务打完当前节点再切到下一个节点。整个过程中只有一个短暂的全库窗口在最后一个节点重启实例后。# 节点 1 执行 apply先停当前节点实例 sqlplus / as sysdba EOF shutdown abort; exit; EOF cd /u01/app/psu/36575425 $ORACLE_HOME/OPatch/opatch apply # 节点 1 的二进制补丁完成后先在节点 1 执行字典升级 # 然后启动节点 1 实例切换业务连接 sqlplus / as sysdba EOF startup upgrade; exit; EOF cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catcon.pl -b catupgrd -d $ORACLE_HOME/rdbms/admin catupgrd.sqlRAC 环境要注意字典升级只需要在其中一个节点做一次不需要每个节点都跑 catupgrd.sql因为字典是集群共享的。但 opatch apply 必须在每一个节点都执行因为 ORACLE_HOME 在 RAC 环境里是各节点独立的。实际操作顺序是节点 1 停实例、apply、启动到 upgrade、跑字典升级、重启到正常再在节点 2 停实例、apply、启动实例。整个过程只要有一个节点因为 CRS 资源管理没配好导致启动不起来就会影响整个集群。RAC 滚动操作还有一个隐含风险Oracle Clusterware 可能因为实例关闭时间过长而触发资源重新定位操作前建议先把相关服务资源和监听的状态记录下来方便失败时排查。生产 RAC 库我一般不会在白天做这个操作哪怕支持滚动也尽量放在业务低谷期。4. 打 p36575425 的五个常见翻车现场现象、原因、解法4.1 磁盘空间足够opatch 却报 OUI-10082 空间不足现象df -h 显示 ORACLE_HOME 所在文件系统还剩 5GB明显够用但 opatch apply 一开始就报 OUI-10082提示空间不足。原因opatch 检测的不只是补丁文件本身的空间它还会预约一份操作用临时空间用于补丁应用过程中的文件备份和回滚准备。11.2.0.4 的 PSU 体积不小加上备份可能超过预期。另外 ORACLE_HOME 下如果已经有历史补丁的 backup 目录这个空间会累积占用。解决用 df -h 确认空间后再看 $ORACLE_HOME/.patch_storage 目录的大小。这个目录存放打补丁的历史备份可以把要打的补丁之外的旧备份删掉释放空间。删之前确认目标补丁已经成功打上否则删了备份就无法回滚。我一般控制这个目录在 2GB 以内。4.2 OPatch 版本过旧报错信息直接拒绝 apply现象opatch apply 刚跑就退出提示类似于 OPatch version xx is older than the minimum required yy。原因11.2.0.4 的后期 PSU 对 OPatch 版本要求逐步抬高很多服务器上的 OPatch 还是两三年前部署的版本根本解析不了新补丁包的格式。解决先从 MOS 下载对应补丁要求的最低 OPatch 版本更新到 $ORACLE_HOME/OPatch 目录。更新前备份旧 OPatch 目录命令是 mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak。更新后再次执行 opatch version 确认版本号再继续后续操作。注意不要把 OPatch 备份到 $ORACLE_HOME 之外它需要与 ORACLE_HOME 在同分区否则权限和时间戳会出问题。4.3 字典升级后失效对象大批出现应用连接报错现象catcon.pl 执行完重启库业务系统报一堆存储过程和函数编译错误。原因11.2.0.4 的 PSU 会替换一部分内部包和 Java 类旧代码依赖的对象在新字典里暂时编译不通过需要重新编译。这个动作 Oracle 建议手动执行 utlrp.sql 而不是等应用调用时报错才编。解决在正常模式启动数据库后执行 $ORACLE_HOME/rdbms/admin/utlrp.sql然后查 dba_objects 里 STATUSINVALID 的对象数量确认降到个位数以内。4.4 RAC 滚动第二个节点 apply 失败日志提示 inventory 锁冲突现象节点 1 apply 成功轮到节点 2 时 opatch apply 报 Inventory is locked by another process。原因opatch 的 inventory 在集群环境下存在共享位置节点 1 的 apply 进程没有完全退出或者节点 2 上残留了旧的 opatch 进程。解决先确认节点 1 的 opatch 进程确实结束ps -ef | grep opatch。再检查节点 2 是否有僵尸进程用 kill -9 清理后重新 apply。这里我会用集群命令 crsctl stat res 确认节点 1 的实例状态避免实例还在跑就动第二个节点。4.5 打完后库起不来alert log 里全是 ORA-600现象启动数据库时实例能 mount但 open 阶段反复报内部错误起不来。原因一个常见情况是补丁.apply 完成后没有以 upgrade 模式启动就直接 open导致数据字典处于新旧不一致状态。另一个是数据库处于 RAC 环境但第二个节点还在用旧的二进制启动共享字典被旧代码写入。解决先把所有节点停到 nomount确认所有节点的 ORACLE_HOME 都已完成补丁应用再统一以 upgrade 模式启动并执行字典升级。这个规则我后来一直严格执行字典升级前集群内所有节点的二进制版本必须一致。5. 打完补丁别急着走三个验证命令和一个回滚技巧确认补丁成功的标准不是 opatch 打印 successfully applied 就完了那个只说明二进制替换完成。我按固定顺序做三个验证缺一不可。# 验证 1补丁已记录在 inventory 中 $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425 # 验证 2数据库字典无异常失效对象 sqlplus -s / as sysdba EOF select count(*) from dba_objects where statusINVALID; exit; EOF # 验证 3数据库状态与告警日志 sqlplus -s / as sysdba EOF select instance_name, status from v\$instance; select to_char(dest_id)||:||substr(status,1,20) from v\$archive_dest_status where status not in (DEFERRED); exit; EOF # 查看最近 200 行的 alert 日志有没有 ORA- 报错 tail -200 $ORACLE_HOME/diag/rdbms/*/trace/alert_*.log | grep -i error\|ORA-验证 1 确认补丁本身存在验证 2 确认字典完整性验证 3 确认实例状态和告警日志。如果失效对象多于两位数说明字典升级过程有问题再把 utlrp.sql 执行一次。回滚技巧我给一个血泪经验打完补丁后如果 24 小时内业务反馈异常需要回滚最稳妥的方式是使用 opatch rollback -id 36575425 恢复二进制然后重新以 upgrade 模式启动并跑一次字典回滚脚本。psu 的回滚脚本通常会在补丁包 README 里说明但生产环境建议直接采用恢复 ORACLE_HOME 备份 恢复数据库备份的方案因为 rollback 在 PSU 上有已知坑回滚不干净会导致二进制和字典版本不匹配反而更难恢复。我的备份保留策略是至少保留 7 天确认补丁运行稳定后再清理备份这个后悔药不能提前扔。希望帮到你。本文还有配套的精品资源点击获取