简介面向64位Linux环境的Oracle 11.2.0.4.161018季度补丁包编号24006111适用于Oracle 11g第二版企业级数据库的日常维护与安全加固。该补丁包涵盖自上一季度以来的累积修复可解决已知漏洞、稳定性问题并带来性能优化是DBA保障生产环境安全运行的关键更新。压缩包约100.6MB内含补丁说明XML文件如PatchSearch.xml及补丁主体文件便于检索补丁适用性、依赖关系与安装指南。已有265人学习下载。应用前需完成数据库备份、兼容性检查并合理规划停机窗口安装时借助Opatch工具执行验证、部署与回滚操作。通过本包可熟悉Oracle补丁管理全流程理解季度补丁策略、安装先决条件及常见排错思路对维护高可用数据库环境具有直接参考价值。1. 认识补丁包命名p24006111_112040_Linux-x86-64.zip 究竟是个什么在 Linux 服务器上做 Oracle 运维的人对p24006111_112040_Linux-x86-64.zip这种文件名不会陌生它一套标准的企业级补丁包。这个名字拆开看p表示 Patch24006111是主补丁编号112040是补丁内的子补丁或者 overlay 补丁标识Linux-x86-64限定平台——Oracle 在 x86_64 架构 Linux 上的专用构建。拿到这个 zip意味着你要给一套数据库或者 Grid Infrastructure 安装修复补丁而不是单纯解压看看里面有什么。很多初接触的人在第一步就被这套命名绕进去了。它既不像源码包那样 clone 下来就能编译也不像普通软件安装包双击即可跑而是带一套自己的安装器OPatch和一套严格的目录结构。好在只要你摸清了这个 zip 里的内容组织方式、OPatch 工具链的调用顺序整个补丁安装流程是高度可复现的。这篇笔记按我实际打补丁的路径展开先认出包再解压校验然后处理依赖和冲突最后安装与验证每一段都给你能直接抄的命令。2. 装补丁前必须确认的三件事补丁归属、环境现状与空间余量拿到补丁包不要急着 unzip。Oracle 补丁和普通 zip 最不一样的地方在于它对应用环境有强约束打了什么补丁、OPatch 版本够不够、依赖的补丁前置条件是否满足这些如果一个没对上apply 到一半报错是小事把 inventory 搞坏就真要加班了。我一般先把下面三件事做完再做解压。2.1 确认当前环境与补丁归属补丁是打在 ORACLE_HOME 上的所以第一步是确认环境变量和当前 inventory 状态。以 oracle 用户登录先检查$ORACLE_HOME是否指向你打算打补丁的那一套环境。Linux 下常见翻车点就是环境变量串了——多个实例共用一个 home或者同时装了数据库和 Grid结果把补丁打到了错误的位置。# 确认当前 shell 使用的 ORACLE_HOME echo ORACLE_HOME$ORACLE_HOME echo ORACLE_BASE$ORACLE_BASE # 查看当前 home 的补丁清单这一步必须做不打无准备之仗 $ORACLE_HOME/OPatch/opatch lsinventory -detail 21 | tee /tmp/lsinv_before.loglsinventory输出里的关键信息有三块当前 OPatch 版本、已安装补丁列表、Oracle 主目录路径。其中 OPatch 版本直接决定你能不能打这个新补丁。输出里的Patch description那一栏会写明这个补丁修复的问题域核对一下跟你这次要修的问题是否对得上。参数上-detail会展开每个补丁的详细信息包括安装时间和涉及组件。如果不是首次在这台机器上打补丁建议保留这份日志后面安装后再做一次lsinventory两份对比就能立刻看出补丁是否真的进 inventory。2.2 核对数据库或 Grid 版本与补丁前置关系接着用 SQL 确认数据库版本注意是version_full不是version后者只显示大版本号无法判断补丁集级别。sqlplus -S / as sysdba EOF set linesize 200 select banner_full from v$version where banner like Oracle%; select version, version_full from v$instance; exit; EOF那为什么要看版本因为p24006111这类补丁通常针对特定 release 发布。常见做法是到补丁的 README 里查它的Product、Release、Platform三段头确认与当前环境匹配。README 是解压后才有的所以在解压前先用 zip 命令查看内部文件列表找到 README 的确切文件名。如果你是在 My Oracle Support 上手动下载的补丁包也可以先看文档页里标注的 Applies to 版本区间避免下载后发现基线版本对不上白等一个下载时间。2.3 检查空间与临时目录挂载方式Oracle 补丁 apply 时会先在临时目录解压并写入日志空间评估不只算 zip 解压后大小还要加上 OPatch 备份原文件所需的额外空间。我的经验值是补丁目录留存一份、ORACLE_HOME 内存在一份、临时目录一份三份加起来按解压后大小的 3 倍预留比较稳。另外$ORACLE_HOME/.patch_storage是补丁回滚目录的默认位置空间不足时也要先确认它所在的文件系统是否有富余。# 磁盘余量与 inode 双查两个都可能成为隐性问题 df -h $ORACLE_HOME /tmp /u01 2/dev/null df -i $ORACLE_HOME /tmp /u01 2/dev/null # 确认临时目录是否被 tmpfs 挂载重则立即发现 mount | grep -E /tmp | /u01 如果发现 /tmp 是 tmpfs且内存不大最好通过设置环境变量把 OPatch 的临时目录指到磁盘文件系统上。这个细节太多人栽过apply 时报Cannot create temporary file排查半天其实是 /tmp 塞满。环境变量名是TMPDIR在打补丁的 shell 里export TMPDIR/u01/app/oracle/tmp即可。这类小参数写进 README 的不少但 README 往往被忽略我建议直接在操作前固定一套环境变量避免二次踩坑。提示修改 ORACLE_HOME 之前务必做一次全量备份最简单的是 tar 整个目录。大版本补丁尤其需要文件数少则几万多则十几万不要指望事后能精准恢复。3. 解压与校验把 zip 里的补丁内容安全落盘补丁包的校验和解压是整个流程里最像普通 Linux 操作的一段但有几个细节和普通 zip 不太一样。这一段用的命令都不难难在什么时候用哪个、怎么判断解压结果是否可信。3.1 先做完整性校验md5sum 与 zip 测试一个都不能少补丁文件在传输过程中损坏的概率不低尤其是跨机房、跨网络下载的场景。Oracle 官方发布的补丁页面上会给出对应 md5 或 sha256 校验值下载完成后第一步就是比对而不是直接解压。如果校验值不对趁早重新下载不要抱着 应该能解压 的侥幸心理。# 计算当前文件的 MD5 值与官方页面比对 md5sum p24006111_112040_Linux-x86-64.zip # 不实际解压先测试 zip 是否完整 unzip -t p24006111_112040_Linux-x86-64.zip | tail -5 # 查看 zip 内部文件列表找 README 和补丁目录名 unzip -l p24006111_112040_Linux-x86-64.zip | head -30unzip -t是 zip 压缩包的自检命令它会逐个文件检查 CRC末尾会给出总和与错误统计。这一步不要跳过因为它能在解压前就暴露文件损坏。unzip -l则帮你预览目录结构找到补丁主目录名与 README。常见的目录形式是解压后有一个以补丁号命名的目录里面放着etc/、files/和patch元数据文件。先看到目录结构再决定解压到哪比想象中重要——有些补丁包解压后直接就是补丁目录有些则包了一层上层目录后面opatch apply指向的位置会不一样。3.2 解压命令选型unzip 可用但注意中文与属主Linux 下解压 zip 的命令列出来有很多选择unzip、jar xf、7z x。对 Oracle 补丁包来说unzip是标准工具兼容性最好。但在一些国产化 Linux 发行版上unzip 的版本参差不齐部分老版本对 zip64 格式支持不好解压大补丁包时报need disk之类错误。这种时候换用7za或者jar可以救急。# 标准解压-q 安静模式-d 指定目标目录 unzip -q p24006111_112040_Linux-x86-64.zip -d /u01/app/oracle/patch24006111/ # 解压后立即检查属主必须为 oracle:oinstall ls -ld /u01/app/oracle/patch24006111 ls -l /u01/app/oracle/patch24006111/24006111 | head解压后的属主问题很隐蔽。如果你用 root 解压补丁目录下的文件属主全是 root后面用 oracle 用户跑 opatch 时即使权限位是 644也会在修改这些文件时报权限错误。所以落地路径要选在 oracle 用户可写的目录下解压动作也用 oracle 用户执行。这条规则我一般在操作清单里放第一行。注意国内不少 Linux 镜像站和网盘会二次压缩或改名导致解压后目录结构与官方 zip 不一致。如果你是从中转渠道拿到的包解压后务必对照 README 里声明的目录结构再继续。从 MOS 直连下载则不存在这个问题。3.3 识别补丁目录结构与 apply 的指向差异解压完成后进入补丁主目录查看一下核心文件是否存在。Oracle 补丁目录的典型结构是etc/config/、files/、etc/actions/以及若干 xml 文件。其中etc/config/inventory.xml或类似文件记录了补丁的元数据files/下是真正要被替换的二进制和脚本。这个结构里没有 Makefile也没有 configure——它靠 OPatch 读取元数据来决定改哪些文件。cd /u01/app/oracle/patch24006111/24006111 find . -maxdepth 2 -type f | head -20从这里能得到一个关键信息apply 时要带-phBaseDir参数指向这个目录而不是指向外层解压目录。如果解压后多包了一层目录OPatch 在查找补丁元数据时就容易报Patch location is not valid。我在给人排查时经常看到这类错误十次有八次是路径指到了外层。另外README 文件通常叫README.txt或PatchReadme.html务必打开读一遍里面加粗的 Before You Begin 段落那里面写的往往是这个补丁特有的附加要求比如需要先停实例、需要额外设置某个环境变量、或者与某个已知问题互斥。打补丁不是流水线每个补丁的附加条件都在 README 里花五分钟读它不亏。4. 升级 OPatch 并检查冲突补丁装不上的头号原因OPatch 是 Oracle 的补丁应用工具它自身也随补丁周期迭代。新补丁包要求的最低 OPatch 版本通常会写在 README 的OPatch Version一节里。如果你当前 home 里的 OPatch 版本低于要求apply 会直接报OPatch version check failed这一步是硬性门槛没有商量的余地。也就是说打大多数补丁前要先解决工具链本身的版本问题。4.1 判断 OPatch 是否过老用 p6880880 升级查看 OPatch 版本用一行命令即可。如果版本偏低需要先下载对应版本的 OPatch 升级包——它的文件命名一般是p6880880_版本号_Linux-x86-64.zip。升级过程其实就是用新 zip 里的内容整体替换$ORACLE_HOME/OPatch目录。# 查看当前 OPatch 版本 $ORACLE_HOME/OPatch/opatch version # 备份旧 OPatch并替换为新版本 cp -r $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak.$(date %Y%m%d) unzip -q -o /tmp/p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME # 再次确认版本 $ORACLE_HOME/OPatch/opatch version替换时要注意-o参数覆盖旧文件且新 zip 解压后直接就是OPatch/目录所以目标路径是$ORACLE_HOME而不是$ORACLE_HOME/OPatch写错的话会在 home 下多套一层目录。升级 OPatch 不会影响已安装补丁的 inventory 记录因为 inventory 存放在$ORACLE_HOME/inventory下与 OPatch 目录本身相互独立。但备份旧 OPatch 目录仍然是好习惯万一新版本和你用的 Linux 发行版有兼容问题还能立刻切回。4.2 用 prereq 命令做冲突预检避免 apply 中途失败OPatch 自带的 prereq 命令是打补丁前最该用而很多人不用的功能。它能在不实际改动文件的情况下静态检查补丁与当前环境的兼容性包括已安装补丁冲突、缺少的前置补丁、平台匹配度、OPatch 版本等检查项。# 进入补丁目录后用 prereq 做全量预检 cd /u01/app/oracle/patch24006111/24006111 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail \ -phBaseDir $PWD -invPtrLoc $ORACLE_HOME/oraInst.loc 21 | tee /tmp/prereq_check.log # 追加一个检查是否已安装同类补丁 $ORACLE_HOME/OPatch/opatch lsinventory -bugs_fixed | grep -i 24006111CheckConflictAgainstOHWithDetail的参数需要留意-phBaseDir指向补丁目录-invPtrLoc指向oraInst.loc文件路径。如果该参数不写OPatch 会尝试使用默认 inventory 位置在多 home 机器上容易混淆。预检输出里出现Conflict字样时不要硬着头皮 apply先确认冲突的补丁 ID 是否已经包含在新补丁里很多补丁是替代关系而不是互斥关系如果确认是替代关系走opatch auto或按 README 里说明的方式处理即可。预检这个步骤能在几分钟内筛掉八成中途失败的因素。我见过太多人跳过预检直接 apply然后在改动几十个文件之后报出冲突回滚又要重新操作一遍。时间成本上预检只占 apply 时长的零头性价比极高。4.3 临时目录与 JRE 问题两个隐藏的 prereq 杀手在 Linux x86-64 上跑 OPatch 还有一个常见坑是 JRE 缺失或者版本不匹配。OPatch 自带的 JRE 位于$ORACLE_HOME/OPatch/jre或类似路径下有些补丁包要求特定 JRE 版本如果在裁剪过的系统上没有安装匹配的 JRE会报Unable to load JRE或Cannot locate Java。这时不要急着改PATH先看看OPatch目录里有没有 JRE设置OPATCH_JAVA_HOME环境变量指向正确的 JDK 或 JRE。# 查看 OPatch 自带 JRE 是否存在 ls $ORACLE_HOME/OPatch/jre 2/dev/null $ORACLE_HOME/OPatch/jre/bin/java -version # 若不存在显式指定可用的 Java 环境 export OPATCH_JAVA_HOME/usr/java/jdk1.8.0_291临时目录变量TMPDIR在前面提过这里再强调一次OPatch 在 apply 过程中会在临时目录创建大量临时文件如果临时目录空间不够或权限不对表现往往是prereq阶段一切正常进入 apply 后忽然报java.io.IOException: No space left on device。这个错误指向的很可能是 /tmp 挂载点也可能指向 ORACLE_HOME 所在文件系统。提前export TMPDIR到空间充足且属主为 oracle 的目录一步到位不给后面留翻车机会。提示OPatch 的日志默认写在$ORACLE_HOME/.patch_storage和/tmp下排错时要同时看这两个位置。脚本里最好在set -x模式下先定义OPATCH_DEBUG环境变量为TRUE这样日志会详细到每一步动作和参数排查定位速度会快很多。5. 避坑打补丁最常碰到的 5 个事故现场这一段是把以往给别人处理问题时碰到的真实情况按「现象 → 原因 → 解决」整理出来每一条都能在十几分钟内定位。不要在踩坑之后才想起来看这一章操作前扫一遍也能帮你规避大部分低级失误。5.1 zip 伪加密没有密码却解压失败现象解压时提示password required或者unsupported encryption但下载页面并没有提供密码文件大小也是正常的。这是网上一些补丁包二次处理后留下的问题。原因是补丁包被第三方工具处理过设置了伪加密标志实际内容并没有加密。解决方法是先确认是否伪加密用zipinfo查看每个条目的加密标志位如果显示-l-表示有加密 flag再用7z x尝试直接接压。7-Zip 对伪加密的处理更宽容常常可以直接解出内容。# 查看 zip 内每个文件的加密标志 zipinfo -v p24006111_112040_Linux-x86-64.zip | grep -E file name|encryption # 用 7z 尝试解压可识别伪加密标记 7z x p24006111_112040_Linux-x86-64.zip -o/tmp/test_extract如果 7z 也只能列出文件而不能解压说明这个包确实被人动过不是标准官方包。这种情况下不要继续直接回官方渠道重新下载。用暴力破解工具去试密码的思路在补丁包场景里完全没有必要——补丁是公开下载的不需要密码有密码说明来路不对。5.2 终端工具传包导致二进制损坏现象zip 解压时报某个特定文件 CRC 错误但 zip 文件大小和下载页对得上。原因不是下载过程损坏而是用了文本模式的 FTP 或某些终端拖拽工具传输 zip导致二进制内容被转义或截断。解决方法是改用scp、sftp或以二进制模式重新传输该文件重新计算 md5 后再解压。这个问题在虚拟化管理平台上比较高频比如从 Windows 宿主机拖到 Linux 虚拟机里中间经过剪贴板zip 文件就可能被改坏。# 远端重新传一遍确保二进制模式 scp -P 22022 p24006111_112040_Linux-x86-64.zip oracleserver:/u01/app/oracle/patch24006111/传输完成后立刻做unzip -t不要省这一步。我在一次真实操作中遇到过三个文件同时 CRC 错误重传一次后全部正常这就是典型的传输环节问题而不是文件本身问题。5.3 只查 df 不查 inode磁盘有空间但创建不了文件现象df -h显示空间还剩几十 GB但 OPatch 在写临时文件时报No space left on device。原因在于文件系统 inode 耗尽目录项创建失败。补丁包解压后文件数量动辄数万每个文件都要消耗一个 inode如果某分区格式化时 inode 密度不足空间未满但 inode 先耗尽。解决方法是执行df -i查看 inode 使用率如果 100%就需要找到可清理的小文件目录或者换一个 inode 充足的文件系统来放补丁目录。# 查可用 inode 数量关键指标IUse% 是否接近 100 df -i /u01/app/oracle/patch24006111 # 找 inode 占用大户一般集中在 tmp 和 oracle 的 trace 目录下 find /u01/app/oracle -xdev -type f | wc -l在 xfs 文件系统上inode 是动态分配的一般不会出现此问题但在 ext3/4 且inode_ratio设置较大的分区上这个坑很常见。遇到时就地换文件系统目录把补丁目录移动到/home或者另一个块设备比清 inode 更快。5.4 apply 中途中断导致 inventory 状态不明现象apply 进行到一半会话断开或服务器重启重新执行 apply 时提示补丁已存在但实际文件并未替换执行 rollback 又提示补丁未安装。原因是 OPatch 的 apply 过程分两个阶段——先是文件操作后是 inventory 更新中断在这两个阶段中间就会造成不一致。解决方法是先看$ORACLE_HOME/.patch_storage里的日志确认中断发生在哪个阶段然后按 OPatch 官方做法清理inventory.xml中的残留条目再重新 apply。# 查询当前 home 的补丁记录看 24006111 是否已登记 grep -r 24006111 $ORACLE_HOME/inventory/ContentsXML/comps.xml | head处理这类残留 inventory 的操作要谨慎务必先备份comps.xml和inventory.xml。不要贸然 delete因为 OPatch 的 inventory 有全局唯一性约束删错条目可能导致后续所有补丁无法登记。这块属于高危操作如果拿不准宁可在 MOS 上开一个 SR把日志和 inventory 备份一起传过去也不要自己乱改 XML。5.5 未停实例就 apply文件被占用现象apply 阶段报ORA-27102或文件无法写入退回检查发现是数据库实例还在运行部分 Oracle 二进制或lib库文件正被进程占用。原因很简单——Linux 的文本替换不检查文件占用状态替换会成功但运行中的进程仍映射着旧的内存页可能积攒隐患OPatch 也会检测到进程存在而中止。解决方法是按标准流程关闭所有相关实例包括数据库和监听。# 关闭监听与实例 lsnrctl stop sqlplus -S / as sysdba EOF shutdown immediate; exit; EOF # 确认没有遗留 oracle 进程 ps -ef | grep -E ora_|tnslsnr|lsnrctl | grep -v grep对于 RAC 环境需要更完整的停集群流程不止crsctl stop crs那么简单还要考虑 ASM 实例和监听依赖。单机环境相对简单但也要等ps输出完全干净再启动 apply。补丁打完后再一次ps确认进程没有半启动状态。6. 从 apply 到验证安装、确认与回滚的完整闭环前置检查做完进入真正的 apply 阶段。这一阶段没有太多玄学核心是把命令参数写对、日志盯好、事后验证做足。apply 命令要进入补丁目录内执行以 oracle 用户操作并且保持当前目录的路径写入-phBaseDir参数。6.1 最小化 apply 命令与两个必盯的日志位置# 进入补丁目录执行 apply-verbose 输出详细进度 cd /u01/app/oracle/patch24006111/24006111 $ORACLE_HOME/OPatch/opatch apply -verbose 21 | tee /tmp/apply_24006111.log-verbose参数值得加OPatch 默认输出简洁但出错时 verbose 模式会打印具体操作的文件路径和执行的动作排错时信息量大很多。apply 过程中有两个位置需要特别盯住——-verbose输出的Running make阶段以及最后的Update inventory阶段。前者如果报编译错误多半是系统缺少依赖的库或者 make 工具链不完整后者如果报错多半是 inventory 写入权限或之前残留的条目冲突。中途 CtrlC 中断 apply 是大忌。OPatch 不像普通安装包那样支持安全中断中断后的状态我们刚才讲过——文件替换了一半但 inventory 没更新两头不靠。万一真的中断先按上一章的 inventory 排查方法处理不要直接二次 apply。6.2 验证补丁状态不只查 lsinventory还要看实际文件apply 成功只是第一步验证要多层进行。第一层是opatch lsinventory确认补丁在 inventory 中第二层是查实际替换的二进制文件时间戳第三层是启动数据库确认没有因文件替换导致加载错误。# 验收一补丁已登记 $ORACLE_HOME/OPatch/opatch lsinventory -bugs_fixed | grep 24006111 # 验收二实际文件修改时间落在本时段 ls -l $ORACLE_HOME/lib/libserver10.a | tee /tmp/lib_check.log # 验收三正常启动并查询 registry 视图 sqlplus -S / as sysdba EOF startup; select status, action, version, description from registry$history where actionAPPLY and version like %24006111%; exit; EOFregistry$history视图记录了每次补丁应用的历史它的version字段不一定直接包含补丁号更常见的是记录补丁集版本。如果这个视图查不到用dba_registry_sqlpatch视图按PATCH_ID查两个视图中至少应该有一个能对映到本次补丁。实际环境里补丁号与视图记录的映射有时存在偏差以opatch lsinventory为准。6.3 回滚准备留下后路但不要随便 rollback打补丁是个有后路的过程因为 OPatch 自动在$ORACLE_HOME/.patch_storage保留被替换文件的备份这也就是所谓的后悔药机制。但 rollback 不要轻易触发——它要求当前环境与安装时几乎一致任何额外操作包括再次 apply 其他补丁都可能让 rollback 因为依赖关系而拒绝执行。# 确认回滚备份存在 ls -d $ORACLE_HOME/.patch_storage/*24006111* 2/dev/null # 如果要回滚执行方式如下不推荐在日常操作中频繁使用 $ORACLE_HOME/OPatch/opatch rollback -id 24006111 -phBaseDir $PWD回滚前先看.patch_storage里对应补丁目录是否存在且包含完整备份缺失时 rollback 会直接失败。如果打补丁后已经又执行过别的维护操作我的习惯是先评估能否接受「基于当前状态重新打另一版补丁」的方案而不是强行回滚——回滚有时比安装更耗时而且更容易把环境带到另一个不一致状态。最后一个个人习惯每次打补丁结束后把apply_24006111.log、lsinv_before.log、lsinv_after.log三份日志统一归档到一个按日期命名的目录里并记录应用的数据库版本和补丁包来源。这些日志在下次打补丁或者排查性能问题时能帮你迅速定位历史变更。补丁安装不是「解压 zip 覆盖文件」这么简单它是一次需要严谨流程支撑的变更管理别偷懒。希望这篇笔记能帮你在面对p24006111_112040_Linux-x86-64.zip这类补丁包时少走弯路。环境不一样、补丁版本不一样但从核对环境、解压校验、预检冲突到 apply 验证这条主线是不变的。先把框架跑通再去处理那些补丁特有的小脾气你会觉得这套流程比想象中顺手。本文还有配套的精品资源点击获取