企业官网建设流程全解析

简介：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 的区别：为什么生产环境最终选了 PSU

Oracle 的季度补丁体系有过几次演变。11.2.0.4 时代最常见的是 PSU（Patch Set Update），也就是季度补丁集更新，累积了上一个 PSU 以来的安全修复和少量高价值 bugfix，经过完整测试后发布。CPU（Critical Patch Update）则更偏向安全补丁，只修安全漏洞，不包含功能性修复。到了 12.2 以后，Oracle 又用 RU（Release Update）和 RUR（Release 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 从补丁文件名读出全部关键信息

这个标题的补丁文件名信息量很大，拆解一下：

这里最容易被忽略的是版本号简写 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.log（0 是数据库编号，单实例通常是 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.sql

RAC 环境要注意：字典升级只需要在其中一个节点做一次，不需要每个节点都跑 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 里 STATUS='INVALID' 的对象数量，确认降到个位数以内。

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 status='INVALID'; 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 天，确认补丁运行稳定后再清理备份，这个后悔药不能提前扔。希望帮到你。

本文还有配套的精品资源，点击获取