企业官网建设流程全解析

简介：面向 Oracle 数据库运维人员，2024 年 7 月发布的 11.2.0.4 补丁集（编号 p36575425）适用于 Linux x86-64 平台，用于修复 Oracle 数据库 11.2 系列在长期运行中暴露的安全漏洞与稳定性问题。压缩包约 536MB，包含 2000 个文件，主要类型为 o、so、xml、sql、jar、class 等，其中库文件与可执行组件支撑补丁安装，SQL 脚本和 XML 配置用于升级与校验。已有 944 人学习下载，适合负责生产库日常维护的 DBA 参考。该 PSU 整合了自上一补丁以来的关键修复，并附有 PatchSearch.xml 等元数据，可协助核对补丁信息、评估变更影响。由于 Oracle 11.2.0.4 属于长期支持版本，定期应用此类季度补丁是保障数据库安全合规、降低运行风险的重要措施。

1. 季度补丁集 p36575425：为什么 11.2.0.4 的 PSU 值得花一个维护窗口

还在维护 Oracle 11.2.0.4 单机或 RAC 环境的团队，对标题里的生产补丁集 p36575425（发布标识 240717，Linux x86-64 平台）应该不陌生。PSU 是季度安全修复与稳定性修复的打包产物，一次替换几十个二进制文件、几十个 Bug 修复，比逐个打 one-off patch 省心得多。这篇文章面向还在跑 11.2.0.4 的数据库管理员，目标不是背下 opatch 命令，而是把「下载核对 → 备份 → 冲突检查 → apply → SQL 变更 → 验证回滚」这条完整链路走通。

很多人不敢打 PSU，总把补丁安装当成玄学，怕打坏、怕回不去。实际 opatch 自带失败自动回滚机制，真正让维护窗口翻车的往往是准备不足，比如没备份 ORACLE_HOME、没做冲突检查、或者打完二进制忘了跑 SQL 脚本。下面我按自己的维护习惯，把整套流程从准备到收尾完整写一遍。

2. 动手前把三件事做扎实：备份、opatch 升级、补丁目录核对

2.1 备份 ORACLE_HOME：让后悔药在 apply 之前就生效

PSU 替换的是 ORACLE_HOME 下的二进制文件、脚本和部分配置文件，数据文件原则上不碰。但生产环境没有后悔药，一旦 apply 到一半主机断电或磁盘写坏，干净的 home 备份就是唯一退路。我一般会在补丁窗口开始前一小时做一次全量打包，而不是在 apply 前几分钟才动手。

mkdir -p /backup/psu_20240725 tar -czf /backup/psu_20240725/oracle_home_$(date +%Y%m%d_%H%M).tar.gz \ --exclude='$ORACLE_HOME/rdbms/dbs' \ $ORACLE_HOME

这里排除rdbms/dbs是因为里面放着参数文件、密码文件等运行时文件，它们不该被旧版本覆盖；如果你平时习惯把 spfile 放在 $ORACLE_HOME/dbs 下，排查问题时反而需要保留，这个排除项按实际环境取舍，拿不准就整个打包。归档完成后顺手做一次校验：

tar -tzf /backup/psu_20240725/oracle_home_*.tar.gz | tail -5 ls -lh /backup/psu_20240725/oracle_home_*.tar.gz

逻辑说明：tar 备份必须确认归档首尾文件都在，不能只看打包命令无报错就以为成功。补丁包本身是 zip，解压过程要临时空间；tar 备份同样要吃磁盘空间，所以备份前先确认/backup目录所在文件系统余量。$ORACLE_HOME在 shell 里必须能展开，用echo $ORACLE_HOME验证一次，很多环境变量没 export 导致备份了空目录，这种坑我踩过不止一次。

2.2 先升级 opatch：旧版工具装不进新补丁

11.2.0.4 默认自带的 OPatch 版本很老，面对 2024 年的季度 PSU 经常直接报不支持。补丁包里不会附带新版 opatch，需要单独从官方支持站点获取。先检查当前版本：

$ORACLE_HOME/OPatch/opatch version

期望输出类似OPatch Version: 11.2.0.4.x。如果版本是 11.2.0.0.0 或明显低于补丁要求，先备份旧 OPatch 目录，再覆盖安装新版：

mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak_20240725 unzip -q p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME

参数说明：p6880880是 OPatch 工具的通用补丁号，它不区分数据库版本，只区分平台，所以解压回$ORACLE_HOME即可。覆盖后马上复验版本号，别等 apply 时才暴露问题。旧的OPatch.bak目录别急着删，等整个 PSU 窗口结束、确认无回滚需求再清理。

这里有个常被忽略的细节：OPatch 升级后，$ORACLE_HOME/OPatch/opatch的权限和属主必须保持 oracle:oinstall，工具解压默认保留 zip 内权限，如果之前目录权限被改过，解压后要chown -R oracle:oinstall $ORACLE_HOME/OPatch，否则后续所有 opatch 命令都会以权限报错开始。

2.3 核对补丁号、平台和校验值：货不对板是补丁安装的第一道坑

标题里的p36575425-112040-Linux-x86-64已经写明了补丁号、版本和平台，但下载过程经常出岔子。解压前先做 MD5 校验，以官方发布页给出的校验值为准：

md5sum p36575425_112040_Linux-x86-64.zip

解压后进入补丁目录，确认结构完整：应有etc/、files/、Install/等目录。用cat etc/config/actions看一眼平台信息，或者直接看README开头几行。重点检查两点：一是补丁目录名与-phBaseDir指向一致；二是解压后的文件属主是否为 oracle。很多人用 root 解压，导致补丁文件属主变成 root，opatch apply 时权限校验直接失败。

压一个常见情况：实际生产环境下载的补丁包可能是从某个内部共享服务器拷贝的，拷贝过程丢文件或损坏是常事。解压后检查files/目录里文件数量是否和发布说明一致，或者跑一次find files -type f | wc -l做个粗略校验。这一步不花多少时间，但能避免维护窗口进行到一半才发现补丁包不完整。

3. 冲突检查与空间校验：让 opatch 在动手前替你踩一半的坑

3.1 用 CheckConflictAgainstOHWithDetail 检查补丁冲突

opatch 的 prereq 子命令能在不动二进制的前提下检查补丁与当前 ORACLE_HOME 的兼容性。我每次都会做两层检查：先是通用的 conflict check，再是 detail 级别。命令如下：

cd $ORACLE_HOME/OPatch ./opatch prereq CheckConflictAgainstOHWithDetail \ -phBaseDir /tmp/p36575425 \ -invPtrLoc /etc/oraInst.loc

参数说明：-phBaseDir指向解压后的补丁目录，不能用 zip 文件路径；-invPtrLoc指定 oraInst.loc 的位置，很多机器上它在/var/opt/oracle/oraInst.loc，不确定就cat /etc/oraInst.loc先确认。prereq只检查不落盘，输出末尾如果出现Prereq "checkConflictAgainstOHWithDetail" passed.说明没有冲突，可以继续。如果出现Conflict列表，直接进 3.2 处理。

注意这个检查只针对「当前 ORACLE_HOME 已安装的补丁」与「新补丁」之间的冲突，不检查数据库实例级兼容性，所以它不能替代后续的启动验证。它最大的价值是在 apply 之前把「打不上 / 必须回滚旧补丁」这类问题提前暴露出来，避免维护窗口白开。

3.2 冲突时先处理存量补丁，再谈新 PSU

检查报告里一旦出现冲突，最常见的场景是：这个 ORACLE_HOME 里先前打过 one-off patch，而新 PSU 已经包含了该 one-off 修复，于是 opatch 认为两份变更针对同一对象，拒绝继续。这时候不要硬闯，先看冲突明细：

./opatch lsinventory

lsinventory 列出当前已安装补丁列表，把冲突的 one-off 补丁号找出来。处理策略很直接：先用opatch rollback -id <旧补丁号>撤掉 one-off，再重新跑 CheckConflict。如果 one-off 的修复确实已经进入新 PSU，回滚后不需要再补打；如果 PSU 发布说明里没包含它，就需要在 PSU 应用完成后重新以 one-off 方式叠加。

还有一个容易误判的场景：多个 PSU 之间的冲突。严格来说 PSU 是累积包，新版 PSU 应当包含旧版 PSU 的全部内容，但 opatch 检测到两个 PSU 同时存在时同样会拒。常规操作是先 rollback 旧 PSU 再 apply 新 PSU，不要试图同时保留两份。这里提前做 lsinventory 的价值就出来了，它让你在窗口前就知道要预留多少回滚时间。

3.3 dryRun 与空间检查：别让 ORACLE_HOME 在应用中途报磁盘满

apply 之前的第二道保险是 dry run。它模拟整个应用过程但不实际替换文件，常见命令是：

./opatch apply -phBaseDir /tmp/p36575425 -dryRun

执行完看输出里的Dry Run successful字样。dryRun 会占用短暂时间，并且会访问 oraInventory，所以不要在业务高峰期跑。它虽然做完整流程预演，但不会检测所有文件拷贝目标的空间余量，因此还要手工查磁盘：

df -h $ORACLE_HOME du -sh /tmp/p36575425

参数说明：df -h看的是 ORACLE_HOME 所在文件系统剩余空间，du -sh看补丁包大小。只装一个 PSU 时空间风险不大，但如果同一窗口还要叠加 opatch 升级、补丁解压、tar 备份，三者峰值都在同一文件系统上，空间就可能吃紧。我给自己定的经验线：ORACLE_HOME 所在分区剩余空间要大于补丁目录大小两倍以上，否则先扩容或清理旧日志再开窗口。

空间检查属于那种“不做没事、做了才放心”的步骤。真在 apply 中途写满磁盘，opatch 会尝试自动回滚，但回滚本身也需要空间，两个动作同时挤占磁盘，结局往往是被迫手工修复 inventory。提前 5 分钟跑一趟 df，能省掉后面 5 小时。

4. 核心维护窗口：停库、apply、catbundle 的先后顺序

4.1 停实例和监听，把文件替换环境攥在自己手里

opatch apply 会直接覆盖 ORACLE_HOME 下的运行文件。只要数据库实例还开着，进程就会占用或缓存旧二进制，替换出去轻则起库报错，重则文件被破坏。所以标准顺序是：通知业务方后关闭实例，再停监听。

sqlplus / as sysdba SQL> shutdown immediate; SQL> exit lsnrctl stop LISTENER

shutdown immediate 会等待当前事务结束，业务高峰期可能卡住很久。如果设置了维护窗，最好在窗口开始前 15 分钟就发 shutdown 命令，给事务收尾留余量。结束后确认进程真的没了：

ps -ef | grep pmon | grep -v grep

这条命令应该没有任何输出。如果有，说明实例还在，强制 kill 前先确认是否卡在 checkpoint 等合法阶段，不要一上来就 kill -9。监听同理，ps -ef | grep tnslsnr | grep -v grep应为空。

这里要把一个顺序说清楚：先实例后监听，不要颠倒。实例关闭时还要通过监听处理的连接，早停监听会导致 shutdown immediate 期间新连接进不来，反而拖慢收尾。RAC 环境则要逐节点处理，不能用同一 ORACLE_HOME 直接对两个节点同时 apply，通常的做法是先在第一个节点停掉该节点的 ASM 和 DB 资源，完成后再切到下一个节点。

4.2 opatch apply 的执行参数与日志解读

环境干净、备份在手、冲突检查通过后，正式应用命令其实很简短：

cd $ORACLE_HOME/OPatch ./opatch apply \ -phBaseDir /tmp/p36575425 \ -invPtrLoc /etc/oraInst.loc

参数说明：-phBaseDir后跟补丁解压目录；-invPtrLoc是 oraInst.loc 的绝对路径。如果机器上只装了一套数据库，-invPtrLoc有时可以省略，但多套环境共存时省略会导致 opatch 找错 inventory，后果是补丁打到别的 ORACLE_HOME 上，所以这个参数我从来都是显式写。apply 过程中屏幕会滚动大量输出，最后一段通常是补丁清单和耗时统计，看到OPatch succeeded即成功。

执行耗时一般在 5～15 分钟，取决于机器性能和补丁体积。中途断掉不要慌，opatch 会自动回滚，但回滚结束后也要看日志确认是否真回到了应用前状态。日志位置固定：

ls -lt $ORACLE_HOME/cfgtoollogs/opatch/ | head -3

最新的那个 opatch_*.log 就是对应当前会话的日志。用这几个关键字定位结果：

grep -E "OPatch succeeded|Return Code = 0|OPatch failed|WARNING" \ $ORACLE_HOME/cfgtoollogs/opatch/opatch_*.log | tail -10

逻辑说明：OPatch succeeded与Return Code = 0缺一不可。只出现 succeeded 而 Return Code 非 0 是异常状态，需要继续排查；出现 FAILED 则说明自动回滚已触发，下一步不是重试 apply，而是看日志定位根因。apply 成功后先别急着启动实例，下面还有 SQL 变更要做。

4.3 启动实例并执行 catbundle.sql 完成数据字典升级

二进制替换完之后，数据字典版本还停留在旧版。11.2.0.4 的 PSU SQL 部分不是 12c 之后的 datapatch 机制，而是用 catbundle.sql 应用。这一步最容易被新手跳过，跳过的后果就是数据库能启动但行为异常，甚至部分新特性直接不可用。标准做法：

sqlplus / as sysdba SQL> startup upgrade; SQL> @$ORACLE_HOME/rdbms/admin/catbundle.sql psu apply

startup upgrade以升级模式打开数据库，允许数据字典版本变更；catbundle.sql后面的psu apply两个参数告诉脚本要应用 PSU 补丁集。脚本执行时间通常 10～30 分钟，执行完后退出 SQL*Plus，查看生成的日志：

ls -lt $ORACLE_HOME/rdbms/admin/catbundle_*.log | head -3 grep -E "ORA-|Error" $ORACLE_HOME/rdbms/admin/catbundle_PSU_*.log | tail -20

日志文件命名规则是catbundle_PSU_<SID>_<时间戳>.log，搜到 ORA- 错误要逐条分析，常见的 ORA-00942 等往往是因为脚本在非 upgrade 模式下跑导致缺对象。确认无误后关库，恢复正常模式再启动：

sqlplus / as sysdba SQL> shutdown immediate; SQL> startup;

最后把监听拉起来。顺序上先实例后监听，和 4.1 的逻辑对应。至此二进制和数据库字典两边都到位了。

5. PSU 安装避坑记录：五个翻车场景与排查路径

5.1 opatch 报权限不足或 inventory 被锁

现象：执行opatch apply时提示Unable to lock inventory，或者直接报Permission denied，甚至部分 OUI-10060 类错误。

原因：最常见的是 oracle 用户对$ORACLE_HOME/oraInventory没有写权限，或者这个目录被 root 解压的补丁文件污染了属主。还有一种闹心情况：另一个 opatch 进程正在跑，inventory 锁还没释放。

解决：先查ls -ld $ORACLE_HOME/oraInventory确认属主，chown -R oracle:oinstall修正；再看ps -ef | grep opatch | grep -v grep，如果有残留进程等它结束再重试。还把$ORACLE_HOME/.patch_storage或者.inventory_backup目录权限检查一遍，这些目录权限错了同样会锁死 inventory。

5.2 apply 提示已有补丁冲突，但事前检查没发现

现象：预检查时 CheckConflict 通过，正式 apply 却报conflicts with patches already applied。

原因：预检查时-invPtrLoc指向了错误的 oraInst.loc，检查的是另一个 ORACLE_HOME 的 inventory；或者检查之后有人同期打了一个 one-off patch，动作串了。

解决：先跑opatch lsinventory确认真实环境里到底有哪些补丁，再比对冲突列表。确认当前 home 里有存量 one-off 时，按 3.2 的方式先 rollback 再重试。排查中要特别留意输出里的Home路径，前置检查的 Home 和 apply 的 Home 不一致是这类问题的根源。

5.3 二进制替换成功，实例启动报内部错误

现象：apply 正常结束，catbundle 跑完了，但启动时报 ORA-600 类内部错误，或者出现在特定功能测试时异常。

原因：八成是数据字典和应用版本不匹配，catbundle 没执行成功或日志里藏了 ORA-00942 没注意；剩下一成是旧 one-off 补丁的修复没有被新 PSU 包含，产生行为回退。

解决：先回滚补丁恢复到 apply 前，恢复业务后慢慢分析。回滚前把$ORACLE_HOME/rdbms/admin/catbundle_*.log完整归档，这些都是定位依据。紧急恢复时用 2.1 的 tar 备份重建 home 更快，所以备份这一步绝不能省。如果猫定后确认是某个 one-off 修复丢失，在 PSU 上重新叠加该 one-off 即可，但一定要先跑 prereq 验证兼容性。

5.4 单机环境用 opatch auto 打补丁，跑到一半失败

现象：有人图省事，在单实例环境用opatch auto代替opatch apply，结果报错并只完成了一半流程。opatch auto 是 RAC 场景设计给 GI_HOME 和 DB_HOME 两套 home 滚动打补丁的工具，单机没有集群资源，它会尝试扫描 ASM 和集群组件，环境不满足就直接失败。

解决：单实例老老实实用opatch apply -phBaseDir。RAC 环境也建议逐节点手动执行，先关一个节点的实例，apply 完验证正常再切下一个节点，整体风险比 opatch auto 全自动滚动更可控。

5.5 补丁后无效对象暴增，UTLRP 也清不干净

现象：应用完成后查dba_objects，大量INVALID状态对象，跑完 utlrp.sql 后数量只降了一点点。

原因：一部分是数据字典版本升级后 SYS 和 SYSTEM 对象需要重编译，utlrp 能处理；另一部分是业务侧对象本来就依赖缺失或引用第三方库不存在，和补丁无关；还有一类是 catbundle 执行时处于非 upgrade 模式导致脚本部分失败。

解决：先按属主分组看无效对象来源：

select owner, object_type, count(*) from dba_objects where status = 'INVALID' group by owner, object_type order by 3 desc;

SYS 和 SYSTEM 下的对象优先跑 utlrp 重编译；业务 schema 下的大量失效先查依赖对象是否还存在，不要一股脑归咎补丁。确认是 catbundle 失败导致的，则回到 4.3 重跑一次 SQL 应用步骤。

6. 验证闭合与回滚后悔药：把维护窗口安全收尾

6.1 用 lsinventory 与版本号确认补丁生效

catbundle 跑完、实例正常启动后，第一个验证命令就是确认补丁在 inventory 里注册成功：

$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425

输出应包含补丁编号、应用时间、平台信息。同时跑一把opatch lsinventory -detail确认补丁应用到正确的 ORACLE_HOME 路径，防止 5.2 里那种打错 home 的情况。补丁生效后sqlplus -v看到的版本号通常不会变，仍是 11.2.0.4.0，因此版本号不变不要误判为失败，PSU 不会修改基础版本号，它只替换二进制内容和数据字典版本。

6.2 重编译无效对象与回归启动

11.2.0.4 打完 PSU 后有一批视图、包需要重编译，标准动作是调 UTLRP 脚本：

sqlplus / as sysdba SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql

脚本会自动并行重编译失效对象，结束时会印出重编译计数。完成后重新查一次无效对象，和 5.5 的查询一致。剩几个 SYS 下的已知对象不消失是正常的，比如某些账号相关的对象本来就是失效状态，和补丁无关。之后按业务模块做一轮开关库、连接、基本 DML 的回归测试，特别是之前报过 Bug 的场景重点验证。

6.3 回滚操作与下一次升级前的快照习惯

如果回归发现问题需要回滚，命令本身并不复杂：

$ORACLE_HOME/OPatch/opatch rollback -id 36575425

但回滚前必须再次关闭实例和监听，回滚后还要重新跑一遍数据字典回滚脚本，不是滚完二进制就结束了。更重要的是，回滚意味着这个维护窗口要做的事没完成，下一次窗口要重新评估补丁版本，而不是简单重试同一操作。我自己的习惯：每打完一个 PSU 就把 ORACLE_HOME 打包一份留存，并给$ORACLE_HOME/cfgtoollogs/opatch/和catbundle_*.log做一次快照，下一次升级时直接对照这些基线来判断问题是不是新补丁引入的。

这些年打下来，最深的教训是：补丁安装本身很少失败，失败几乎都出在没给环境留好后路。一旦开始打补丁，就把自己当成在改手术，备份、检查、逐步验证每一环都不能省。有一次在预生产环境因为忘带-invPtrLoc，把补丁打到了同机另一套测试库的 home 上，从此每次执行前强制先跑一遍opatch lsinventory确认路径。希望这些经验能帮到你，少走几趟弯路。

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