Oracle数据库补丁安装指南：从命名规则到OPatch实战-平芜编程栈

简介：这是一份面向Oracle数据库管理员与运维工程师的Oracle 11g补丁安装包，适用于64位Linux系统，补丁编号为24006111，对应数据库版本11.2.0.4.161018，属于Oracle定期发布的季度累积补丁。压缩包内主要包括补丁描述文件与补丁二进制文件，前者如XML格式的PatchSearch用于检索补丁信息和依赖关系，后者用于实际更新数据库，整个压缩包体积约100.6MB。已有264人学习下载，适合正在维护Oracle 11g生产环境、需要按季度更新补丁的中高级DBA参考使用。通过该补丁包，可以清晰掌握补丁适用性确认、依赖检查、安装流程与回滚方法，同时理解备份和停机规划等关键操作，从而更稳妥地保障核心业务系统的安全稳定运行。

1. 这个文件名到底在说什么

第一次看到p24006111_112040_Linux-x86-64.zip这种文件名的时候，我刚从开发转岗做运维没两年，盯着屏幕愣了好久。后来被老 DBA 点了一句，才明白这串字符其实已经把"这个文件是什么、装在哪、用来干嘛"全写清楚了。

拆开看就是四段：

p是 Patch 的意思，说明这是一个补丁包。
24006111是补丁编号，Oracle 内部用这个 ID 关联所有补丁的文档、描述和下载信息。
112040是版本号，对应 Oracle 数据库 11.2.0.4.0。这个版本比较特殊，它是 11gR2 最后一个大版本，很多企业至今还在用。
Linux-x86-64是运行平台，也就是 64 位 Linux 服务器。
最后的.zip是压缩格式，解压之后才是真正的安装文件。

所以如果你手上的文件叫这个名字，说明你正在准备给一台 64 位 Linux 服务器上的 Oracle 11.2.0.4 数据库打补丁。

这里要提醒一下：Oracle 的补丁体系分很多种，常见的有 CPU（Critical Patch Update）、PSU（Patch Set Update）、SPU（Security Patch Update）、Bundle Patch 和一次性补丁（One-Off Patch）。p24006111属于哪种补丁，取决于你从 My Oracle Support 上下载时看到的补丁描述和 README 文档。命名规则是一样的，但用途可能完全不同。我给生产库打过 PS U，也打过专门修复某个 Bug 的一次性补丁，不管哪种，流程基本都是下面这套思路。

2. 打补丁前的准备：别急着解压

很多人拿到 zip 包第一反应就是unzip -q p24006111_112040_Linux-x86-64.zip，结果解压完不知道下一步干嘛，甚至直接卡在权限问题上。我的建议是：解压之前先把准备工作做扎实，磨刀不误砍柴工。

2.1 确认补丁适用的环境和版本

先确认三件事：操作系统版本、数据库版本、OPatch 工具版本。

操作系统用这个命令看：

cat /etc/redhat-release

数据库版本用 SQL*Plus 看：

sqlplus -v

或者登录数据库之后执行：

SELECT version FROM v$instance;

OPatch 工具的版本也重要，因为新补丁的安装通常要求 OPatch 不低于某个版本。检查方法：

$ORACLE_HOME/OPatch/opatch version

我之前遇到过补丁说明里明确写着 Requires OPatch 11.2.0.3.23 or above，结果服务器上的 OPatch 还是 11.2.0.3.4，直接 apply 会报版本不兼容。老老实实先去 MOS 下载对应版本的 OPatch 覆盖，再回来继续打补丁。

2.2 检查磁盘空间和用户权限

解压补丁包需要空间，应用补丁也需要空间。两个地方都要看：一是你准备把补丁包放哪儿的目录，二是$ORACLE_HOME所在文件系统的剩余空间。

df -h /u01 /tmp

补丁包本身不大，一般几十 MB 到几百 MB，但解压后加上应用过程产生的临时文件，建议至少留出 5GB 以上的空间。空间不够导致补丁中断的情况我见过不止一次，很折腾。

权限方面：补丁包解压出来之后的文件属主必须是安装 Oracle 的那个用户（通常是 oracle），所在组通常是 oinstall 或 dba。因为你最终会用这个用户去执行opatch apply，如果文件属主不对，OPatch 会报权限相关的错误，处理起来很麻烦。

2.3 数据库的备份和停机准备

补丁应用的过程需要数据库处于关闭状态（对于非滚动补丁而言，RAC 环境有滚动方式可以逐个节点打，但也要先了解清楚）。这就意味着你要提前评估停机窗口，并且做备份。

备份我一般做两件事：

用 RMAN 做一次数据库全备（或至少是控制文件加系统表空间的备份）。
把$ORACLE_HOME整个目录 tar 一份出来。

tar -czf /backup/oracle_home_before_patch_$(date +%Y%m%d).tar.gz $ORACLE_HOME

这时候 tar 可能会比较大，但这是救命的东西。有一次我打补丁时 ORACLE_HOME 下的文件被覆盖后出现了奇怪的字符集报错，最后就是靠这个 tar 包恢复回去的，省了大量重新安装的时间。

提示：停机窗口内不要只盯着打补丁本身，SQL 脚本的执行时间也要预算进去。11.2.0.4 的某些补丁需要启动数据库后跑catbundle.sql或类似脚本，这个动作往往比opatch本身更耗时，千万不要低估。

3. 补丁安装实操记录

环境准备好之后，正式的安装流程就清晰了。下面这个流程适用于单实例非 RAC 环境，RAC 环境会多一个节点顺序和集群层面的操作，但思路一致。

3.1 解压补丁包并检查内容

用 oracle 用户操作，先将补丁包拷贝到目标目录：

mkdir -p /u01/app/oracle/software/patch mv p24006111_112040_Linux-x86-64.zip /u01/app/oracle/software/patch/ cd /u01/app/oracle/software/patch unzip p24006111_112040_Linux-x86-64.zip

解压之后会生成一个以补丁号命名的目录，比如24006111。里面有README.html、etc目录，以及实际的补丁文件。强烈建议先把README.html打开看一遍。有些补丁需要额外的前置补丁或特殊处理步骤，唯一权威的安装说明就在这个文件里。

3.2 停库停监听

以 oracle 用户执行：

lsnrctl stop export ORACLE_SID=你的实例名 sqlplus / as sysdba

在 SQL*Plus 里：

SHUTDOWN IMMEDIATE; EXIT;

同时也要确认没有残留的数据库进程，否则后面opatch可能会检测到实例还在运行而中断。

ps -ef | grep pmon

正常情况下这个命令应该没有任何输出。

3.3 预检补丁冲突

这是我最爱的一步，也是新手最容易跳过的。直接执行：

cd $ORACLE_HOME/OPatch ./opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/app/oracle/software/patch/24006111

这个命令会检查当前 ORACLE_HOME 里已安装的补丁和新补丁之间有没有冲突。如果有冲突，它会明确告诉你冲突的补丁编号，你就得先处理旧的补丁或者找 Oracle 支持确认处理方式。预检通过的输出末尾会有Prereq "checkConflictAgainstOHWithDetail" passed.之类的字样。

3.4 正式应用补丁

一切就绪后执行：

cd $ORACLE_HOME/OPatch ./opatch apply -phBaseDir /u01/app/oracle/software/patch/24006111

OPatch 会先做一系列检查，然后应用补丁文件到 ORACLE_HOME。这个过程大概需要几分钟到十几分钟，取决于服务器磁盘性能。

注意看日志输出，如果出现OPatch succeeded，说明补丁已经安装成功。如果出现OPatch failed，先不要慌，看具体报错信息，百分之七八十的问题出在空间、权限或者前置补丁缺失上。

3.5 执行数据库层面的脚本

某些补丁（特别是涉及数据字典变更的）需要在数据库启动后执行 SQL 脚本。具体要不要执行、执行哪个脚本，README 里写得清清楚楚，比如常见的catbundle.sql是针对 PSU/SPU 的。如果不确定，可以查一下补丁对应的 MOS 文档。

执行方式类似这样：

sqlplus / as sysdba

STARTUP; @$ORACLE_HOME/rdbms/admin/catbundle.sql PSU apply;

脚本执行完成后，建议重新编译无效对象：

@$ORACLE_HOME/rdbms/admin/utlrp.sql;

这一步很容易被遗漏，但遗漏之后数据库的功能本身不会有大问题，不过后面用dba_objects查无效对象时会看到一堆 INVALID，看着很吓人，而且确实可能影响部分功能。

3.6 验证补丁是否生效

验证分两层。第一层用 OPatch 看：

$ORACLE_HOME/OPatch/opatch lsinventory

第二层用 SQL 验证：

SELECT action_time, action, version, id, comments FROM sys.registry$history ORDER BY action_time;

或者是针对数据库补丁版本的视图：

SELECT * FROM dba_registry_history;

如果你在dba_registry_history里能查到对应的补丁 ID，那基本就稳了。

最后别忘记启动监听：

lsnrctl start

4. 常见问题与排查技巧

这几年打补丁踩过不少坑，把最常见的几种整理成速查表，遇到问题时可以直接对照处理。

4.1 问题速查表

现象	可能原因	处理方式
解压时提示 Permission denied	补丁包属主不是 oracle 用户	`chown -R oracle:oinstall`后重新解压
opatch 报 OPatch version 过旧	补丁要求更高版本的 OPatch	从 MOS 下载新版 OPatch 覆盖`$ORACLE_HOME/OPatch`
apply 时提示 Inventory 权限错误	临时目录`/tmp`权限被改过	用`TMP=/u01/tmp`指定新的临时目录，并确保属主是 oracle
补丁预检报冲突	环境中已有冲突补丁	联系 Oracle 支持或卸载冲突补丁
`shutdown immediate`无法关闭数据库	存在活跃会话	先 kill 活跃会话，再关闭，必要时使用`SHUTDOWN ABORT`
OPatch 找不到 ORACLE_HOME	环境变量没有设置	`export ORACLE_HOME=`指定正确路径后再执行
解锁后启动报错：`ORA-00600`或`ORA-01115`	文件权限被改或被覆盖	恢复备份的 ORACLE_HOME，重新检查文件属主
执行 SQL 脚本时报`ORA-04021`等锁类错误	有会话占用相关对象	重启数据库后再执行 SQL 脚本
zip 包校验失败	下载不完整	重新下载并对比官方 MD5 或 SHA-1

4.2 几个独家避坑技巧

第一招：opatch lsinventory -detail比lsinventory给的信息全得多，特别是需要确认某个补丁是否包含多个子补丁时。我在 RAC 环境核对两个节点的补丁状态时，基本就是靠-detail输出做对照。

第二招：打完补丁之后，第一时间检查监听和 ASM 相关的资源是否正常。11.2.0.4 的补丁有时候会影响到 ASM 实例，哪怕你的业务只用一个单实例数据库，只要环境里有 ASM，就必须把 ASM 实例也纳入检查和停止范围。ASM 实例没关掉就开始打补丁，OPatch 本身不会直接报错，但之后你会遇到各种奇怪的现象，比如磁盘组挂不上。

第三招：临时目录的坑。OPatch 运行时会往/tmp写临时文件。如果服务器上/tmp空间被占满或者权限被某个安全加固软件收紧了，你会看到一堆莫名其妙的失败。提前用df -h /tmp看一眼，顺手把TMP环境变量指到一个有空间可控的目录：

export TMP=/u01/tmp export TMPDIR=/u01/tmp

第四招：补丁解压后建议在服务器上保留一份，别删。有些补丁后续的 rollback 或者二次修复需要基于原补丁目录完成。而且要保留的不仅是 zip 包本身，解压后的目录也要留着。我之前有一次想opatch rollback -phBaseDir的时候发现解压目录早就清了，又重新下了一次补丁包，麻烦得要死。

4.3 回退预案：万一出了问题怎么办

补丁这东西，永远要想着怎么退回去。就算前面准备得再充分，遇到极端情况也要有明确的回退方案。

如果是opatch阶段失败，可以先尝试：

$ORACLE_HOME/OPatch/opatch rollback -patch_id 24006111

如果这个能走通，系统就能恢复到打补丁之前的状态。万一 rollback 也走不通，那就只能用更笨但有效的办法：把之前 tar 出来的 ORACLE_HOME 解压回去，再恢复数据库备份。

rm -rf $ORACLE_HOME tar -xzf /backup/oracle_home_before_patch_$(date +%Y%m%d).tar.gz -C /

恢复到这一步之后，数据库可以正常启起来，但一定要尽快验证数据完整性和业务功能。如果一切正常，再重新评估是否要再次尝试打补丁。

我在实际操作中有个不太常规但很管用的习惯：补丁文件解压后，我会把 zip 包和解压目录都复制一份到独立的备份存储上，和数据库备份放一起。因为 zip 包的校验值（比如 SHA-1）就是下载那一刻的官方原始值，一旦后续要验明补丁包是否有变化，拿这份一比对就清楚了。这个习惯帮我排查过两次"补丁包拷贝过程中文件损坏"的问题，值得参考。

打个 11.2.0.4 的补丁，说难不难，说简单也谈不上。只要把准备工作做足，严格按照 README 的步骤执行，大部分问题都可以在预检阶段发现，而不是在 apply 阶段手忙脚乱。下载补丁包之后，第一件事永远是打开那个 HTML 说明文件，而不是急着执行命令，这是我踩了足够多次坑之后总结出来的最重要的一条经验。

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