简介针对Oracle 11g R2 11.2.0.4在Windows x64平台使用的最新集成补丁包面向仍在使用11g数据库的DBA、运维及系统管理员用于解决安全漏洞修复、性能优化与补丁集中管理问题。11.2.0.4作为11g R2的重要补丁集包含大量安全更新和稳定性改进资源将这些内容打包为可离线应用的rar压缩包。压缩包共463个文件以jar、dll、properties、exe、pl、md等类型为主其中jar与dll为补丁运行核心exe与pl承担OPatch执行和扩展逻辑md/txt提供说明与验证指引整体约637.5MB。目前已有2266人学习下载。包内文件按OPatch工具的应用流程组织涵盖环境检查、补丁安装、结果查询与卸载等环节可直接用于生产库打补丁前的准备和后续核验配合说明文档可快速理解先决条件与注意事项降低误操作风险。该补丁包于2022年10月18日更新适用于64位Windows环境尤其适合无法立即升级到12c或19c的存量系统是保持数据库安全、稳定运行的重要参考。1. oracle11.2.0.4 补丁包 2022.10.18 Win64Windows 老库的末班补丁车如果你的服务器上还跑着 Oracle 11.2.0.4 的 Windows 64 位实例看到oracle11.2.0.4 补丁包 2022.10.18 Win64这个标题第一反应不该是又来一个补丁而是这很可能是你在官方常规支持通道里能拿到的最后一批季度补丁之一。11.2.0.4 是 11g R2 的终版小版本自 2013 年发布后一直靠季度补丁维持2022 年 Extended Support 走到尾声10 月 18 日这个日期对应的基本就是最后一个完整季度更新窗口。对 Windows Server 上的生产库来说这个补丁包解决的不只是某个 ORA- 报错而是安全扫描、等保基线、审计整改里反复出现的Oracle 高危漏洞条目——很多单位就是被这份清单逼着动手的。这篇文章按我实际打补丁的流程来写下载之后怎么核对、打之前怎么准备、执行窗口怎么开、打完怎么验收以及 Windows 平台特有的几个坑。适合手里有 Windows 64 位 11.2.0.4 生产库、正在犹豫要不要上这趟末班车的 DBA。先给结论值得打但要认清这是止血不是根治。2. 先花 10 分钟核对补丁包目录结构、OPatch 版本、基线清单很多人拿到补丁包就直接解压执行这是翻车的高发起点。Windows 上的 11.2.0.4 补丁包和 Linux 版本结构不完全一样它通常是一个几百 MB 的 zip解压后是一个主目录加一串子目录。在动手前先把这个包的结构、README 要求、当前环境的 OPatch 版本核对清楚。这三件事确认完后续流程基本不会出方向性错误。2.1 补丁包主目录里有什么README、PatchSearch.xml 与子补丁目录把 zip 解压到本地工作目录我习惯放在盘符根目录下的英文路径里比如D:\oracle_patch不要放进带空格和中文的路径否则 opatch 在 Windows 上解析路径时会出一些很玄学的错误。解压命令用 PowerShell 最省事Expand-Archive -Path D:\download\pXXXXX.zip -DestinationPath D:\oracle_patch Get-ChildItem D:\oracle_patch解压完成后主目录下一般能看到的几类东西一个 README.html 或 README.txt一个 PatchSearch.xml若干子目录。README 是唯一权威的安装步骤说明先打开它找到 Installation Steps 和 Prerequisites 两个段落确认这个包是复合补丁composite patch还是多补丁集合。PatchSearch.xml 里记录了本包包含的补丁 ID、对应平台和相互依赖关系不需要去解析它但要明白它的作用opatch 在执行时靠它判断哪些子补丁需要按什么顺序装。子目录的数量决定了你后面用 apply 还是 napply——一个子目录就 apply多个子目录就考虑 napply这个判断标准在 README 里也会写明。2.2 先验证 opatch.bat 版本低于最低要求就停手打补丁这个动作本身是由 OPatch 工具驱动的补丁包对 OPatch 版本有最低要求而且 2022 年的补丁要求通常比很多老环境里装的 OPatch 高出不少。Windows 上 OPatch 不在 PATH 里要用全路径调用。先看当前版本cd /d %ORACLE_HOME%\OPatch opatch.bat version正常情况下输出里会显示类似OPatch Version: 11.2.0.3.xx的信息。接着去 README 的前置条件段落找 Minimum OPatch Version 这一项对比当前版本。如果低于要求别继续往下走直接把补丁包自带的 OPatch 压缩包解压出来覆盖到%ORACLE_HOME%\OPatch。很多补丁包内会额外带一个 OPatch 更新包文件名通常是 p6880880 系列把它解压后替换旧 OPatch 即可。这里有个细节替换前先把旧 OPatch 整个目录改名备份而不是删除。我见过有人直接删了旧目录结果补丁装到一半出问题想回退连工具都没了只能重新从安装介质里翻。2.3 opatch lsinventory 输出怎么看基线状态与已装补丁在打补丁之前一定要记录当前环境的补丁基线。这既是自查手段也是出了问题回退时的对比依据。执行cd /d %ORACLE_HOME%\OPatch opatch.bat lsinventory -detail输出会分两大部分前半部分是 OPatch 和系统信息后半部分是已安装补丁列表。重点看两点一是 Installed Top-level Products 里 Oracle Database 11g 的状态二是列表里已经有哪个补丁——如果之前打过某个 PSU这次再打同一个或更高版本的季度补丁opatch 会检测到冲突如果列表里出现过一次失败的补丁残留opatch 可能会拒绝继续安装。同时进数据库确认当前版本SELECT * FROM v$version; SELECT comp_id, comp_name, version, status FROM sys.dba_registry ORDER BY comp_id;把 opatch lsinventory 的输出和这两条 SQL 的结果截个图存档。这不是走过场补丁打完之后你需要拿这份基线来对照哪些组件版本变了、哪些没变。没有基线的补丁验收就是在猜。3. 打补丁前的三项准备备份、停服务、预检查补丁执行本身只有几十分钟但准备工作的质量决定出问题时你能不能全身而退。11.2.0.4 在 Windows 上的补丁本质上是替换 ORACLE_HOME 下的核心二进制文件再执行 SQL 脚本升级数据字典。这两个动作任何一个中断都可能让实例启不来。所以备份、停服务、预检查这三件事必须按顺序做透。3.1 数据库全备与 ORACLE_HOME 快照最后一道后悔药先把数据库做一次全备这是底线。Windows 上有图形界面但我更习惯命令行 RMAN因为可以记录输出、方便在排错时回看rman target / backup database format D:\rman_backup\db_%U.bak include current controlfile; backup spfile format D:\rman_backup\spfile_%U.ora;参数说明include current controlfile会在备份数据文件的同时把当前控制文件也备份进去避免单独备份控制文件时遗漏format里的%U是 RMAN 自动生成的唯一文件名保证备份集不重名Windows 路径盘符要写清楚。RMAN 备份是数据库层面的后悔药程序文件层面的后悔药还要靠自己动手把整个%ORACLE_HOME%目录复制一份特别是database子目录里的 spfile 和口令文件以及network\admin里的监听和 tnsnames 配置。命令上直接xcopy D:\app\oracle\product\11.2.0\dbhome_1 D:\oracle_home_bak\ /E /H /C /I就行。文件复制这步很多人嫌占磁盘不做但补丁一旦把某个 DLL 替换坏你重新安装整个软件要花半天而复制目录只要十几分钟。3.2 Windows 服务停干净等 oracle.exe 全部退出再动手Linux 上打补丁前用shutdown immediate停实例Windows 上同理但 Windows 比 Linux 多一层麻烦数据库和监听是以 Windows 服务的形式存在的服务没停掉oracle.exe 进程还在内存里补丁程序去替换二进制文件时会被系统拒绝。正常流程是先停监听再停数据库服务net stop OracleOraDb11g_home1TNSListener net stop OracleServiceORCL tasklist | findstr /i oracle第一行停监听器第二行停数据库实例对应的 Windows 服务第三行检查是否还有 oracle.exe 进程残留在内存里。这里有一个 Windows 平台特有的坑如果你的环境里装了多个 ORACLE_HOME或者某个监控 agent 通过 SQL*Net 保持着连接服务停了之后进程未必立刻退出。tasklist | findstr /i oracle的输出如果还有东西不要直接 taskkill先查是谁占着进程名是 oracle.exe 但父进程是某个 agent就让业务停掉那个 agent如果真是僵死进程再用taskkill /F /IM oracle.exe处理但这是最后手段强杀进程可能带来实例恢复的额外风险。3.3 补丁预检查空间、依赖、冲突扫一遍服务停好后执行补丁包的预检查。这一条命令能提前暴露大部分问题省得 opatch apply 跑一半才报错cd /d D:\oracle_patch %ORACLE_HOME%\OPatch\opatch.bat prereq CheckSystemSpace -phBaseDir D:\oracle_patch\pXXXXXprereq是 opatch 的预检查子命令CheckSystemSpace检查目标 ORACLE_HOME 所在磁盘空间是否满足补丁包解压和安装需要-phBaseDir指向补丁主目录。输出里如果出现CheckSystemSpace : Passed说明空间不是问题。另有一个隐含检查项是依赖冲突——如果当前环境已经装了更高版本的组件或者之前手动打过 one-off 补丁opatch 会在正式 apply 时报prerequisite check fails或existing patch conflict提前用opatch lsinventory核对过基线的话到这里就能判断出是谁冲突了。预检查通过后再最后确认一遍所有 Oracle 相关服务都是停止状态就可以进执行窗口了。4. 正式执行opatch apply 与 catbundle.sql 的前后顺序执行窗口分两段先做二进制层的 opatch 安装再做数据字典层的 SQL 脚本升级。缺一不可而且顺序不能反——只跑 SQL 脚本不装二进制实例起来后行为和原版本不一致只装二进制不跑 SQL 脚本数据字典里的版本信息还是旧版后续跑某些查询和功能会出现内部错误。这一段是整个补丁过程的核心按下面四步走。4.1 替换 OPatch 并收紧环境变量确认补丁包自带的 OPatch 版本高于 README 要求后把新 OPatch 顶上去。打开一个管理员权限的 cmd设置环境变量set ORACLE_HOMED:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SIDORCL rename %ORACLE_HOME%\OPatch OPatch_bak_20221018 move D:\oracle_patch\OPatch %ORACLE_HOME%\OPatch %ORACLE_HOME%\OPatch\opatch.bat versionORACLE_HOME必须指向你实际安装数据库的主目录如果系统里有多套环境这一步最容易出错——PATH 里如果还残留着别的 Oracle client 路径直接敲opatch会调用到别家的工具。ORACLE_SID这里只是规范习惯opatch 本身不依赖它但后续 SQL 脚本执行需要。先rename再move的顺序保证新 OPatch 替换失败时旧目录还在。最后再查一次版本确认新 opatch 能正常执行。这个动作完成后整个补丁阶段所有的 opatch 调用都用全路径%ORACLE_HOME%\OPatch\opatch.bat不要依赖 PATH。4.2 跑 opatch apply / napply确认最后的日志现在进入真正的补丁安装。执行前确认所有 Oracle 服务和进程都已停止用管理员 cmd 运行cd /d D:\oracle_patch %ORACLE_HOME%\OPatch\opatch.bat apply -phBaseDir D:\oracle_patch\pXXXXXapply用于单一补丁或复合补丁-phBaseDir指定补丁所在主目录。如果你的补丁包解压后是多个子补丁集合用 napply 更合适%ORACLE_HOME%\OPatch\opatch.bat napply -phBaseDir D:\oracle_patchnapply会把主目录下所有子补丁按依赖关系顺序安装避免手动逐个 apply 时遗漏依赖。执行过程中输出会持续滚动关键看最后几行出现OPatch succeeded才算成功出现OPatch failed就需要把日志翻出来看。日志文件在%ORACLE_HOME%\cfgtoollogs\opatch\目录下按时间戳生成具体文件名里包含补丁目录名。这时候不要慌着重试先看日志里第一个 ERROR 是文件权限、空间不足还是进程占用绝大多数失败日志里第一句真正原因在滚动输出里早就出现了只是被后面的堆栈盖住了。4.3 启动实例并执行数据字典升级脚本二进制替换完成启动数据库服务net start OracleServiceORCL net start OracleOraDb11g_home1TNSListener不是启动完就直接对外开服务而是先用 sqlplus 连进去把数据字典升级脚本跑完。用 sysdba 登录启动实例到 open 状态sqlplus / as sysdbaSQL startup; SQL ?/rdbms/admin/catbundle.sql psu apply;这段是 11.2.0.4 补丁执行中最关键的一步。catbundle.sql是 Oracle 提供的补丁数据字典升级脚本psu apply两个参数告诉脚本这是 PSU 类型补丁、执行应用动作?会被 SQL*Plus 自动展开为%ORACLE_HOME%。脚本执行时间取决于库的大小和对象的多少可能十几分钟到几十分钟执行期间不要开第二个会话去查数据字典也不要手动 kill 这个会话。输出里如果出现错误把错误停在屏幕上先看是执行错误还是脚本内部可控警告。正常情况下脚本结束后会打印一串组件验证结果每行状态是VALID。4.4 用 utlrp.sql 收尾并核对组件版本catbundle 脚本只是把数据字典版本升级到和补丁一致升级过程里会有一些对象因为依赖关系暂时 invalid。所以紧接着执行 utlrp.sql 做一次无效对象重编译SQL ?/rdbms/admin/utlrp.sql; SQL SELECT comp_name, version, status FROM sys.dba_registry ORDER BY comp_name;utlrp.sql是 Oracle 自带的无效对象重编译脚本用并行方式重新编译数据库里所有失效对象参数不需要额外指定执行完会输出 summary。第二步的查询用来确认组件状态看status列是否都是VALID再看version列是否变成了补丁对应的版本。如果这里出现某个组件还是旧版本或 INVALID后面自检阶段会进一步排查。到这里补丁安装的主体流程已经走完了但别急着宣布成功——接下来的验收和观察期才是真正判断这次补丁是否服帖的环节。5. Windows 上打 11.2.0.4 补丁的 5 个避坑记录这五条是 Windows 平台 11.2.0.4 补丁执行期最常见的踩坑现场每一条我都见过不止一次。记录方式按现象、原因、解决三步来写方便你对照排查。5.1 现象apply 报文件被占用日志里有 file in useopatch apply 跑到一半中止日志里出现类似cannot replace file oracle.exe, source file is in use或提示某个 DLL 被锁定。原因很直接有一个或多个 oracle.exe 进程还活着Windows 文件系统不允许替换被进程映射的二进制文件。常见来源是监听器服务没停干净、监控 agent 拉起了连接、或者之前用shutdown abort停库后进程没有完全退出。解决用tasklist | findstr /i oracle查出剩余进程逐个确认来源然后关闭对应服务如果是僵尸进程直接taskkill /F /IM oracle.exe。处理完再重新跑opatch apply。还有一个不起眼的原因杀毒软件实时防护把 opatch 替换 DLL 的动作当成可疑行为锁了文件导致明明没有 Oracle 进程也报占用这种情况要在补丁期间把 ORACLE_HOME 和补丁目录加入杀毒白名单。5.2 现象opatch 版本报错或提示找不到 Inventory执行 opatch 命令后报OPatch version X is lower than the minimum required或者Failed to get inventory、PRIF-1012。原因分两类一是当前 ORACLE_HOME 里的 OPatch 太旧README 要求的新版没装进去二是 cmd 窗口没有用管理员身份打开OPatch 读不到中央清单注册表项或 PATH 里串了别的 Oracle home 导致 opatch 指向错误。解决先确认%ORACLE_HOME%环境变量值正确用echo %ORACLE_HOME%查一遍不对就 set然后用补丁包自带的新 OPatch 替换最后确保以管理员身份重新打开 cmd。我通常在执行前先跑一次%ORACLE_HOME%\OPatch\opatch.bat version这个动作能同时验证路径和权限两件事。5.3 现象数据库服务启动后立刻挂掉补丁完成后net start OracleServiceORCL成功但十几秒后服务状态又变回停止alert log 里出现无法加载文件或内部错误。原因是新替换的 oracle.exe 和一堆 DLL 被安全软件隔离或拦截了Windows 上常见场景是服务器装了行为防护类软件对刚被替换的数据库主程序产生误报。解决第一步先看 alert log 和 Windows 事件查看器确认是不是文件加载失败第二步把%ORACLE_HOME%\bin目录加进安全软件排除名单然后重新启动服务。这个坑打 Linux 补丁遇不到属于 Windows 独有。另外注意有些服务器会同时装多套安全产品排除名单要每套都加。5.4 现象catbundle.sql 执行卡住或报 ORA-00054数据字典升级脚本跑着跑着不动了长时间不输出或者直接报ORA-00054: resource busy and acquire with NOWAIT specified。原因是执行期间还有别的会话持有对象锁最常见的是 DBA 自己的监控脚本、巡检 SQL 或者备份任务还连着数据库。解决在另一个会话查SELECT sid, serial#, username, blocking_session FROM v$session WHERE blocking_session IS NOT NULL;找到阻塞源头终止对应会话或者干脆在启动实例后先执行ALTER SYSTEM ENABLE RESTRICTED SESSION;再跑 catbundle升级完再恢复。强调一下catbundle 执行期间尽量不要并发做任何对象操作哪怕只是查 dba_tables 也可能影响脚本执行。5.5 现象回滚后数据库组件版本和二进制对不上补丁后发现业务异常想回滚执行opatch rollback -id pXXXXX成功二进制回到旧版本但数据库里的组件版本还是新版。原因11.2.0.4 的补丁回滚不像 12c 之后有 datapatch 统一管理 SQL 层它需要手动对应执行回滚脚本很多人只滚了二进制层就停了。解决严格按 README 里的 rollback 章节操作它一般会要求先opatch rollback再在数据库上执行对应的回滚 SQL 脚本如果 README 没提供回滚脚本那就只能靠补丁前的 RMAN 备份恢复数据文件。这也是我反复强调补丁前必须做全备和 home 目录快照的原因——在 11.2.0.4 这个年纪的版本上回滚 SQL 层不是每次都顺畅备份是最有把握的后悔药。6. 补丁完成后的三条自检命令与我的收尾习惯补丁打完了、业务也验证过了我还会做三件事这三件事能让你在补丁后一周内的任何异常里有底气判断是不是补丁惹的祸。第一件事查补丁历史记录SELECT TO_CHAR(action_time, YYYY-MM-DD HH24:MI) AS action_time, action, bundle_series, comments FROM sys.dba_registry_history ORDER BY action_time;正常会看到一行或多行APPLY记录时间和你打补丁的时间吻合bundle_series能看出是 PSU。第二件事查组件有效性SELECT comp_name, version, status FROM sys.dba_registry ORDER BY comp_name;这条和安装时最后一步是同一个查询只要 status 全是 VALID组件层就没有问题。第三件事查失效对象和 alert logSELECT owner, object_name, object_type FROM dba_objects WHERE status INVALID;同时打开%ORACLE_HOME%\diag\rdbms\SID\SID\trace\alert_SID.log搜一下ORA-00600和ORA-07445没有才是真干净。这里我给一个我自己的习惯补丁完成后不急着删备份RMAN 备份和 home 目录快照至少保留到补丁成功运行一周后。遇到过一次某库打完补丁第二天业务报一个和 AWR 报告相关的内部错误排查了三个小时定位到是补丁引入的行为变化因为没有备份最后只能靠 opatch 回滚加手动处理折腾了一整夜。自那之后我立了规矩凡是给 11.2.0.4 这种维护期尾声的版本打补丁备份保留时间翻倍并且补丁后第一个业务峰值时段我会盯着 alert log 和 AWR 的等待事件变化再离开。这个年纪的库补丁本身通常没问题问题都在它周围的环境。按这三条自检命令走一遍配合备份保留策略这次补丁基本就算落袋为安了。希望帮到你。本文还有配套的精品资源点击获取