简介面向Windows平台Oracle 12c数据库运维场景的Opatch补丁升级工具包适合需要为数据库实施补丁安装、回滚或版本检查的DBA及运维人员。压缩包共454个文件约102.88MB涵盖132个jar运行库、111个dll动态链接库、41个md说明文档、21个exe可执行程序以及大量pl、sh、bat等自动化脚本和properties配置文件可支撑不同环节的补丁操作。内容预览显示包含opatch.bat、datapatch.bat、operr.bat等关键入口以及cacerts证书、blacklist过滤、fontconfig字体配置等辅助组件结构完整。已有992人学习/下载适用于Windows环境下Oracle 12c补丁维护的快速参考与离线使用。 给 Oracle 12c12.1.0.2打补丁在 Linux 上已经够繁琐了但真正让人血压飙升的是在 window 环境里用 Opatch 给 oracle12c 打补丁。我最近刚处理完一台 Windows Server 2012 R2 上的 12.1.0.2 数据库补丁更新整个流程从环境准备、OPatch 升级到正式 apply、datapatch一天下来踩了七八个雷有几个问题在 Linux 平台闻所未闻在 Windows 上却几乎是必现的。这篇文章把整套流程按执行顺序拆开讲重点说清楚每一步为什么要这么做、哪些检查不能省、哪些报错可以忽略适合正在或者准备在 Windows 上为 Oracle 12c 打补丁的 DBA 和运维同学参考。我会把命令、日志、排错思路都摆出来尽量做到你看完就能直接拿去用。1. 为什么 Windows 上的 12c 补丁流程比 Linux 更麻烦1.1 补丁包里不只有 OPatch还有一堆前置条件很多人以为打补丁就是下载、解压、执行 opatch apply 三步其实不等于。Oracle 12c 的补丁从结构上就比老版本复杂一个季度补丁包里通常包含二进制部分替换数据库的 exe、dll 文件和 SQL 部分需要连到数据库执行的脚本。二进制部分用 OPatch 工具应用SQL 部分在数据库启动后交给 datapatch 完成。OPatch 本身又是 Java 程序这意味着 Windows 服务器上必须有一个可用的 JDK/JRE。此外Windows 上还有 SHA-2 代码签名的问题Oracle 从某个时间点之后发布的补丁程序都是 SHA-2 签名的如果你的系统还停留在 Windows Server 2008 R2 或 Windows 7 这种老版本并且没有安装微软的 SHA-2 支持补丁典型的就是 kb2999226那么 OPatch 可能连启动都会失败或者解压出来的 DLL 在加载时被杀毒软件拦截。所以在开始之前先把环境这个坑填平比研究补丁本身更重要。我在 Windows 上见过太多opatch 命令都跑不起来的情况最后查出来都是环境问题而不是补丁包的问题。1.2 什么时候该打补丁什么时候该观望补丁不是越新越好也不是越多越好要分场景。正常情况下数据库遇到了一个明确影响业务的 Bug且 MOS 文档里的修复补丁正好覆盖你当前的版本这时候打再就是每个季度 Oracle 发布的 Proactive Bundle Patch会带安全修复出于合规和安全性也建议打。但如果你正处于季度峰值业务期、数据库和第三方监控/备份软件深度绑定那我劝你宁可晚一个窗口也不要裸奔操作。补丁本身不危险危险的是打一半发现无法回滚的处境。尤其是 Windows 平台上Oracle 服务和文件锁之间的纠缠比 Linux 复杂得多——Linux 上删掉一个被占用的文件往往还能继续Windows 上文件被进程锁住就是真锁住了服务不停干净补丁百分之百失败。另外有一个基线意识同一套机房里的多套 Oracle 数据库补丁版本尽量保持一致。否则以后做 Data Guard、迁移、比对时一套 19.3、一套 19.11光是 dba_registry_sqlpatch 的对比就够你折腾半天的。2. 动手前的环境检查这三项缺一不可2.1 OPatch 工具版本先查版本再决定要不要升级执行补丁前第一件事是在数据库服务器上查出当前的 OPatch 版本。Windows 上打开 cmd进入 ORACLE_HOME 的 OPatch 目录然后跑cd /d %ORACLE_HOME%\OPatch opatch version输出类似OPatch Version: 11.2.0.3.36。这里有个容易忽略的点不同的补丁对 OPatch 最低版本要求不一样补丁包自带的 README 里会明确写。比如有些 12.1.0.2 的补丁要求 OPatch 版本不低于 11.2.0.3.35。如果版本不够直接 apply 会在前置检查阶段被拦下来报类似 OPatch version is older than required 的错误。升级 OPatch 本身不复杂。到 MOS 上下载对应 Windows 64 位的p6880880版本比如p6880880_112000_MSWIN-x86-64.zip解压后把 ORACLE_HOME 下的 OPatch 目录改名备份再用解压出来的 OPatch 目录替换原目录。注意备份这一步别省Windows 上 OPatch 目录里存放着补丁应用相关的元数据备份了才有后悔药。升级完成后重新执行opatch version确认新版本生效。同时养成一个好习惯升级前先执行一次opatch lsinventory把当前数据库已经安装的所有补丁列表导出留底这个快照在后续冲突排查时非常有用。2.2 JDK 与 PATHOPatch 能不能跑起来的地基前面说了 OPatch 是 Java 写的所以服务器上的 Java 环境直接决定工具能不能跑。安装 JDK 时建议选 64 位 JDK 1.8版本不用追求最新稳定即可。安装后重点检查环境变量的配置set JAVA_HOME java -version如果java -version在 cmd 里能输出版本说明基础没问题。但环境变量有时会有坑服务器上可能装了多个 Java尤其是跑着其他中间件的时候PATH 里靠前的那个 Java 未必是 64 位的。OPatch 对 JVM 位数很敏感32 位 JVM 跑在 64 位 Windows 上轻则告警重则直接 OOM 或者崩溃。解决方式很简单在运行 opatch apply 的同一个 cmd 窗口里重新指定环境变量不要依赖全局配置set JAVA_HOMEC:\Java\jdk1.8.0_211 set PATH%JAVA_HOME%\bin;%PATH% opatch version这样可以在不改动全局环境的前提下确保 OPatch 调用到正确的 Java。另外一点如果服务器上 JDK 路径带空格比如C:\Program Files\Java\jdk1.8.0_211现代 OPatch 版本通常能处理但老版本会有问题。遇到这种情况最保守的做法是把 JDK 装到类似C:\Java\这种短路径下省去后续功夫。2.3 SHA-2 签名补丁与账户权限老系统的隐性强需求这一条专门提醒那些还在 Windows Server 2008 R2、Windows 7 SP1 上跑 Oracle 12c 的同学。补丁包里的大量文件是 SHA-2 签名证书没有系统级支持的话安装过程会出现签名验证失败或者程序无法启动的诡异现象。微软官方提供的 kb2999226 和配套的 kb2921916 就是为了解决 SHA-2 代码签名支持而发布的。检查方法很直接在控制面板-程序和功能-查看已安装的更新里搜索 KB2999226。如果没装先找运维同事确认这台 Windows 是否还能正常打微软补丁补上系统补丁后再继续 Oracle 打补丁的操作。顺序千万别反了——先 Oracle 后系统补丁很容易造成 Oracle 相关程序签名状态异常。账户权限方面运行 OPatch 的账户需要对 ORACLE_HOME 目录具备完全控制权限同时也需要能访问 oraInventory 目录。最省事的方法是右键 cmd以管理员身份运行再执行 OPatch 操作。千万别用普通管理员账户硬扛Windows 的 UAC 会在你意想不到的时候把文件重定向到虚拟存储路径日志和实际文件对不上排查起来极其痛苦。我还建议在打补丁期间临时关闭杀毒软件实时防护或者至少把 ORACLE_HOME 目录加入白名单。之前我就遇到过一次补丁包解压出来好好的apply 过程中某个 DLL 被实时防护隔离了日志里报 file not found找了很久才发现文件被吃了。这种坑不属于 Oracle却比 Oracle 的报错更让人崩溃。3. 补丁下载、解压、冲突检查的完整流程3.1 补丁号与解压路径一个 260 字符硬限就能卡死你找到正确的补丁号这一步建议以 MOS 文档为准。对 12.1.0.2 来说常见的是季度性 Database Proactive Bundle Patch比如我这次使用的补丁号是 37537949实际环境以 MOS 搜索结果为准。下载补丁时注意选择Microsoft Windows x64 (64-bit)平台版本不要下成 Linux 版这个错误在下载界面上很容易看走眼。Windows 有一个历史遗留问题就是 MAX_PATH——文件路径超过 260 字符会直接导致创建文件失败。Oracle 补丁包解压后的目录结构嵌套很深如果你把压缩包解压到C:\Users\Administrator\Downloads\oracle_patch\37537949\...这种长路径下大概率在解压过程中就报文件路径太长甚至解压完了某些文件缺失但系统不提示。我建议的规范路径格式是C:\temp\37537949压缩包也放到这个短路径下再解压。如果路径中还有中文目录名那问题更多OPatch 和 Java 的默认编码可能让日志里的中文路径显示成乱码对排查毫无帮助。所以我定了一条规矩所有补丁介质统一放C:\temp\patch\补丁号和正式环境路径严格区分。3.2 冲突检测命令与结果解读很多新手跳过了 OPatch 的 prereq 检查直接 apply结果中途失败。实际上冲突检测非常快却能把问题提前暴露出来。打开管理员 cmd进入 OPatch 目录执行cd /d %ORACLE_HOME%\OPatch opatch prereq CheckConflictAgainstOHWithDetail -ph C:\temp\37537949这条命令会检查补丁与当前数据库已安装补丁之间的冲突。正常情况输出类似 No pre-requisite conflicts found说明可以继续。如果检测到冲突输出会列出具体冲突的补丁号这时候不要强行 apply。正确处理方式是先去 MOS 查一下冲突补丁是否有合并版本或者考虑先回滚某些不必要的旧补丁。Windows 平台上有些旧补丁在卸载后需要重启服务这点也要一并考虑进去。还需要提醒的是prereq 检查通过不代表 apply 一定成功但 prereq 检查失败的情况下 apply 大概率必死。所以这一步是低成本止损的关键点。3.3 停服务和文件锁Windows 不给你任何侥幸机会Linux 上打补丁时哪怕数据库进程还开着某些文件操作也能蒙混过关Windows 完全不同。Oracle 的 DLL 和 exe 一旦被进程加载文件系统层面就是绝对锁定状态不允许被替换或删除。所以在 opatch apply 之前必须把相关的 Oracle 服务全部停止包括监听服务和数据库实例服务。建议按下面的顺序操作net stop OracleOraDb12c_home1TNSListener net stop OracleServiceORCL服务名不固定用services.msc查看实际的服务名。如果数据库处于 RAC 环境还需要考虑 CRS 服务但 Windows 单机场景相对简单。光停完服务不代表万事大吉。有时某些后台程序或备份代理仍然打开了 ORACLE_HOME 下的文件apply 时就会报 file is being used by another process。定位占用进程可以用 Sysinternals 的 handle.exehandle.exe -a oraClass12.dll查到占用进程后根据实际情况停掉对应程序再重新检查。这个过程虽然琐碎但比打补丁打一半挂住要省钱省心得多。4. 正式打补丁apply、日志、datapatch 三步走4.1 opatch apply 命令与参数说明环境准备完毕、冲突检查通过、服务停止干净后终于可以进入正题了。在管理员 cmd 中执行cd /d %ORACLE_HOME%\OPatch opatch apply C:\temp\37537949如果系统能找到正确的 oraInventory命令可以直接执行。如果提示找不到中央清单或者对权限有疑虑可以显式指定 inventory 位置opatch apply C:\temp\37537949 -invPtrLoc C:\Program Files\Oracle\Inventory\oraInst.locoraInst.loc记录了 inventory 目录和安装用户信息很多 Windows 环境的 OPatch 问题都出在这个文件的访问权限上。直接用管理员权限指定它的路径能绕开一部分权限坑。如果服务器上有多个 Java 环境避免 OPatch 从一开始就挑错 JVM可以配合-jdk C:\Java\jdk1.8.0_211参数指定 JDK 路径。这个参数能省去很多环境变量混乱导致的诡异错误。apply 执行期间尽量让服务器保持没人碰的状态不要同时打开大量 Oracle 相关文件别通过 Windows 远程桌面去反复查看目录结构这些动作看似无害但确实会增加文件被占用的概率。整个执行过程中只盯着日志和命令输出就行了。4.2 日志文件里的关键信息和常见误判执行结束后不能只看窗口最后的提示。OPatch 通常会在%ORACLE_HOME%\cfgtoollogs\opatch下生成带时间戳的日志文件比如opatch2025-06-15_10-23-45.log。打开这个文件重点搜索这几个词findstr /i error fatal failed opatch2025-06-15_10-23-45.log如果最终输出是 OPatch succeeded一般可以判定二进制补丁应用成功。但要注意日志中会有一些 warning比如某个文件不是精确匹配、某个可选组件跳过等这些不一定影响结果。真正的 ERROR 和 FATAL 才是需要处理的。有一个常见误判有些补丁在前置检查阶段输出几行 Prerequisite check ... failed但后面又显示 succeeded。这种情况需要仔细阅读 failed 的具体内容——如果 failed 的检查项只是针对某个不存在的组件或平台特性且 OPatch 判定为可忽略最终结果仍可能是成功。但如果你对这个失败项没把握最稳妥的做法是到 MOS 提问或者对照 README 检查不要赌它没事。4.3 datapatch 与 SQL 补丁不跑等于白打12c 之后光 opatch apply 成功是不够的。补丁包中的 SQL 变更需要数据库启动后才能应用工具就是 datapatch。假设你的数据库服务已经启动执行%ORACLE_HOME%\OPatch\datapatch -verbosedatapatch 会自动检测当前数据库版本、已经安装的 SQL 补丁并把缺失的 SQL 补丁应用进去。执行完成后可以通过数据字典确认 SQL 补丁状态SELECT * FROM dba_registry_sqlpatch ORDER BY action_time DESC;如果查到对应补丁版本出现在列表中说明 SQL 补丁也已经生效。这一步别偷懒我见过好几位同事 opatch apply 成功后就直接交付了结果业务方反馈这个 Bug 还在问题就出在 datapatch 没跑。严格来说一次完整的补丁操作应该包含二进制补丁和 SQL 补丁两部分漏掉任何一环都不能算完成。如果 datapatch 执行中报了错误先把数据库的 alert 日志和 datapatch 的输出日志对照着看。常见的问题包括数据库实例没有完全启动、PDB 未打开、或者某个 SQL 文件因权限无法编译。逐个解决后重新执行 datapatch 即可它是幂等的不会重复应用已经成功的补丁。5. 我在 Windows 上踩过的三个坑5.1 错误代码 73 inventory 权限和 oraInst.loc第一次在 Windows 上跑 opatch apply 时我被 OPatch failed with error code 73 卡了很久。这个错误代码信息量有限日志里通常只写 Central Inventory is not accessible 之类。网上很多翻译含糊不清实际上多半是因为当前用户的权限不够或者oraInst.loc指向的 inventory 目录不可写。解决思路就是给当前用户授予 inventory 目录的完全控制权限并在命令中显式指定-invPtrLoc。权限修改方式很简单右键 inventory 目录进入安全设置把当前管理员账户加入完全控制列表。改完后重新执行 opatch问题基本消失。还有一个隐蔽细节某些数据库的 ORACLE_HOME 是从其他服务器拷贝过来的orainventory 路径写的是原机的路径这在 Windows 上很常见。这种情况下别犹豫直接修改oraInst.loc指向本机实际 inventory 路径或者重建一个引用文件。5.2 文件被占用老是在应用层翻车之前提到过停服务但真正让我吃大亏的是第三方应用。数据库服务器上可能装了 PL/SQL Developer、Navicat、甚至某些网管监控 Agent它们会在后台打开 Oracle 的 DLL 文件。opatch apply 进行到一半突然报 FolderRefresh.dll is used by another process那种心情真的酸爽。那次我用 handle.exe 定位到是某个监控 Agent 的服务进程占用了文件但net stop停了 Oracle 服务后它依然活着。无奈之下只能停掉监控 Agentapply 完再启动回来。事后我把这个经验固化成操作清单打补丁前除了 Oracle 服务还要把第三方数据库工具和相关监控 Agent 全部列入停止范围。宁可在补丁完成后费点时间恢复也不要中途挂起。5.3 回滚与重打的正确姿势补丁打失败后不要急着重新 apply先搞清失败原因否则会反复失败。如果确实需要回滚命令是opatch rollback -id 37537949同理回滚完成后检查 SQL 补丁是否也需要回滚必要时执行%ORACLE_HOME%\OPatch\datapatch -rollback -id 37537949整个流程里我给自己定的一条铁律是每次补丁操作前后都保留一份opatch lsinventory的结果并且把执行时间、OPatch 版本、补丁号记录在运维变更表中。Windows 平台的 Oracle 环境往往比 Linux 更难从二进制层面快速判断当前补丁状态一份扎实的变更记录能在几个月后的故障排查中省下至少半天的定位时间。最后再分享一个小技巧补丁打完后别急着把那个临时解压目录C:\temp\37537949删掉。等数据库跑几天、确认业务无异常后再清理万一需要回滚这个目录还能复用一下省去重新下载解压的时间。补丁这件事尤其在 Windows 平台上耐心和留一手比手速重要得多。本文还有配套的精品资源点击获取