简介这份资源是面向Oracle数据库运维人员与DBA的官方补丁包补丁号24006111适用于64位Linux平台上的Oracle 11.2.0.4版本属于2016年10月发布的季度累积补丁11.2.0.4.161018。它针对生产库长期运行中暴露的缺陷修复、安全加固与性能优化需求适合仍处于11gR2维护周期内的系统做定期更新与版本对齐。压缩包约100.6MB包内以补丁二进制文件和XML格式的补丁说明文档为主前者配合Opatch完成安装与回滚后者记录补丁适用性、依赖关系与安装指引便于在动手之前核对环境是否匹配。该资源已有265人学习或下载。借助它读者可以理清补丁前置检查、数据库备份与停机窗口规划的要点掌握Opatch验证、应用、回滚的完整流程并据此建立季度补丁的跟踪与评估习惯降低升级过程中出现兼容性问题的风险。1. 四十分钟窗口里翻车p24006111 这个 Oracle 补丁包不是解压就能装有次接手一套 11.2.0.4 的库停机窗口只批了四十分钟我把 Oracle 补丁包 p24006111 解压出来就直接opatch apply第一行输出就顶回来OPatch 版本太旧认不出这个补丁。换了 OPatch 重新来prereq 又报和已装补丁冲突。四十分钟全烧在排查上最后原样回滚业务照旧跑在老版本上白熬一夜。文件名其实早把答案写在脸上p24006111_112040_Linux-x86-64.zip前半段是补丁编号112040对应数据库 11.2.0.4Linux-x86-64限定平台三个条件缺一个这包就打不上去。这种 11.2.0.4 的存量库在机房里到处都是装不好的代价不是屏幕上几行报错而是实例起不来、只能拿备份顶。这篇笔记写给我自己也写给手上有一到两套 11.2.0.4、需要在有限窗口里把补丁打稳并留好回滚路径的人。2. 装前清点11.2.0.4 的版本底账和 OPatch 版本必须先对齐补丁装不上九成原因不在补丁本身而在装之前没把环境底账翻开。11.2.0.4 这个版本生命周期长、补丁层级乱同一台机器上可能装过好几轮 PSU$ORACLE_HOME里的 OPatch 还停留在出厂状态。我现在的习惯是动手前先花十分钟把版本、OPatch、平台、属主四件事全部打印出来抄在一张纸上后面每一步都对着这张纸走。先解释文件名这一步很多人跳过。补丁包命名是固定的字段拼接读懂它就知道该往哪台机器上放文件名字段含义装错会怎样p24006111补丁编号opatch lspatches里会显示装错编号回滚时找不到对应 id112040目标数据库版本 11.2.0.4版本不符prereq 直接判不适用Linux-x86-64平台与位数平台不符apply 阶段报二进制不匹配.zip补丁包压缩格式需先解压出同名目录直接对 zip 执行 opatch 会报找不到 patch 目录2.1 三处版本号对齐数据库、OPatch、操作系统环境变量先确认干净。切换用户一律用su - oracle带减号才会加载 oracle 用户的 profile用su oracle切换过去ORACLE_HOME往往是空的后面所有命令都会落到错误的路径上这类错误最难查因为命令本身不报错只是默默对着/或者别人的 home 干活。# 必须带减号加载 oracle 用户的环境变量 su - oracle # 1. 数据库版本看是否是 11.2.0.4 这一档 sqlplus -v # 或者进库看 sqlplus / as sysdba EOF select * from v$version; exit EOF # 2. OPatch 版本决定这个补丁能不能被识别 $ORACLE_HOME/OPatch/opatch version # 3. 操作系统与位数必须和文件名里的 Linux-x86-64 对上 uname -m cat /etc/issue # 4. 关键环境变量四个都要有值 echo $ORACLE_HOME echo $ORACLE_SID echo $PATH | tr : \n | grep -i oracleopatch version输出的格式是OPatch Version: 11.2.0.3.x这个 x 就是判断依据。11.2.0.4 上如果 OPatch 还停在 11.2.0.3.0 附近的早期版本面对编号较大的新补丁基本都会拒识。我一般会把 OPatch 升到 11.2.0.3.32 或更新的同系列版本理由很实际新补丁的etc/config/inventory.xml里带了较新的 schema 校验老 OPatch 读不懂就直接退出。还有一点容易被忽略$PATH里可能同时挂着两个 ORACLE_HOME 的 bin 目录。打补丁期间如果which opatch指到了另一个 home你会对着 A 库执行、结果打在 B 库上。执行前用which opatch核一次路径比事后翻日志省事得多。2.2 OPatch 升级为什么必须在 apply 之前落地OPatch 是独立于数据库的一个小工具目录升级它不涉及实例风险很低但顺序错了就要返工。我的做法是先备份再替换备份目录留在同一块盘上出问题一条mv就能回去。# 1. 备份现有 OPatch带上日期方便回退 cd $ORACLE_HOME cp -a OPatch OPatch.bak.$(date %Y%m%d) # 2. 解压新版 OPatch 包p6880880 这一档的包解压后就是 OPatch 目录 # 注意解压到临时目录不要在 $ORACLE_HOME 下直接解避免覆盖一半 mkdir -p /u01/soft/opatch_new cd /u01/soft/opatch_new unzip -o p6880880_112000_Linux-x86-64.zip # 3. 替换先删旧目录再搬新的保持属主一致 rm -rf $ORACLE_HOME/OPatch mv /u01/soft/opatch_new/OPatch $ORACLE_HOME/ chown -R oracle:oinstall $ORACLE_HOME/OPatch chmod -R 775 $ORACLE_HOME/OPatch # 4. 验证 $ORACLE_HOME/OPatch/opatch versioncp -a的-a是保留权限和时间戳OPatch 目录里有可执行文件丢了执行位后面会报 permission denied。chown那行的组名按你机器上实际的dba组写有的环境是dba有的是oinstall加dba双组。替换完立刻跑一次opatch version版本号变了才算成功如果报Java相关错误多半是解压时丢了opatch/jlib下的 jar重新解一遍即可。提醒一句OPatch 升级不需要停库但如果这套库正在跑批尽量避开业务高峰因为替换瞬间如果有人恰好执行opatch命令会拿到半残目录。2.3 补丁包解压位置与属主别在 $ORACLE_HOME 里解压补丁包不要解压到$ORACLE_HOME里面。apply 过程中 OPatch 会遍历 home 下的文件做校验多出来的补丁目录会干扰 inventory 的判断历史上就有人因此拿到莫名其妙的空间不足报错。我的固定路径是/u01/soft/patch/解压后得到一个24006111目录。# 建独立补丁目录属主给 oracle避免用 root 解压后 apply 报权限错 mkdir -p /u01/soft/patch chown -R oracle:oinstall /u01/soft/patch su - oracle cd /u01/soft/patch unzip -q p24006111_112040_Linux-x86-64.zip # 检查解压结果重点看 README.html 和 etc/config/inventory.xml 在不在 ls -l /u01/soft/patch/24006111-q是静默解压避免几百行文件名刷屏。解压完一定要ls一眼标准的补丁目录里应该有README.html里面写了这个补丁适用的版本、前置补丁、是否需要跑 catbundle、etc/config/inventory.xml、files/下的二进制替换件。README.html是这套环境里唯一的黑匣子花三分钟看它的「Prerequisites」一节能省掉后面一小时排错。如果解压是用 root 做的chown -R补一次属主否则 apply 阶段会报Unable to create directory或者写 inventory 失败。3. 冲突预检和备份把打不上提前判掉很多人把opatch apply当成第一步动作其实它应该是最后一步。真正决定成败的是前面这几条 prereq 检查跑完它们你才知道这个补丁在这台机器上到底能不能装、装完还剩多少余地。3.1 prereq 三条检查冲突、空间、依赖OPatch 自带一组检查命令-ph后面跟补丁目录的绝对路径或者相对路径都行但必须是解压后那个24006111目录不是 zip。cd /u01/soft/patch # 1. 与当前 ORACLE_HOME 已装补丁的冲突检查最关键的一条 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./24006111 # 2. 系统空间检查看 /tmp 和 $ORACLE_HOME 所在文件系统够不够 $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -ph ./24006111 # 3. 被占用的活动文件检查跑之前确认没有进程还在用 home 里的二进制 $ORACLE_HOME/OPatch/opatch prereq CheckActiveFilesAndExecutables -ph ./24006111第一条的输出里Prereq checkConflictAgainstOHWithDetail passed.才算过关如果列出若干补丁编号并标failed说明这些补丁和 p24006111 有文件级重叠必须先确认它们是被本补丁包含superseded还是真正冲突。判断依据就在补丁目录的README.html里它一般会写明「这个补丁替代了哪些编号」被替代的那些不需要先卸。第二条经常被人忽略。11.2.0.4 的$ORACLE_HOME动辄二三十 Gapply 时会先在 home 里生成备份副本空间不足时表现出的报错是Error: Insufficient disk space看着像权限问题其实是盘满了。我的经验值是$ORACLE_HOME所在文件系统至少留出 home 体积的 1.5 倍空闲/tmp留 2G 以上。第三条只有输出No active files才干净。如果提示某个.so被占用说明还有实例或者监听在跑先按第 4 章的顺序停干净。3.2 备份两件事home 二进制和数据库本身补丁打坏了后悔药只有两种opatch rollback和 home 备份。而 rollback 依赖 inventory 记录完整如果 apply 中途被打断inventory 可能是半写状态这时候只能靠文件级备份。# 1. 记录打补丁前的完整补丁清单出问题时用它对账 $ORACLE_HOME/OPatch/opatch lsinventory -detail /u01/backup/inv_before_$(date %Y%m%d).txt # 2. 文件级备份 ORACLE_HOME 的关键子目录全量太慢就至少备这几个 cd $ORACLE_HOME tar -czf /u01/backup/oracle_home_bin_$(date %Y%m%d).tar.gz \ bin lib rdbms/lib rdbms/admin network/lib OPatch # 3. 数据库侧做一次全备这是最后一道底线 rman target / EOF backup database plus archivelog; exit EOFtar那一行只备份了二进制和库文件目录不是全量 home好处是体积小、速度快能在窗口内做完坏处是不含dbs、network/admin之外的配置。真出大问题配置那部分本来也不该被补丁改动所以这个取舍我认为合理。如果你的窗口宽裕直接cp -a $ORACLE_HOME $ORACLE_HOME.bak更省心代价是多占几十 G。备份完把三个路径写进变更单里inventory 文本、tar 包、RMAN 备份集。出事的时候没人愿意现场翻历史命令。4. 正式 apply单实例从停库到 catbundle 的完整命令线前面都过了真正的补丁动作其实只有十几分钟剩下的时间都在等待和验证。这一章按执行顺序走一遍命令可以直接抄参数我会说清每一项为什么这么写。4.1 停库顺序监听、实例、后台进程逐个确认顺序错了会出现CheckActiveFilesAndExecutables过不去或者 apply 结束实例起不来。标准顺序是先停应用连接、再停监听、最后停实例。su - oracle # 1. 停监听避免打补丁期间有新连接进来 lsnrctl stop # 2. 停实例用 immediate 而不是 abort sqlplus / as sysdba EOF shutdown immediate; exit EOF # 3. 确认没有残留的 oracle 进程还挂着 home 里的文件 ps -ef | grep -i ora_ | grep -v grep ps -ef | grep -i tnslsnr | grep -v grepshutdown immediate会回滚未提交事务并做一次检查点比abort安全得多用abort虽然快但下次启动要做实例恢复在打补丁这种本来就紧张的窗口里没必要给自己加戏。第三条命令输出为空才算干净如果还有ora_pmon_xxx残留kill -9之后等十秒再查一次。RAC 环境多一步每个节点都要停且srvctl stop instance -d db_unique_name -n node比手工 shutdown 更稳因为它会同步更新集群里的实例状态。如果补丁同时覆盖 Grid Infrastructure先打 GI home 再打 DB home顺序反了 DB 补丁会报 GI 版本不匹配。4.2 opatch apply 的参数取舍# 进入补丁目录执行-silent 只输出关键信息-local 表示只打当前节点 cd /u01/soft/patch/24006111 $ORACLE_HOME/OPatch/opatch apply -silent -local # 打完之后立刻确认补丁在清单里 $ORACLE_HOME/OPatch/opatch lspatches-silent不是省事是为了让日志干净。它会跳过交互式确认把结果写成一行一行的状态方便你grep关键字。失败时不要只看屏幕上最后几行去$ORACLE_HOME/cfgtoollogs/opatch/下找当次的日志文件那里有完整的调用栈。-local在单实例上是可选的在 RAC 上强烈建议加上因为它只处理当前节点的 home避免 OPatch 试图去连别的节点却因为互信没配好而卡住。代价是每个节点都要单独跑一遍。apply 成功时能看到ApplySession applying interim patch 24006111 to OH和最后一行OPatch succeeded.。中间可能刷出大量Copying file行正常现象别急着 CtrlC。如果中途报Prerequisite check CheckActiveFilesAndExecutables failed说明还有进程占文件回到 4.1 重新确认。4.3 收尾catbundle 与 utlrp别漏了字典更新二进制替换完不等于结束11.2.0.4 上还有一个必做动作跑catbundle.sql。这一步更新数据字典里的组件版本和注册信息漏掉它dba_registry里的版本号还是旧的后续再打补丁会判版本不一致。# 启动实例后再跑字典脚本注意不是 nomount sqlplus / as sysdba EOF startup ?/rdbms/admin/catbundle.sql psu apply ?/rdbms/admin/utlrp.sql exit EOF # 检查有没有编译失败的无效对象 sqlplus / as sysdba EOF select count(*) from dba_invalid_objects; select comp_name, version, status from dba_registry order by comp_name; exit EOFcatbundle.sql后面跟的psu apply是两个参数前者是脚本接受的入口参数名后者表示应用方向回滚时对应的是psu rollback别写反。脚本执行中会生成catbundle_*.log落在当前工作目录跑完grep -i error扫一遍。utlrp.sql负责重编译失效对象11.2.0.4 上跑完通常要几分钟到十几分钟视对象数量而定。跑完dba_invalid_objects计数应该是 0 或者个位数如果还有几十上百个先看dba_objects里这些对象属于哪个 schema多半是某个自有 schema 的对象依赖了刚被替换的包手工重编译一次即可不是补丁本身的问题。5. 避坑与排查五个只有真打过补丁才会遇到的坑这一章的五条都是我自己或者同事在 11.2.0.4 上实际撞过的按现象、原因、解决的顺序写能对号入座最好。5.1 apply 阶段的三个高频失败现象opatch apply第一行就报Patch 24006111 is not applicable to the current ORACLE_HOME但版本确实是 11.2.0.4。原因补丁包的inventory.xml里限定了目标 home 的版本和已装补丁基线OPatch 读到的 OPatch 版本太旧解析不了新的 schema于是直接判不适用。 解决先opatch version确认低于 11.2.0.3.32 档位就先升 OPatch升完再跑一次 prereq。九成版本明明对却打不上都是这一条。现象prereq 冲突检查列出三四个补丁编号标failed看着像真的打架。原因这些补丁是被 p24006111 替代superseded的旧补丁冲突检查只做机械比对不判断替代关系。 解决打开补丁目录的README.html找Patches superseded by this patch那一节逐个核对编号。在替代列表里的不用管不在列表里的才是真冲突真冲突要么先回滚那个补丁要么换一个包含它的更新包。现象apply 跑到一半报Error: Insufficient disk space但df -h看着还有不少空间。原因OPatch 会在$ORACLE_HOME下先做一份文件副本实际占用是补丁体积的好几倍而df看的是文件系统级余量可能被别的目录占着。 解决du -sh $ORACLE_HOME看实际体积留出 1.5 倍空闲再重试。空间实在腾不出来把$ORACLE_HOME/.patch_storage下历史补丁的备份目录清掉一部分那些是旧补丁的回滚基础清之前确认不再需要回滚。5.2 打完之后两个更隐蔽的坑现象补丁打完了opatch lspatches能看到编号但实例起不来alert log 里刷ORA-04063: package body ... has errors。原因要么漏跑了catbundle.sql要么跑的时候实例处于 nomount/mount 状态字典脚本没真正执行完。 解决确认实例处于 open 状态重跑一次?/rdbms/admin/catbundle.sql psu apply再跑utlrp.sql。重跑是幂等的脚本内部有版本判断不会重复应用。现象opatch lspatches里查不到刚打的补丁但 apply 明明输出了 succeeded。原因执行 apply 时没有用su - oracleORACLE_HOME指向了另一个 home补丁打在了别处或者-invPtrLoc指向了错误的 inventory 文件记录写到了非默认位置。 解决用find / -name oraInst.loc 2/dev/null找出所有 inventory 位置逐个用opatch lsinventory -invPtrLoc 路径查找到补丁落在哪个 home 上。补救办法是在正确的 home 上重新 apply 一次别试图手工改 inventory。提示这五条里有四条在动手前花十分钟就能规避真正必须现场排查的只有空间那一条。6. 装完怎么验证三张表过一遍再做一次回滚演练补丁装完那一刻是最容易松劲的时候OPatch succeeded.只说明文件替换完成说明不了这套库还能不能正常跑。我现在固定走三张检查缺一张不签字。检查项命令合格标准补丁清单$ORACLE_HOME/OPatch/opatch lspatches能看到 24006111且无其他补丁被意外移除组件版本select comp_name,version,status from dba_registry;状态全为 VALID版本与补丁基线一致对象健康度select count(*) from dba_invalid_objects;计数为 0 或个位数除了这三张表还有两件事我会顺手做完连一次监听确认lsnrctl status里服务注册正常然后从一个应用连接串做一次真实的增删改查这一步比任何 SQL 都更能说明问题。alert log 也要扫一遍grep -i -E ORA-|error看有没有被忽略的报错。最后一步是很多人省掉、但我坚持做的回滚演练。不是真回滚而是在心里走一遍路径确认$ORACLE_HOME/.patch_storage下这个补丁的回滚基础还在opatch rollback -id 24006111这条命令拿得到。如果空间紧张被清掉了至少要知道自己没有退路别等到出事才发现。我踩过最疼的一次是补丁装完直接走了第二天早上业务连上来报ORA-06553一查是漏跑utlrp.sql几十个包还是失效状态。从那以后我每次打完补丁dba_invalid_objects的计数不归零就不离开机房哪怕窗口已经超时。这一条比任何参数说明都值钱希望帮到你。本文还有配套的精品资源点击获取