Oracle 11.2.0.4 补丁包 p26635834 落地指南：从预检到回滚

简介Oracle官方补丁包p26635834_112040_Linux-x86-64.zip面向Linux x86-64平台上的Oracle 11g R211.2.0.4数据库用于修复安全漏洞、性能瓶颈与稳定性缺陷适合DBA和运维人员在升级或排障时使用。压缩包共103个文件大小40.49MB主要包含class字节码、sql脚本、xml配置文件、jar工具包及txt说明其中元数据配置可被OPatch自动读取便于匹配环境并指导安装流程。目前已有264人学习下载适合具备Oracle基础、需要在实际环境中维护数据库的读者。下载后可获得完整的补丁程序与配套脚本能够按官方流程完成兼容性检查、解压、备份、应用补丁和版本校验同时通过分析内部脚本与类文件理解补丁变更逻辑有效增强数据库安全性与合规性降低升级风险。1. 一个文件名里藏了半条命p26635834 这个 Oracle 补丁包要怎么落地p26635834_112040_Linux-x86-64.zip 这个文件名第一次看到的人多半会愣一下。别被这一长串吓住Oracle 补丁包的命名规律其实很机械p 后面是补丁号112040 代表 11.2.0.4.0 这个 ReleaseLinux-x86-64 是平台标识。DBA 拿到它的场景大概率是季度安全补丁CPU/PSU或者某个特定 Bug 修复包。它要解决的事情很具体把补丁安全地应用进 11.2.0.4 的实例验证它生效万一出问题还能退回来。这篇适合正在维护 11.2.0.4、被等保或安全通告追着打补丁的运维和 DBA按预检、实战、验证、回滚的顺序把整套流程走一遍中间穿插几条我踩出来的经验。2. 打补丁前必须做对的三件事环境变量、依赖版本与 inventory 预检2.1 从补丁文件名读出 Release 与平台先确认你和补丁在同一频道p26635834_112040_Linux-x86-64.zip 这个名字里最有用的信息是 112040 和 Linux-x86-64 这两段。112040 是 11.2.0.4.0 的缩写也就是常说的 11g R2 第四个版本。Oracle 的补丁体系里基版本不会因为打补丁而改变11.2.0.4 永远是 11.2.0.4所有补丁都是增量叠加在这个基版本之上。这一点先想明白后面遇到 apply 报依赖缺失才不会慌。平台标识要重点看。Linux-x86-64 只适用于 64 位 x86 LinuxRHEL 6/7、Oracle Linux 6/7、CentOS 6/7 都在这一档。但 Solaris、AIX、Windows 的补丁后缀完全不同文件不能互用。我见过有人把 Solaris 的包 unzip 到 Linux 上opatch apply 直接报 Patch is not applicable——那不是 OPatch 有问题是包下载错了。动手之前先确认架构# 确认系统架构x86_64 才是 64 位 uname -m # 顺手确认 Linux 发行版 cat /etc/oracle-release 2/dev/null || cat /etc/redhat-release说明uname -m 输出 x86_64 时才能用这个包i386/i686 是 32 位系统补丁包后缀不匹配就不能继续。cat 那段命令是为了看发行版RHEL 和 Oracle Linux 在补丁层面基本一致但发行版小版本太老时补丁的 glibc 依赖可能不满足。2.2 环境变量与 ORACLE_HOME 校正打补丁最怕 PATH 指到另一个 Oracle一台机器上装多套 Oracle 的情况很常见比如生产是 11.2.0.4测试机还挂着一套 12c。这时候打补丁最大的风险不是补丁本身而是 shell 环境指向了错误的 ORACLE_HOME。opatch 工具就在 ORACLE_HOME 下面它默认读环境变量和本机 inventory。如果 PATH 先找到的是 12c 的 OPatch你以为在给 11.2.0.4 打补丁实际操作的可能是另一套库的 inventory后果相当刺激。# 每步都值得先确认三件事用户、ORACLE_HOME、ORACLE_SID whoami echo ORACLE_HOME$ORACLE_HOME echo ORACLE_SID$ORACLE_SID which opatch sqlplus说明whoami 必须输出 oracle 而不是 root。echo 检查环境变量是否已经正确导入。which opatch 的路径必须在目标补丁的 ORACLE_HOME 下如果指向 /usr/bin/opatch 或别的位置说明 PATH 顺序有问题需要先修正。我一般不建议直接 source 别人的 .bash_profile里面残留的历史变量太多。更稳的做法是在当前 shell 手动设置# 手动设置环境变量路径以实际安装目录为准 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export ORACLE_SIDorcl export PATH$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH # 验证当前目录确实是 ORACLE_HOME cd $ORACLE_HOME pwd参数说明ORACLE_HOME 路径不能靠猜最可靠的办法是查 /etc/oratab 文件或者 lsnrctl status 的输出。LD_LIBRARY_PATH 这行是为了避免 sqlplus 或 OPatch 运行时报 libclntsh.so 找不到——这个问题在 11g 上比 12c 更常见因为老环境的库链接路径经常不完整。2.3 OPatch 版本与依赖预检apply 之前先用 prereq 做一次体检OCIS 版本要求是硬门槛11.2.0.4 要求 OPatch 版本不低于 11.2.0.3.9。版本低了 opatch apply 会直接拒绝执行。很多老服务器上的 OPatch 还停在一个远古版本因为没人日常会去升级工具。检查方法很简单# 查看当前 OPatch 版本 $ORACLE_HOME/OPatch/opatch version如果输出低于 11.2.0.3.9先找 p6880880 工具包来升级 OPatch 本身。p6880880 是 Oracle 官方 OPatch 升级包的通用补丁号不同平台有对应版本。注意升级 OPatch 不等于打补丁它不碰数据库数据也不需要停实例。# 升级 OPatch先备份再解压最后覆盖 cp -rp $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak.$(date %Y%m%d_%H%M%S) unzip p6880880_112000_Linux-x86-64.zip -d /tmp/opatch_tmp cp -rp /tmp/opatch_tmp/OPatch/* $ORACLE_HOME/OPatch/ $ORACLE_HOME/OPatch/opatch version参数说明备份这一步别省。OPatch 升级失败后想退回旧版没有备份就只能重新解压安装介质。解压到 /tmp 再 copy 而不是直接解压进 ORACLE_HOME是为了防止 zip 内目录结构把原 OPatch 覆盖乱。copy 完成后再次执行 opatch version确认版本号真的变了。然后是 inventory 预检。Central Inventory 目录权限被改过是 apply 阶段最常见的临时翻车源头# 检查 inventory 是否完好 $ORACLE_HOME/OPatch/opatch lsinventory -detail 21 | head -30如果报 Inventory check failed先看 /u01/app/oraInventory 的属主和权限chown -R oracle:oinstall /u01/app/oraInventory chmod -R 775 /u01/app/oraInventory最后用 prereq 子命令做正式体检。prereq 不太被重视但它能在不改动系统的情况下提前暴露补丁适用性、磁盘空间这两大问题# 先解压补丁再跑 prereqphBaseDir 指向补丁目录 unzip p26635834_112040_Linux-x86-64.zip -d /tmp/patch $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseDir /tmp/patch/26635834 $ORACLE_HOME/OPatch/opatch prereq CheckApplicable -phBaseDir /tmp/patch/26635834说明phBaseDir 是补丁解压后所在目录不是 zip 文件路径。CheckSystemSpace 会列出 ORACLE_HOME 所在文件系统剩余空间和补丁所需空间CheckApplicable 检查补丁是否适用于当前 ORACLE_HOME。两条命令都不报错apply 才算通过预检。3. 补丁应用实战从 unzip 到 opatch apply 的完整动作与参数拆解3.1 解压补丁包unzip 的细节决定 apply 的成败解压这一步看似简单翻车率却出奇地高。常见失误有两个一是把补丁解压到 root 才可读的目录导致 oracle 用户读取补丁文件时权限不足二是 zip 解压后嵌套了一层目录cd 错了路径后面 apply 报 Patch ID not found。# 解压补丁包到独立目录不要直接解压到 ORACLE_HOME mkdir -p /tmp/patch unzip p26635834_112040_Linux-x86-64.zip -d /tmp/patch # 查看解压结果确认目录结构 ls -lR /tmp/patch | head -50说明-d 参数指定解压目录。不推荐直接解压到 $ORACLE_HOME补丁文件会混进软件目录后面 opatch apply 的 phBaseDir 也不好指。ls -lR 看结果如果看到 /tmp/patch/26635834/ 下面有 README.txt 和 etc/ 目录那这个 26635834 目录就是真正的 phBaseDir如果第一层直接散落着文件说明解压出来的结构和预期不一致以 README 为准。解压完我有个固定动作先读 README.txt 的前 100 行里面写明前置补丁、是否需要停实例、是否需要跑后续 SQL 脚本。不同补丁的 README 差异很大有的要求 apply 后执行某个 sql有的要求先执行脚本漏读这一段会导致后面验证阶段莫名失败。# 修正文件属主保证 oracle 用户可读 chown -R oracle:oinstall /tmp/patch chmod -R 755 /tmp/patch关于 zip 本身再提醒一句从官方渠道下载补丁时页面会给出对应的 md5 或 SHA 校验值。下载完先校验再解压别等到 apply 报文件损坏才回头重传# 校验 zip 文件完整性以你下载页面提供的校验值为准 md5sum p26635834_112040_Linux-x86-64.zip3.2 停止服务与 opatch apply-oh、-silent、-local 到底该怎么用11.2.0.4 的大多数补丁要求数据库处于 shutdown 状态特别是 PSU 和 CPU 这类会改内部结构的补丁。我建议统一按需要停来准备省得 apply 中途被锁文件卡住。先停监听再关实例# 停监听 lsnrctl stop # 用 sqlplus 关闭实例 sqlplus / as sysdba EOF shutdown immediate; exit; EOF说明shutdown immediate 会等待当前事务结束并回滚未完成事务。如果数据库里跑着大事务shutdown immediate 可能卡住必要时可以改用 shutdown abort但 apply 前必须确保实例彻底关闭用 ps -ef | grep ora_ 检查没有后台进程残留。进入补丁目录执行 apply 是核心动作# 进入补丁目录执行 apply cd /tmp/patch/26635834 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME参数拆解。opatch 会读取补丁目录中的 etc/actions 元数据生成应用计划并逐步执行。几个关键参数-oh 指定 ORACLE_HOME。虽然环境变量里已经有但显式写出可以防止脚本里 export 路径写错。-silent 让输出进入静默模式适合写进自动化脚本。-local 只在当前节点执行。RAC 环境每个节点必须单独做即使共享 ORACLE_HOME 也不推荐跨越节点做远程批量操作。-invntry 指定 inventory 目录比如 -invntry /u01/app/oraInventory非默认路径时才需要。-report 只生成应用报告不做实际变更第一次处理陌生补丁时建议先跑一遍。# 先看报告确认发生什么再真正执行 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -reportapply 过程中屏幕会滚动输出 Applying patch 26635834...结尾出现 OPatch succeeded 才算成功。这句话没看到就不要进入下一步。3.3 冲突检查与 supersededapply 失败时先读懂这几行输出opatch apply 会自动做两种冲突检查duplicate 和 superseded。duplicate 是补丁已经应用过好办检查 inventory 确认即可。superseded 比较麻烦它表示当前补丁编号已被另一个更高版本的补丁覆盖直接 apply 会失败并列出冲突补丁清单。遇到 superseded 的正确姿势是不要硬打。Oracle 的补丁演进里新的补丁会替代旧的同类补丁。如果 opatch 提示已被 p 后面更大的补丁号取代把那更高的补丁下载下来应用才是正路。只有当你确认 ORACLE_HOME 里并不存在那个新补丁时才用 -override 绕过检查# 只有明确知道自己在做什么时才用 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -override另外apply 日志写在 $ORACLE_HOME/cfgtoollogs/opatch/opatch日期.log。失败时不要只盯屏幕最后几行打开日志搜 WARNING 和 ERROR冲突清单往往在日志中间位置而屏幕输出只显示末尾 20 行。这个坑我踩过一次补丁明明冲突我却看着最后的输出以为只是权限问题。4. 打完之后不算完验证、失效对象与回滚预案4.1 用 opatch lsinventory 和 lspatches 验证补丁状态apply 显示成功不代表结束第一步要验证补丁真的进了 inventory。我自己遇到过 apply 成功后 lsinventory 里看不到补丁编号的情况原因就是 apply 时 ORACLE_HOME 指向了另一个实例。所以验证必须显式指定 ORACLE_HOME。# 验证补丁是否在 inventory 中 $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 26635834 # 列出当前 ORACLE_HOME 下所有已应用的补丁 $ORACLE_HOME/OPatch/opatch lspatches说明lsinventory 输出很长grep 补丁号是最快的确认方式。lspatches 给出的是补丁概览能看到补丁的应用顺序。如果这一步报 Inventory check failed说明 inventory 记录有问题必须先修复再继续否则下次装其他组件也会受影响。4.2 启动数据库并重编失效对象utlrp.sql 不是可选项数据库启动后数据字典里可能有一批失效对象。PSU 和 CPU 补丁经常更新内部视图和包体新旧代码切换后部分对象状态变成 INVALID 是正常现象但必须处理。处理方式就是跑一遍 Oracle 官方的 utlrp.sql# 启动数据库 sqlplus / as sysdba EOF startup; exit; EOF # 重新编译失效对象 sqlplus / as sysdba $ORACLE_HOME/rdbms/admin/utlrp.sql说明utlrp.sql 会用并行方式编译 INVALID 对象执行时输出每类对象的编译情况。跑完后再查一遍残留失效对象-- 检查失效对象正常应该没有新的 INVALID 对象 col owner format a20 col object_name format a40 select owner, object_type, count(*) from dba_objects where status INVALID group by owner, object_type;有些补丁的 README 还会要求执行额外的 catalog 脚本比如部分 PSU 要求跑 catbundle.sql。判断依据就是 README 的 Post-Installation 章节我之前有一次打完 PSU 没跑这个脚本数据库启动后功能异常alert 日志里全是内部错误后来补跑才恢复正常。现在我把看 README 的 Post-Installation写进了打补丁的固定检查清单。4.3 opatch rollback后悔药不是什么时候都好吃OPatch 支持对大部分补丁执行回滚前提是 apply 时没有清理回滚信息。rollback 会把补丁涉及的文件恢复成 apply 前的状态。命令本身不复杂# 回滚单个补丁 $ORACLE_HOME/OPatch/opatch rollback -id 26635834 -oh $ORACLE_HOME参数说明-id 后面是补丁编号和 apply 时的编号一致。-oh 指定 ORACLE_HOME。回滚同样要求数据库处于 shutdown 状态流程与 apply 对称停监听、停库、rollback、启动、重新编译失效对象。如果存在多个补丁先回滚依赖它的补丁再回滚它本身。RAC 环境下还可以考虑 opatch auto它是把 apply/rollback 封装成交互式流程的脚本能管理多节点。但 auto 模式对目录布局有要求不是所有环境都能直接跑单实例上直接 rollback 更可控。我遇到过一次 rollback 失败的案例补丁 apply 成功后同事清理临时文件时手工删了 OPatch 目录下的 backup 信息回滚时报 Backup information not found。从那以后我养成了一个习惯apply 成功后在 /u01/backup 下存档一份 $ORACLE_HOME/cfgtoollogs/opatch 的日志备份。真到 rollback 时这份备份是最后的后悔药。5. 补丁应用避坑指南五条高频翻车记录5.1 现象opatch apply 报 OPatch version mismatch / OPatch requires version 11.2.0.3.9原因ORACLE_HOME 里的 OPatch 版本低于补丁要求的最低版本。补丁自带的环境检测脚本发现 OPatch 版本不达标直接拒绝执行。这个问题最容易出现在刚装完库、从没打过补丁的老环境。解决先升级 OPatch。用 p6880880 工具包覆盖安装到 $ORACLE_HOME/OPatch覆盖前做好备份。升级后重新 opatch version 确认版本号再重新跑 apply。这个坑的根因是没人拿 OPatch 当软件升级建议把它写进打补丁前预检脚本的第一步。5.2 现象unzip 解压后opatch apply 报 Patch ID not found原因phBaseDir 指向的目录不对。补丁 zip 解压后可能是两层目录比如 /tmp/patch/p26635834_112040_Linux-x86-64/26635834/把 phBaseDir 指到外层opatch 在里面找不到 etc/actions 元数据。解决用 ls -lR 查看目录结构找到真正包含 README.txt 和 etc 文件夹的目录层。另外检查解压时是否忘了 -d 参数没有 -d 时 zip 会把文件直接散落在当前目录目录结构完全被破坏。这个坑的通用教训是解压后先看目录再进补丁路径。5.3 现象apply 中途报 OUI-10086: Central Inventory is not accessible原因oracle 用户对 /u01/app/oraInventory 没有写权限或者 inventory 目录被 root 操作改了属主。很多服务器为了安全会把基础目录锁成 root 属主打补丁前又忘了放权。解决恢复属主和权限chown -R oracle:oinstall /u01/app/oraInventorychmod -R 775。然后重新执行 lsinventory 确认可读。如果权限没问题但仍报错检查 /etc/oraInst.loc 里记录的 inventory 路径是否与实际一致。我见过一台机器因为 /etc/oraInst.loc 指向了旧路径导致 OPatch 怎么都找不到 inventory。5.4 现象apply 过程中报 No space left on device日志尾部全是磁盘写入失败原因ORACLE_HOME 所在文件系统空间不足。opatch apply 会先备份被替换的文件备份文件也占用 ORACLE_HOME 空间剩余空间不够时 apply 直接中断而且中断后可能残留半应用状态。解决apply 前先 df -h 看 ORACLE_HOME 文件系统的剩余空间用 opatch prereq CheckSystemSpace 也能预判。如果空间不足先清理监听日志、DIAG 诊断日志和过期归档。这里有个细节空间不足时不要只清 /tmp补丁备份写的是 ORACLE_HOME 所在分区必须看那一块的余量。5.5 现象补丁打完数据库启动后 alert 日志刷 ORA-00600 / ORA-04031原因补丁更新了数据字典或内部函数版本但补丁后续要求的 SQL 脚本没有执行旧的对象状态和新字典不一致。这种情况在 PSU 上特别常见因为 PSU 通常要求在数据库打开状态下执行后续脚本。解决回到 README 的 Post-Installation 章节找到要求的 SQL 脚本。一般是 utlrp.sql 或 catbundle.sql用 sysdba 身份执行。执行完再查 dba_objects 里 INVALID 对象数量直到清零。如果脚本执行完还有 ORA-00600把 alert 日志里 args 参数记下来再决定是否需要走 MOS 提服务请求。6. 进阶技巧把补丁应用做成一条可回滚的命令管道6.1 用 napply 批量应用多个补丁一个安全补丁周期里往往不止一个补丁。逐个 cd 进去 apply 效率低中途失败还会打断流程。opatch 提供 napply 命令指定一个目录它会自动识别目录下所有待应用补丁并批量执行# 把多个补丁按编号放在同一个目录下 $ORACLE_HOME/OPatch/opatch napply -oh $ORACLE_HOME -phBaseDir /tmp/patch说明napply 会先扫描 inventory自动过滤已应用的补丁然后按补丁间依赖关系依次应用。相比手动循环napply 会在一个时间窗口内处理完多个补丁日志统一写到同一个目录排障时不用翻多个日志文件。6.2 打补丁前先留 inventory 快照回滚不再靠猜回滚最怕的是不知道打补丁前 inventory 长什么样。我现在养成的习惯任何补丁应用前先做一份 inventory 快照存档# 打补丁前记录 inventory 快照 mkdir -p /u01/backup/opatch_snapshots $ORACLE_HOME/OPatch/opatch lsinventory -detail /u01/backup/opatch_snapshots/pre_patch_$(date %Y%m%d_%H%M%S).txt # 同时备份 OPatch 日志目录 cp -rp $ORACLE_HOME/cfgtoollogs/opatch /u01/backup/opatch_snapshots/opatch_logs_$(date %Y%m%d_%H%M%S)参数说明lsinventory -detail 输出全量补丁列表和组件版本回滚前比对这份快照能确认当前系统是否被其他操作污染过。日志目录备份是给 rollback 找不到 backup 信息时用的最后后悔药。补丁应用做到最后玄学成分其实很少大部分翻车都源于漏了一步预检或没读 README。从那以后我每个季度安全补丁窗口都强制自己走完整套流程解压前先 md5解压后看 READMEapply 前跑 prereqapply 后跑 utlrp最后存档 inventory 快照。麻烦是麻烦一点但比起凌晨两点在机房对着日志发懵这套动作能省下好几条命。希望帮到你。本文还有配套的精品资源点击获取