简介Oracle 11.2.0.4补丁包2022年10月18日更新适用于Windows x64面向仍在运行Oracle 11g R2的数据库管理员与运维人员是保障数据库安全与性能的关键资源。作为11g R2最后的主要补丁集该版本集中了安全修复、性能优化和缺陷修复尤其适合尚未迁移到更高版本、需要维持系统稳定的生产环境。整个资源包共463个文件约637.5MB文件类型以jar、dll、properties、exe、pl、sh、bat为主其中有可执行程序、动态链接库、配置属性和自动化脚本能够支撑64位Windows平台上的完整补丁维护工作。压缩包内额外提供OPatch工具及其辅助脚本并附有md、txt等说明文档便于理解补丁验证和环境检查步骤管理员可使用apply命令完成补丁应用再用lsinventory核对安装结果配合事前备份与先在非生产环境测试等做法能显著降低升级风险。目前已有2257人学习下载适合需要掌握Oracle 11g补丁管理、系统安全加固及性能调优的数据库技术人员。1. 补丁包背后11.2.0.4 在 2022 年 10 月之后还能怎么补在 2025 年还能见到跑在 Windows 服务器上的 Oracle 11.2.0.4 生产库这并不稀奇真正稀奇的是很多这类库的补丁状态还停留在两三年前。Oracle 11.2.0.4 的补丁包到 2022 年 10 月 18 日仍然在出正式的 Win64 版本之后基本不再有统一的季度更新这意味着 2022.10.18 这个包是把老库补到官方最终状态的关键资源。它能解决的是库还迁不走但等保和安全扫描已经盯着漏洞不放适合的是一线 DBA以及运维手里还攥着一批 11g 老库的人。这篇文章照着拆包、预检、apply 和 datapatch 的顺序往下走最后把翻车点一个个列清楚。2. 拆包看货PSU、OJVM 与客户端补丁的三种身份2.1 先分清三类成分同是补丁后遗症差别很大从补丁下载平台拿到的这个包表面上看是一个压缩包但里面通常不是单一补丁。11.2.0.4 在 Windows 64 位平台上补丁包往往混着三类东西数据库 PSU/RU、OJVM 补丁、Windows x64 客户端补丁。我先说结论这三类补进 ORACLE_HOME 的机制不一样回滚能力也不一样搞混了会把环境补成半吊子。下面这张表是我每次拆包先提醒自己的对照清单| 成分 | 影响范围 | 安装方式 | 回滚边界 | | 数据库 PSU / RU | 数据库内核、监听、SQL*Plus 等工具 | opatch apply | 可以回滚但跨 datapatch 后有限制 | | OJVM 补丁 | Java 虚拟机、DBMS_JAVA、loadjava | 独立 opatch apply | 多数情况不能回滚 | | 客户端补丁 | 独立 client 的 ORACLE_HOME | 单独安装 | 视具体补丁版本而定 |怎么快速识别压缩包里补丁目录名一般是一个八位数字编号真正的编号以你拿到的压缩包和 README 为准。文件名通常长得像 p编号_112040_MSWIN-x86-64.zip 这种格式其中 112040 代表 11.2.0.4 平台基线MSWIN-x86-64 代表 Windows 64 位。解压之后别急着动先把每个子目录下的 README.html 或 README.txt 打开上面会写明这个补丁是给哪个 Home 的、最低 opatch 版本、前置补丁要求。这一步花五分钟能省后面三个小时。2.2 为什么说 2022 年 10 月这个包值得单独留一份Oracle 对 11.2.0.4 的延长支持在 2020 年前后已经进入尾声到 2022 年 10 月这一批基本是普通订阅用户能拿到的最后正式统一补丁。之后就算再出修复也是定制补丁通道不再走季度 CPU/PSU 的常规发布。对一线运维来说这件事的实际意义是第一这个时间点的补丁包适合作为老库的“最终基线”。以后排查故障先确认环境是否已经在这个基线之上能省掉一大类“是不是缺补丁导致”的怀疑。第二不要再指望后续季度更新覆盖 11g 的洞等保检查问补丁更新到什么时间这个包就是对不齐的答案。第三我给自己立了个习惯凡是还在跑的 11.2.0.4统一以这个最终批次之后的版本为基线之后不追新稳定优先。2.3 校验完整性先别急着双击解压砸过一次哈希不完整导致 apply 到一半报文件校验失败的锅之后我每次拿到补丁包都先做一件事验证哈希。Windows 上不用装额外工具系统自带 certutil 就能办到。# 列出压缩包内容确认目录结构与预期一致 7z l Oracle_112040_PSU_2022.10.18_Win64.zip # 计算 SHA256和 Oracle 官方页面给出的值逐位核对 certutil -hashfile Oracle_112040_PSU_2022.10.18_Win64.zip SHA256逻辑说明7z 列包是为了在解压前看清里面有几个补丁目录防止下载到的是残缺包certutil 校验哈希则用来确认文件没有被网络传输过程中的异常损坏。官方下载页面通常同时给出 MD5、SHA1、SHA256我习惯对 SHA256碰撞概率低到可以忽略。参数说明certutil 的-hashfile第一个参数是要校验的文件路径第二个参数是算法名大小写都行。如果服务器是 Windows Server 2008 R2 或 2012certutil 同样可用实在找不到就退回 7-Zip 自带的文件哈希功能效果一样。校验通过后我习惯把解压目录放到C:\oracle_patch坚决不解压到 ORACLE_HOME 内部免得后续目录遍历时把补丁目录里的旧文件扫进去。3. 补丁前的三条硬规矩opatch 版本、服务停干净与备份清单3.1 opatch 版本太低后面全部白搭opatch 负责把补丁元数据写进 ORACLE_HOME 的 inventory版本低了不识别新补丁的格式轻则报警告重则直接拒绝 apply。补丁包 README 里通常会写明最低 opatch 版本要求但很多人跳过 README 直接执行结果就是 opatch 在解析补丁描述文件时报错。先检查当前版本# 在 ORACLE_HOME 环境变量就绪后查看当前 opatch 版本 opatch version正常输出类似OPatch Version: 11.2.0.3.x。如果版本低于补丁要求需要先下载匹配的 opatch 包解压后覆盖%ORACLE_HOME%\OPatch目录。覆盖之前把原 OPatch 目录改名备份例如改成OPatch_bak_$(date)这样万一新 opatch 与当前环境不兼容还能倒回去。常见报错是 opatch 提示PRIF-0000无法读取 inventory看到这类信息先别急着怀疑补丁包八成是 opatch 版本与 inventory 结构不匹配。3.2 环境对标把服务停干净再谈打补丁opatch apply 要求没有进程占用 ORACLE_HOME 下的文件Windows 上最彻底的准备方式不是 shutdown immediate而是直接把服务停掉。生产库如果允许停机窗口我一般走完 shutdown immediate 之后再用 sc 停服务双保险# 查看Oracle实例服务和监听服务的当前状态 sc query OracleServiceORCL sc query OracleOraDb11g_home1TNSListenersc query的关键是看 STATE 一列RUNNING 就说明服务还活着。把这两个服务停掉后别马上开始 apply先去任务管理器确认没有 oracle.exe、tnslsnr.exe 残留。这类残留进程是 Windows 平台补丁失败的主因之一文件被占用会导致 opatch 在复制阶段报错。如果进程杀不掉用taskkill /F /IM oracle.exe /IM tnslsnr.exe强制结束后再看一遍。3.3 备份清单这张表上的东西不能省打补丁通常不动数据文件但补丁过程中如果出现意外中断实例重启时可能触发实例恢复所以备份习惯不能省。我给自己定的最低备份清单如下| 备份对象 | 路径示例 | 备份方式与目的 | | spfile |%ORACLE_HOME%\database\SPFILEORCL.ORA| 复制一份防止回滚后参数不兼容 | | 密码文件 |%ORACLE_HOME%\database\PWDORCL.ORA| 复制一份防止文件被覆盖 | | 网络配置 |%ORACLE_HOME%\network\admin下 tnsnames.ora、listener.ora | 出问题可快速还原监听配置 | | 数据文件 | 数据文件完整路径 | RMAN 全备或冷备归档模式下最低也做一次全备 |有没有例外如果环境很小、本来就没有开归档冷备是唯一靠谱的选择关库后用操作系统复制把所有数据文件、控制文件、redo log 复制出去然后再打补丁。备份结束后顺手查一下注册表里的 ORACLE_HOME 路径Windows 上如果当初装到了带空格的路径比如C:\Program Files\...或者中文目录opatch 在路径解析时很容易翻车。遇到这种环境我的建议是先骂一遍当初装机的人然后把补丁包放到短路径下执行否则后面排查补丁路径问题的成本会非常高。4. 手工apply完整路径从 opatch prereq 到 datapatch 收尾4.1 目录归类和 README 对照执行前先分好兵把压缩包解压出来后第一件事是把补丁目录按身份分开数据库 PSU/RU 归一组OJVM 归一组客户端补丁归一组。同一套补丁包里DB 和 OJVM 通常目录编号不同README 里也会标明安装顺序。常见做法是先装数据库 PSU再装 OJVM如果 README 写了特殊顺序以补丁包自带说明为准不要拿其他环境的经验硬套。顺带提一个容易忽略的点有些下载名称为 PSU 的包其实已经包含了前置补丁是 bundle 格式不再需要自己凑前置条件有些则严格要求先装一个旧补丁再装新补丁。判断依据就是 README 里“Pre-requisite”一节。这一节没看清楚就开跑往往是 opatch 在预检阶段报“missing prerequisite patch”停住。4.2 设置环境变量并跑预检查Windows 下最容易出问题的是环境变量不干净。我每次开一个新的 cmd 窗口都把这些变量重新敲一遍不依赖系统全局配置set ORACLE_HOMEC:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SIDORCL set PATH%ORACLE_HOME%\OPatch;%PATH% cd /d C:\oracle_patch\补丁目录 opatch prereq CheckSystemSpace -ph .这段命令的逻辑前三行把 Oracle 环境变量收紧到当前会话避免和其他版本的 Oracle 客户端冲突cd进入补丁目录opatch prereq CheckSystemSpace -ph .中的-ph表示补丁目录路径.表示当前目录作用是检查磁盘空间、依赖组件和补丁冲突。我在多套 Oracle 共存的环境上吃过PATH混乱的亏——PATH里既有 12c 的 bin 又有 11g 的 binopatch 执行时调用的 sqlplus 版本不对直接报“SQL*Plus could not be loaded”。从那以后凡是手工操作 Oracle 补丁一律不开全局环境只用当前窗口设置。4.3 正式 apply交互式执行比静默更可控预检通过后进入正式安装阶段cd /d C:\oracle_patch\补丁目录 opatch applyapply 过程中 opatch 会读取补丁描述文件逐步替换二进制文件最后把补丁信息写入 inventory。耗时取决于补丁大小和机器性能通常几分钟到半小时不等。我在第一次给生产库打补丁时试过opatch apply -silent结果中途某个环节失败日志信息被吞掉一大半反而更难排查。现在一律用交互模式虽然多按一次回车但每一步的输出都看得到。期间如果卡住先别急着判断死机。opatch 的日志落在%ORACLE_HOME%\cfgtoollogs\opatch\目录下文件名格式是opatch2022-xx-xx_xx-xx-xx.log。打开日志看最后几行如果停在文件复制阶段多半是被杀毒软件扫描拖慢如果停在Invoking SQL*Plus这行说明数据库没有完全关闭。Windows 上保险做法是再敲一遍sc query OracleServiceORCL确认服务是 STOPPED然后再重跑。4.4 datapatch 收尾忽略这步等于白打opatch apply 只完成了二进制层面的更新数据库内部的 SQL Patch 通常不会自动注册。启动数据库后用 datapatch 把补丁中的 SQL 脚本应用进去set ORACLE_HOMEC:\app\oracle\product\11.2.0\dbhome_1 set ORACLE_SIDORCL cd /d %ORACLE_HOME%\OPatch datapatch -verbose用-verbose是为了看到每一步 SQL 应用细节文档里参数释义是输出详细日志。不带它也能执行但排错时缺少上下文所以我一直带着。datapatch 执行完毕后才能查到 dba_registry_sqlpatch 视图里的补丁记录。select patch_id, patch_uid, status, description from dba_registry_sqlpatch order by patch_id;这条查询用于确认 SQL patch 的注册状态status字段为APPLY_APPLIED才算成功。patch_id对应补丁编号patch_uid是补丁在数据库内的唯一标识。这一步经常被跳过一个坑opatch 显示成功但应用层还是连不上或用不了新特性查了半天才发现 SQL patch 没落地。以后凡是我经手的补丁opatch 成功和 datapatch 成功这两条缺一不可。4.5 监听与客户端补丁同一个包里的另一个战场如果机器上还装有独立的 Oracle Client 11.2.0.4补丁包里针对 client 的部分要单独安装。很多 DBA 只给服务端打了补丁应用服务器上的 client 还是旧版结果连库时报ORA-28040: No matching authentication protocol这大概是我见过最多的补丁后遗症之一。处理方式解压客户端补丁目录在 client 的 ORACLE_HOME 下同样执行 opatch 流程环境变量换成 client 的路径别和服务端混用同一个 HOME。业务侧如果用的还是 ojdbc6.jar 这类 11g 时代驱动系统继续跑 11.2.0.4 没大毛病但打完补丁后最好用一次真实连接测试确认 JDBC 驱动与数据库补丁后的协议版本兼容。5. 避坑排查五个翻车现场的记录5.1 OJVM 补丁装完发现不能回滚现象打 OJVM 补丁前没备份后来库出现异常想 opatch rollback结果列补丁清单里根本看不到 OJVM或者直接提示该补丁不支持回滚。 原因OJVM 属于 Java 虚拟机层面的维护补丁Oracle 为 11.2.0.4 之后的 OJVM 补丁设计了不可回滚的安装方式inventory 里就没有登记可回滚信息。 解决装 OJVM 之前先把 ORACLE_HOME 下javavm目录和lib目录做文件级备份。真出问题最快的办法是从备份整体还原 ORACLE_HOME不要指望 opatch 单独把 OJVM 摘出去。我现在的习惯是凡生产库要动 OJVM先做一次虚拟机快照或整个 Home 目录的文件级复制再进补丁流程。5.2 Windows 上照抄 Linux 的 opatch auto 命令现象网上教程写着用opatch auto -apply打补丁拿到 Windows 环境一跑提示找不到 clusterware或者 opatch 工作目录根本没有 auto 子目录。 原因opatch auto面向 RAC/集群环境设计单实例单节点的 Windows 安装包不包含对应的自动化调用目录自然无法识别。 解决Windows 单机直接用手工opatch apply流程。如果是 RAC for Windows那就先启动 CRS 服务按节点逐个执行别把 Linux 的自动化命令照抄过来。这类问题的本质是平台边界没看清我一般会在操作单上先核对“环境是单实例还是 RAC”再决定走哪条安装路径。5.3 datapatch 卡住不动日志停在一条 SQL 上现象datapatch -verbose 跑很久日志停在某一条 insert/update 上最后报 ORA-04021 或 ORA-04031。 原因字典缓存被大量无效对象占住或者 shared pool 内存不足再或者是上一次补丁中断留下了未完成的残留状态SQL 脚本重放时死锁。 解决先查无效对象再决定是否清共享池。-- 查看无效对象规模数量巨大时先处理它们 select owner, object_name, object_type, status from all_objects where status VALID;有大量无效对象先确定是不是补丁前就存在的补丁前就有的就声明在前补丁新产生的才需要处理。再不行就alter system flush shared_pool;后重跑 datapatch。这条命令在 11g 生产库上会影响所有会话的 SQL 解析性能必须放到业务低峰执行。我最开始不懂这个白天施工时 flush 了一下回话马上变慢被业务方追着问了俩小时。5.4 监听服务起不来卡在 TNS-12541现象补丁打完后 lsnrctl start 起不来报 TNS-12541、TNS-01196或监听一直停在 starting 状态。 原因监听端口被其他进程占用listener.ora 里的路径还指向旧的 Home或者监听服务对应的可执行文件路径在补丁后变了。 解决按顺序排查。第一lsnrctl status看监听日志第二netstat -ano | findstr 1521看端口占用占用方不是 oracle 就杀进程第三确认 listener.ora 里LISTENER节点的目录确实指向当前 Home。监听这类问题有时候很玄学但九成逃不出这三个方向按顺序走一遍能收敛。5.5 打补丁后应用连不上账号密码过期现象补丁装完应用连库报 ORA-28002 或 ORA-28001销售开始怀疑补丁出了问题。 原因补丁本身不会主动改密码策略但环境在补丁前已经配置了默认口令生命期停机窗口恰好跨过了密码过期时间点库一启动就弹出密码过期提示。 解决用 sys 登录把业务账号对应的 profile 口令策略放开alter profile default limit password_life_time unlimited password_lock_time unlimited;什么时候该骂补丁、什么时候该查配置文件这里是个典型例子。补丁只是压死骆驼的最后一根稻草真正的雷是之前就埋下的。6. 打完之后验证习惯与回滚的边界6.1 一张验证清单替换“看着像没事”补丁打完之后我按固定顺序做四件事。第一步opatch lsinventory -detail输出里有目标补丁号状态是 APPLIED。第二步用 6 里的 SQL 查 dba_registry_sqlpatch确认 SQL patch 状态是 APPLY_APPLIED。第三步用 dbeaver 或 PL/SQL Developer 做一次业务账号的真实查询不是查 sys 表而是走业务侧的同一条 SQL 路径。第四步打开 11g 的 alert 日志从补丁后启动时间点扫到当前确认没有 ORA-600、ORA-7445 之类内部错误。这套流程走完我才会在维护记录上签字。6.2 后悔药能吃多少回滚边界这个问题我的教训很直接数据库补丁的 rollback 不是万能的。PSU/RU 部分可以用opatch rollback -id 补丁号滚回但前提是数据库没有跨过 datapatch 之后的长时间运行如果已经跑了一天生产数据在补丁后的代码路径下发生了写入rollback 之后再跑datapatch -rollback也未必能完全恢复原来状态。OJVM 就更不用指望基本只能前滚修复或还原 Home。所以真正可执行的后悔药是备份不是 rollback 命令。打补丁前把 RMAN 备份或冷备做完发现问题直接还原比在 rollback 边界上抠半天靠谱。从那以后我给每一台正式环境的 11.2.0.4 都保留一份补丁包、一份打完后的 opatch 输出和 datapatch 日志按库名归档。再遇到环境疑神疑鬼先对这三样问题立刻收敛一半。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取
