Oracle 11.2.0.1 打补丁全流程：OPatch 顺序、回滚与验证

简介Oracle 11.2.0.1 数据库补丁安装指南文档面向需要为旧版 Oracle 实例做补丁维护的初中级 DBA 与系统运维人员聚焦补丁准备、OPatch 应用、版本核验与异常回退等实际场景也可供数据库课程实验和版本升级前评估参考。压缩包共 1 个 doc 文件约 942KB以步骤化文字整理便于离线查阅与随身参考。已有 131 人学习下载对仍在运行同版本的环境具有一定参考价值。内容覆盖打补丁前的实例关闭与完整备份、OPatch 解压和环境变量设置、按补丁编号由小到大逐个应用并确认成功提示以及安装后的补丁清单核验与功能测试同时给出查看已装补丁、回滚单个补丁、检查前置条件等排错思路并提醒保留原始补丁包备用。适合作为 Oracle 11g 补丁维护的速查手册帮助读者理清流程、减少漏装和误操作风险。1. Oracle 11.2.0.1 打补丁顺序错一步OPatch 会让你从头再来一台还跑着 Oracle 11.2.0.1 的老业务库安全扫描报告上组件版本那一栏被标红留给变更的窗口只有两个小时。补丁包拿到手是一串以数字命名的目录主机是 WindowsORACLE_HOME 落在D:\oracle\product\11.2.0\dbhome_1。这种场景里最麻烦的从来不是命令本身而是顺序和状态管理补丁必须从编号小的往大的逐个 apply中间任何一步没看到 succeed 就继续往下走最后大概率要整库回滚重来。下面这套流程覆盖 OPatch 就位、实例停机、逐个补丁执行、失败定位与回滚边界也写清楚了哪些步骤能省、哪些一步都不能跳。手上压着一份数据库补丁包却一直不敢下手的人照着走一遍即可。2. 动手前的账要算清OPatch、补丁编号与 ORACLE_HOME 三方对齐2.1 先确认 OPatch 版本再谈补丁能不能打11.2.0.1 这个版本的安装介质里自带的 OPatch 通常停在很老的一代。而后续发布的补丁包在 README 的 Prerequisites 一节里会明确写「需要某个版本以上的 OPatch」。版本不够时opatch apply往往跑不了几行就退出报一个 error code 73看起来像补丁包坏了实际上只是工具太旧。所以第一步不是急着 apply而是把当前版本号打出来看一眼。set ORACLE_HOMED:\oracle\product\11.2.0\dbhome_1 %ORACLE_HOME%\OPATCH\opatch version这条命令会输出形如OPatch Version: 11.2.0.x.x的一行。set ORACLE_HOME只在当前命令行窗口内有效关掉窗口就失效这是很多人第二次打开 cmd 就报错的原因。如果你习惯用管理员权限新开窗口记得在同一个窗口里把 set 和 opatch 连着敲。版本对不上时要做的是替换 OPatch 目录而不是替换整个 ORACLE_HOME。我的习惯是先改名备份再放新的进去这样万一新版 OPatch 在你的环境里水土不服把旧目录改回来就能恢复原状。cd /d %ORACLE_HOME% ren OPatch OPatch_bak_before_patch mkdir OPatch然后把新版 OPatch 压缩包解压把解压出来的内容注意是目录里面的内容不是外面那层壳整体拷进%ORACLE_HOME%\OPatch再跑一次opatch version确认版本已经变了。这里有个细节解压工具如果多套了一层同名目录实际路径会变成OPatch\OPatch\opatch.bat命令就找不到入口跑起来提示「不是内部或外部命令」。遇到这种提示先看目录层级别怀疑补丁包。需要注意替换 OPatch 本身不需要停库但替换完成后要重新开一个 cmd 窗口避免旧窗口里的环境变量和路径缓存干扰判断。2.2 补丁编号怎么读p 号、目录结构与 README数字补丁包解压后一般长这样外层目录名以p加一串数字开头里面是若干固定结构的子目录和说明文件。搞清每个位置是干什么的比背命令有用得多。目录或文件作用打补丁时怎么用p加数字的根目录补丁的唯一标识cd进去再执行opatch applyREADME.html/README.txt版本要求、前置补丁、安装后脚本动手前必读重点看 Prerequisites 和 Post-Installationetc\config\inventory.xml补丁元数据由 OPatch 读取不要手改files\下的各级目录实际要被替换的文件OPatch 自动拷贝不用手动覆盖custom\或sql\一类目录需要人工执行的 SQL 脚本按 README 指引在 apply 成功之后执行编号的大小不是装饰。同一个版本线上后发布的补丁通常依赖前面已经打过的补丁README 里会用「requires patch X」的方式写清楚。这就是为什么必须从数字小的往大的打一次性跳着打OPatch 会在冲突检测阶段直接拦下来或者更糟——打进去了但数据库组件状态不一致。另外一个容易被忽略的点多个补丁不要解压到同一个文件夹里。有人图省事把三四个补丁全解压到D:\patch根下文件互相覆盖最后opatch apply读到的是混合体。一个补丁一个目录目录名保持原样这是最省心的做法。2.3 ORACLE_HOME 与实例状态的检查清单补丁只能在实例完全停止的状态下打。Windows 上「停止实例」和「停止服务」是两件事shutdown immediate关的是数据库监听器和服务还在跑ORACLE_HOME 下的可执行文件依然被占用。echo %ORACLE_HOME% dir %ORACLE_HOME%\bin\oracle.exe第一行确认环境变量指到了正确的 ORACLE_HOME第二行确认这个路径下确实有 Oracle 主程序。一台机器上装了多个 home 的情况并不少见指错了 home补丁就打到了另一个库上这种情况回滚都救不回来。sqlplus / as sysdba SQL select instance_name, status from v$instance; SQL shutdown immediate; SQL exitv$instance里的 status 应该是 OPEN 或 MOUNTED确认实例名没搞错。shutdown immediate会回滚未提交事务并断开所有会话如果有长事务卡住它会等这时不要强行 CtrlC再等一会儿或换shutdown abort并接受实例恢复的代价。lsnrctl stop net stop OracleServiceORCL tasklist | findstr /i oracle.exe tnslsnr.exe服务名里那一段按你实际的 SID 替换。tasklist那条是收尾检查正常应该什么都不输出。如果还能看到oracle.exe或tnslsnr.exe说明有东西没停干净最常见的是图形化工具还连着库、EM 控制台进程还在跑或者有人开了个 sqlplus 窗口没关。带着进程打补丁OPatch 会在替换 DLL 和 EXE 时失败日志里留下一个CheckActiveFilesAndExecutables的失败项。3. 按编号从小到大逐个 apply一套可复现的命令序列3.1 解压与目录布局补丁包统一放在一个短路径下不要带中文、空格和括号。D:\patch这种就很好。解压工具用常见的即可重点是每个补丁解压出来是独立的顶层目录。D: cd \patch dir /bdir /b只列名字方便一眼看全有几个补丁、编号顺序对不对。输出里应该是一行一个p开头的目录。如果看到解压出来的目录里还有一层同名目录说明解压时多包了一层需要进到里层去那里才是README.html和files的所在层。判断标准很简单执行opatch apply的那个目录必须有etc和files这两个子目录否则一定是在错误的层级上。解压后的原始压缩包不要删理由放在后面的避坑清单里讲。3.2 单个补丁的完整执行流程先拿编号最小的那个练手确认整个链路通再批量往下走。set ORACLE_HOMED:\oracle\product\11.2.0\dbhome_1 cd /d D:\patch\p1234567 %ORACLE_HOME%\OPATCH\opatch apply三行的作用依次是指定目标 ORACLE_HOME、切到补丁目录、执行应用。opatch apply默认作用于当前 ORACLE_HOME所以不需要额外传-oh除非你要给别的 home 打补丁才用-oh 路径显式指定。在 Windows 上不带参数的opatch apply会拉起图形化的安装界面中途要点几次确认。机房远程桌面卡的时候这个过程很难受所以批量阶段一般加参数走静默%ORACLE_HOME%\OPATCH\opatch apply -silent -waitforcompletion-silent表示不弹界面-waitforcompletion让命令等到补丁真正装完才返回。老版本 OPatch 在静默模式下有可能提前返回你以为打完了其实后台还在拷贝文件紧接着打下一个补丁就会撞车加上这个参数能避免大部分误判。执行过程中会先做一轮前置检查ORACLE_HOME 是否有效、补丁是否已经打过、有没有冲突、有没有被占用的文件。这几项任何一项失败命令会停下来并给出具体项名不会硬着头皮改文件。看到失败不要习惯性地按回车继续去日志里找那个具体项名处理完再重跑重跑是安全的。3.3 多补丁串行执行与 succeed 判读手工一个个敲当然可以但如果窗口时间紧、补丁有五六个写个循环更稳。前提是一定要做到「失败即停」绝不能让脚本跨过失败的补丁继续往下打。echo off setlocal set ORACLE_HOMED:\oracle\product\11.2.0\dbhome_1 set PATCH_ROOTD:\patch for /d %%D in (%PATCH_ROOT%\p*) do ( echo applying %%~nxD pushd %%D %ORACLE_HOME%\OPATCH\opatch apply -silent -waitforcompletion if errorlevel 1 ( echo FAILED at %%~nxD , stop here popd exit /b 1 ) popd ) echo ALL PATCHES DONEfor /d遍历目录%%~nxD取目录名只作打印用pushd/popd保证每个补丁结束后回到原目录。if errorlevel 1是这段脚本的关键只要有任何一个补丁返回非零立刻打印失败目录名并退出后面的补丁不会被执行。这里必须提醒一句for /d是按目录名的字符顺序遍历的不是按数字大小。补丁编号位数一致时字符序和数字序恰好相同一旦编号位数不同比如一个 7 位一个 8 位顺序就会乱。所以跑脚本之前先dir /b看一眼必要时把循环改成显式列目录名的写法或者干脆手工按编号顺序执行。这类细节不值得赌打错顺序的代价是整库回滚。判断成功的标志是输出里出现OPatch succeeded.。静默模式下这行照样会打出来看到它再进下一个目录。如果只看到OPatch completed with warnings不要当成功处理去日志里看警告内容多数是某个文件校验值不一致或有组件未安装需要人工判断。3.4 重启与自启验证全部补丁打完先别急着重启服务器。先在命令行里把实例拉起来确认能正常 OPEN再重启机器。sqlplus / as sysdba SQL startup SQL select instance_name, status from v$instance; SQL exitstartup之后 status 应该是 OPEN。如果卡在 MOUNTED 或者报错说明补丁引入了问题这时候服务器还没重启处理窗口更宽裕。确认能起之后再按补丁说明决定是重启服务器还是重启服务即可。net start OracleServiceORCL sc qc OracleServiceORCLnet start拉起数据库服务sc qc看启动类型START_TYPE 应该是 AUTO_START。如果是 DEMAND_START说明这台机器原来就配成手工启动重启服务器后数据库不会自己起来这跟补丁无关但会被误认为「打完补丁库起不来了」。这种误会排查起来很浪费时间提前看一眼能省掉。机器重启完成后再连一次库跑个简单查询确认监听和实例都正常然后就可以进入验证环节了。4. 补丁失败之后lsinventory、回滚与日志定位4.1 建基线lsinventory 与 lspatches打补丁之前先存一份当前的补丁清单这是后续所有判断的依据。%ORACLE_HOME%\OPATCH\opatch lsinventory -detail D:\patch\before_patch_inventory.txt-detail会输出每个已安装补丁的编号、组件、安装时间和唯一 ID。存成文本最大的好处是对比打完补丁再导一份after_patch_inventory.txt用文本比对工具一拉新增了哪些补丁一目了然。较新的 OPatch 还提供lspatches子命令输出更紧凑一行一个补丁号如果提示未知命令说明你的 OPatch 版本偏老用lsinventory -detail即可功能上是等价的。这两份文件在事后复盘时价值很高。变更单上写着「打了三个补丁」实际清单里只多了两个第三个别提多难受——有基线文件就能立刻定位是没打上还是打到了别的 home。4.2 日志在哪错误码背后的真实原因OPatch 的完整日志在%ORACLE_HOME%\cfgtoollogs\opatch\下面文件名形如opatch_时间戳.log同时每个补丁还会生成一个以补丁号命名的子目录里面是更细的执行记录。命令行窗口里看到的只是摘要真正的原因都在这里。错误码常见含义处理方向73OPatch 版本不足或补丁与当前 ORACLE_HOME 版本不匹配升级 OPatch核对补丁适用的版本线104补丁已应用过或与已装补丁冲突用lsinventory确认是否重复看冲突检测输出134前置检查未通过进日志找具体的 prereq 项名逐项处理错误码只能缩小范围最终判断仍然要回到日志文本。日志里搜CheckActiveFilesAndExecutables、CheckConflictAgainstOHWithDetail、Prerequisite这几个关键词能最快定位到失败的那一步。第一次看这种日志会有点懵因为日志前后夹杂了大量环境信息习惯做法是直接从文件末尾往上翻第一个ERROR附近就是问题现场。4.3 回滚的边界什么能退什么退不回去单个补丁可以通过补丁 ID 回滚前提是这个补丁之后打的补丁还没有改变同一批文件。set ORACLE_HOMED:\oracle\product\11.2.0\dbhome_1 %ORACLE_HOME%\OPATCH\opatch rollback -id 1234567-id后面跟的是补丁编号不是目录名两者一般一致但要以lsinventory里的记录为准。回滚同样要求实例处于停止状态前面那套停库、停监听的流程要重走一遍。回滚的顺序是后打的先退。A、B、C 三个补丁依次打上要退 A 就得先退 C 和 B因为有文件覆盖关系。这一点和打补丁的方向正好相反很多人在这里踩坑直接对最早的补丁执行 rollback命令可能报错也可能成功但留下一个组件版本错乱的库。还有一处回滚覆盖不到的地方补丁包里那些需要人工执行的 SQL 脚本。opatch rollback只还原二进制和部分配置数据字典里的记录不会自动退回去。所以打补丁前对数据库做一次完整备份数据文件、控制文件、参数文件、归档日志不是形式主义它是 SQL 部分唯一的后悔药。4.4 前置条件检查与冲突检测在真正 apply 之前可以单独跑一遍检查把问题暴露在动手之前。cd /d D:\patch\p1234567 %ORACLE_HOME%\OPATCH\opatch prereq CheckConflictAgainstOHWithDetail -ph ./ %ORACLE_HOME%\OPATCH\opatch prereq CheckActiveFilesAndExecutables -ph ./-ph ./表示以当前目录作为补丁目录。第一条查冲突与已装补丁是否重叠、是否缺少前置补丁。第二条查占用有没有进程锁着要替换的文件。两条都过了再 apply成功率会高很多。这两条命令还有个大用处批量补丁之前先把每个补丁都跑一遍 prereq一次性发现「第 4 个补丁缺前置」这种问题比打到一半才发现要好得多。5. 避坑清单五个让补丁前功尽弃的细节5.1 报OPatch failed with error code 73就认定补丁包坏了现象命令刚跑起来就退出日志里翻不出任何文件级操作记录只留一个 73。原因九成以上是 OPatch 版本不够读不懂这个补丁的元数据格式少数情况是补丁适用的版本线不对比如拿了 11.2.0.4 的补丁往 11.2.0.1 上打。解决先opatch version和补丁 README 里要求的最低版本对比不够就按 2.1 节的方式替换 OPatch。替换之后仍然报 73就回头核对补丁的适用版本别在错版本的补丁上死磕。5.2CheckActiveFilesAndExecutables失败反复重试都不过现象前置检查阶段报某个文件被占用重跑三五次结果一样。原因shutdown immediate只关了实例监听器、EM 控制台进程、图形化客户端、甚至某个忘记关掉的 sqlplus 窗口都可能在 ORACLE_HOME 下持有文件句柄。Windows 不像 Linux 那样能直接查到谁锁着文件表现出来就是「明明停了库还是说占用」。解决按顺序停监听、停数据库服务然后tasklist | findstr /i oracle.exe tnslsnr.exe确认干净。还有残留就查 EM 相关服务和任何连过库的客户端。确认进程全部消失之后再执行 apply。5.3 在补丁根目录直接执行opatch apply现象命令报找不到inventory.xml、etc目录不存在或者直接提示当前目录不是合法补丁目录。原因opatch apply需要以补丁目录为目标把D:\patch这种放了一堆补丁的父目录当成目标它当然找不到元数据。另一种情况是解压多套了一层cd进去的层级不对。解决cd到同时包含etc、files和 README 的那一层再执行。判断方法很直接dir看一眼有没有这几个子目录。实在拿不准就用带路径的写法opatch apply D:\patch\p1234567让 OPatch 自己去定位。5.4 只跑了opatch apply没执行补丁里的 SQL 脚本现象lsinventory里能看到补丁记录但数据库组件版本号没变或者某些功能仍然报旧版本的错。原因这类补丁通常分两部分二进制文件由 OPatch 替换数据字典部分要靠执行 SQL 脚本完成。README 的 Post-Installation 一节里会写清楚要不要执行、执行哪个脚本常见的是catbundle.sql、catcpu.sql这一类。跳过这步等于只换了一半。解决每个补丁 apply 成功后回去翻 README确认有没有 post-install 脚本。有的话用sqlplus / as sysdba连上去执行执行时留意输出里的ERROR和ORA-字样跑完再看一次组件状态。5.5 打完补丁把 OPatch 备份和原始压缩包清掉现象一两周后业务反馈某个功能异常需要回退到打补丁前的状态翻遍磁盘找不到原始补丁包。原因补丁打完觉得目录占地方顺手删了OPatch 备份目录也被当成垃圾清掉。回滚需要补丁包本体重新拿回来的版本和当初打的未必一致。解决原始压缩包、解压目录、OPatch_bak_*备份目录全部保留至少留到下一次完整备份周期结束。解压出来的补丁目录可以清理压缩包和 OPatch 备份不要动。这条是纯粹的教训没什么技术含量但栽进去的人不少。6. 验证不止 lsinventory把补丁号落到 SQL 查询和回归清单上opatch lsinventory能证明 OPatch 认为补丁装上了但证明不了数据库本身认不认这个补丁。这两件事不是一回事差距就在数据字典那部分。验证要分两层做一层看工具一层看库。6.1 从数据字典反查补丁记录连上库用 sys 权限查打补丁的历史记录这个视图记录的是数据库层面真正执行过的升级和补丁动作。-- 打补丁和升级动作都会记在这里按时间排序看最近发生了什么 select action_time, action, namespace, version, id, comments from registry$history order by action_time; -- 组件版本用来确认 RDBMS 组件的版本号有没有随补丁变化 select comp_name, version, status from dba_registry order by comp_name; -- 实例的基础版本信息作为对照 select * from v$version;第一段查询的输出里最近的时间点应该对应你这次打补丁的时间action一列会体现动作类型。如果registry$history里压根没有新记录而lsinventory显示补丁已装那基本可以判断 SQL 脚本那部分被跳过了回到 5.4 节处理。第二段查组件版本。打完补丁后 RDBMS 组件的 version 可能不变但 status 必须是 VALID。任何组件出现 INVALID 或 NONEXISTENT都要单独处理不要急着交付。把这三段查询的输出和 4.1 节保存的 inventory 文件一起归档到变更记录里下次有人问「这个库到底打了哪些补丁」答案是现成的。6.2 一份能落地的回归清单别指望「库能起来、能连上」就等于没问题。补丁影响的是内核和组件业务侧的异常往往几天后才暴露。窗口内时间有限我一般按下面这个顺序快速过一遍二十分钟能跑完。检查项做法判定标准实例与监听v$instance状态、lsnrctl statusOPEN监听 READY告警日志查看打补丁之后的 alert log无新增ORA-00600、ORA-07445组件状态dba_registry查询全部 VALID无效对象统计 schema 下的 INVALID 对象数和打补丁前持平业务冒烟挑三个核心 SQL 跑执行计划计划未发生非预期变化告警日志那条尤其值得花两分钟看。补丁打完启动实例时如果出现过内部错误alert log 里会有记录而实例可能照样起来、业务照样能连问题被静默地藏在那里等到高峰期才爆出来。我习惯是启动完成后立刻tail一遍最近两百行扫一眼有没有不认识的错误码。无效对象统计这条也实用。有些补丁会牵动系统包重编译之后如果依赖链上有问题业务对象会变成 INVALID。数量与打补丁前一眼对不上就先重编译一遍再查。用这套流程走下来还有一点个人习惯想强调后来我每次打补丁都强制先做一次lsinventory -detail存基线、再跑一遍prereq把冲突和占用提前暴露出来这两步加起来不到五分钟却把我从两次「打到一半发现前置补丁没打」的坑里捞了出来。补丁这件事后悔药永远比预防针贵。希望帮到你。本文还有配套的精品资源点击获取