简介这是面向 Windows x64 平台的 Oracle 12c 数据库安装介质与配套补丁资源对应官方补丁编号 p33174380适用于需要在 Windows 服务器上部署或升级 Oracle 12c 数据库的 DBA、运维工程师及数据库技术爱好者。压缩包大小约 780MB共包含 2000 个文件从类型分布看既有 413 个 DLL 动态链接库支撑数据库运行也有 315 个 SQL 脚本用于建库、配置与初始化配合 198 个 PLB 存储过程包、176 个 EXE 程序以及 88 个 JAR 包基本覆盖数据库核心组件、自动安装工具和日常维护脚本。资源保留了官方安装包的原始目录层级和文件命名便于使用者按需查找组件、核对介质完整清单减少因文件缺失或版本混乱导致的部署失败问题。目前已获得 1433 人学习下载适合有一定 Oracle 基础、需要在 Windows 环境快速准备 12c 安装素材的读者离线使用对于搭建本地测试环境、复盘安装过程或研究官方组件构成也有直接帮助。1. p33174380 这个 Windows 补丁包Oracle 12c 运维绕不开的一步棋p33174380_122010_MSWIN-x86-64.zip 这个文件是 Oracle 12c 在 Windows x86-64 平台上的正式补丁包。文件名本身就是一套解谜线索33174380 是补丁编号122010 对应数据库版本 12.2.0.1.0MSWIN-x86-64 则限定了这是 64 位 Windows 专用的版本。做 Oracle 12c 维护的人隔几个月就会撞上一次这种 zip问题在于很多人把它当普通压缩包解压完直接 apply然后被 OPatch 版本、路径空格、服务没停这些盘外招挨个绊倒。这篇按我实际拆补丁的顺序把 Windows 上从解压到验证回滚的完整流程走一遍新手能照着操作熟手可以直接跳去第 4 章看翻车位。适合正在 Windows 服务器上维护 12.2.0.1、或者刚拿到 PSU/CPU 补丁犹豫怎么下手的人。2. 动手前先立规矩OPatch 版本、目录布局与补丁属性辨识打补丁这件事九成失败不是补丁本身的问题而是准备工作没做到位。Windows 平台尤其如此路径习惯、服务模式、权限模型都和 Linux 差着一截所以我每次拿到新补丁都会先花十分钟把工具链和环境检查完再动 apply。2.1 先读文件名补丁类型与版本归属Oracle 的补丁包命名不是随机字符串它把最关键的元数据都编码在文件名里。以 p33174380_122010_MSWIN-x86-64.zip 为例逐个拆开看文件名片段含义常见取值举例p33174380补丁号Bug Number / Patch ID33174380 对应一个具体的季度补丁或补丁集122010数据库版本编码12201012.2.0.1.012102012.1.0.2.0MSWIN-x86-64平台标识MSWINMicrosoft Windowsx86-6464位.zip压缩格式Oracle 在 Windows 平台统一打包为 zip33174380 这种 8 位编号常见于 CPUCritical Patch Update或 PSUPatch Set Update这类季度补丁也可能是个 Bundle Patch。判断具体类型不能靠猜解压完之后跑一条 opatch 就能确认但它一定是基于 12.2.0.1.0 这个基线版本做的增量不会跨大版本。我见过不少人在这一步出错手里拿的是 12.2.0.1 的补丁库却是 12.1.0.2还硬往上 apply。opatch 在 prereq 检查阶段会直接把这种操作挡下来报“Patch is not applicable”之类的错。所以动手前先确认数据库大版本拿 SQL 验证一下最快set linesize 120 select version, banner from v$version where rownum 2;这条 SQL 用来确认当前数据库实例的版本号。如果第一行不是 .0那这份补丁就不该出现在这台机器上。版本号对不上时别尝试硬绕去换对应版本的补丁包才是正路。2.2 OPatch决定补丁成败的底层工具OPatch 是 Oracle 官方提供的补丁管理工具所有 apply、rollback、inventory 操作都由它完成。打补丁之前必须确认它的版本不低于补丁包的最低要求否则会在 prereq 阶段直接失败报错长这样OPatch version 12.2.0.1.0 is not supported by the current OPatch version.这条报错的意思是你 Home 里装的 OPatch 太老不认识新补丁的元数据格式。解决方法不是绕过检查而是先升级 OPatch。常见做法是从 My Oracle Support 下载最新的 p6880880OPatch 的补丁包解压后替换%ORACLE_HOME%\OPatch目录。替换之前先给原目录留个备份这是最基本的后悔药。OPatch 本身的版本检查命令非常简单但要注意在正确的目录环境下运行set ORACLE_HOMEC:\app\oracle\product\12.2.0\dbhome_1 set PATH%ORACLE_HOME%\OPatch;%ORACLE_HOME%\bin;%PATH% opatch version这里我把 ORACLE_HOME 显式设成了 12.2.0.1 的 Home 路径然后把 OPatch 目录和 bin 目录都塞进 PATH 前端。这样做是为了防止系统里存在其他版本的 opatch 命令导致工具和 Home 不匹配——Windows 上 PATH 优先级踩坑非常常见。opatch version 输出形如OPatch Version: 12.2.0.1.3x记下这个数字后面核对补丁要求时会用到。2.3 环境基线三分钟摸清 Home 状态在 apply 之前我一般强制自己走一遍环境基线检查。这不是形式主义而是给补丁前后留对照样本。Windows 服务器上最容易被忽略的是服务状态和路径形态这两点放到第 4 章再展开先看必跑的三条命令opatch lsinventory sc query OracleServiceORCL sc query OracleOraDB12Home1TNSListener第一条opatch lsinventory列出 Home 里已安装的全部补丁它同时会输出 OPatch 版本、安装路径等信息。你拿到的 33174380 如果是更新补丁inventory 里必须已经存在它的前序补丁缺了就会出现依赖错误。后面两条sc query是 Windows 服务查询命令确认数据库实例服务和监听服务的当前状态——如果显示 RUNNINGapply 之前必须先停掉。这三个检查做完环境是什么样心里基本有数了。这一步多花三分钟能省掉后面两个小时的排错时间。3. 解压与 apply从 zip 到补丁生效的完整流程准备工作做完进入正题。这一章覆盖从解压 zip 到 SQL 补丁落地的完整链路每一步我都会给出命令、说明为什么这么做以及失败时从哪里看日志。3.1 解压这一步的讲究路径、工具与层级结构Oracle 补丁的 zip 包解压后顶层是一个以补丁 ID 命名的目录里面才是真正的补丁文件。以 p33174380 为例解压后应该看到C:\patch\33174380\然后再进一层能看到etc、files等子目录和patch.xml元数据文件。如果解压出来找不到这层结构说明解压方式有问题。解压路径上务必做到两点纯英文、无空格。Windows 的系统路径本身已经够长Oracle Home 的默认路径C:\app\oracle\product\12.2.0\dbhome_1动辄 40 多个字符补丁解压位置如果继续嵌套在深层目录下很容易触发路径长度上限。我一般固定在服务器上建一个C:\patch目录专门用来放补丁包cd /d C:\patch unzip p33174380_122010_MSWIN-x86-64.zipunzip是 Oracle 自带或独立安装的解压工具。如果你机器上没有这个命令用 7-Zip 的命令行也可以但不建议用 Windows 资源管理器右键的“全部解压缩”它在处理深层目录和长路径时经常给出含糊的失败提示。解压完成后用 dir 确认目录结构dir C:\patch\33174380正常情况下应该能直接看到etc、files、patch.xml等内容。如果里面只有一个孤零零的安装说明 txt八成是拿某个第三方工具解压时把目录层级打平了。这种情况别继续重新解压否则 opatch 会找不到补丁描述文件直接报“Patch location is invalid”。3.2 关闭实例与监听Windows 服务模式下的固定顺序打补丁改的是 Oracle Home 里的二进制文件数据库和监听还占着这些文件时apply 几乎必挂。Windows 上 Oracle 以系统服务方式运行很多人习惯性地直接去任务管理器找进程其实用服务命令更干净。顺序必须是先停实例、再停监听反过来启动时先监听后实例sqlplus / as sysdba进入 SQL*Plus 后执行关库shutdown immediate; exit;shutdown immediate是常规生产库停库的首选它会阻止新会话、回滚未提交事务后关闭实例。如果库里有长时间未结束的事务immediate 也可能卡住此时再考虑 shutdown abort但那是下策执行前后都要确认原因。退出 SQL*Plus 后停监听lsnrctl stoplsnrctl 会打印Stopping listener和TNS-01111/TNS-01110这类状态码看到Command completed successfully才算真正停下。Windows 上还有一种情况是监听服务被配置为自动重启lsnrctl stop之后服务又拉起来此时需要用 sc 确认服务状态sc query OracleOraDB12Home1TNSListener如果状态是 RUNNING说明服务自启策略挡了路直接用sc stop或者net stop停掉服务再继续。这里不啰嗦但顺序真的不能换先库后监听避免了监听还握着 Home 目录里的网络配置文件导致 opatch 文件替换失败的场面。3.3 opatch apply命令行参数与执行策略环境和停服务都就绪之后apply 本身反而是最机械的一步。进入补丁目录执行cd /d C:\patch\33174380 opatch applyopatch 会先做一轮 prereq 检查验证 OPatch 版本、数据库状态、补丁依赖、inventory 完整性。这些检查全部通过后才会真正动文件所以前面任何一步偷懒都会在这里以报错的形式反弹回来。检查阶段比较慢几十秒到几分钟不等日志会刷屏耐心等着到Patching component...的阶段才算开始替换文件。如果 opatch 进入交互询问提示要 My Oracle Support 账号和密码说明它需要读取 OCM 配置文件。常见做法是用响应文件跳过交互opatch apply -silent -ocmrf %ORACLE_HOME%\OPatch\ocm\ocm.rsp-silent表示非交互模式适用于远端执行或无人值守-ocmrf指定 OCM 响应文件路径里面预置了配置信息避免卡在账号输入这一步。注意 ocm.rsp 的路径在不同版本、不同安装方式下可能不一致找不到时在%ORACLE_HOME%\OPatch\ocm目录里 ls 一下即可。apply 成功的标志不是窗口关闭而是最后几行输出里有这么一句OPatch succeeded.看到这行字补丁的二进制部分才算替换完成。但注意这还不代表补丁在数据库层面已经生效SQL 变更还等着另行处理。所以下一步必须进 datapatch。3.4 datapatch12c 补丁真正落地的另一半从 12.2 开始Oracle 把补丁拆成了两部分二进制替换和 SQL 变更。前者由 opatch apply 完成后者由 datapatch 工具执行。很多人打完补丁发现数据库起来后版本没变、Bug 还在十有八九是跳过了 datapatch。datapatch 命令本身很简单但有个前提数据库实例必须先启动否则它无法连接数据库执行变更。所以现在把启动顺序反过来先监听、再实例lsnrctl start sqlplus / as sysdba进入 SQL*Plus 后startup; exit;启动完成后执行 datapatchcd %ORACLE_HOME%\OPatch datapatch -verbosedatapatch 会读取 inventory 里的补丁清单自动识别哪些补丁带 SQL 变更、哪些已经 applied然后逐个执行。-verbose让它把每一步细节都打印出来方便出问题时定位。执行时间视补丁复杂度而定短则几分钟长则半小时期间它会输出类似Adding SQL patch ...这样的进度行。执行结束后日志通常会提示... successfully applied或者列出失败项。如果出现失败别急着重跑先看%ORACLE_HOME%\OPatch\datapatch\目录下的日志文件大多数情况是某条 SQL 在特定数据条件下报错需要人工介入而不是盲目重试。到这里补丁在二进制和数据字典两个层面都完成了。接下来要做的事是花十分钟把补丁生效的证据留下来这就是第 5 章要讲的验证。4. 避坑与排查Windows 上打 12c 补丁的五个翻车现场这一章全部来自真实环境里的血泪经验每条都是我先踩过、后来帮别人填过的坑。Windows 平台上的 Oracle 补丁问题跟 Linux 上最大的区别在于路径规则、服务模型和权限体系所以排错方向也要跟着调整。4.1 现象prereq 检查报 OPatch 版本不支持补丁 apply 一开始就中断日志里写着OPatch version ... is not supported或者提示最低版本要求未满足。原因是 Home 里的 OPatch 工具版本低于补丁包要求这在长时间未升级 OPatch 的 12.2 环境里很普遍。解决方式不是绕过而是先升级从 MOS 下载对应平台的 p6880880备份现有%ORACLE_HOME%\OPatch后整体替换再重新跑 apply。从那以后我每季度接补丁都顺手查一次 OPatch 版本养成习惯就没再被这个坑绊倒过。4.2 现象路径带空格或过长导致 apply 失败补丁解压到了C:\Users\Administrator\Desktop\新建文件夹\oracle patch\p33174380这种路径opatch 报错说找不到目录或者无法创建临时文件。原因是 Windows 上路径中的空格和中文编码会影响 opatch 内部脚本对路径的解析而 260 字符的路径上限在深层目录下更容易被突破。解决做法是统一把补丁放在C:\patch这种短路径下目录名只用字母、数字和下划线。我见过有人用 Desktop 路径跑通过一次但那属于玄学不值得赌。4.3 现象apply 中途报无法复制文件补丁替换文件时报cannot copy file或提示文件被占用。原因十有八九是数据库实例或监听服务还在运行Oracle 的二进制文件被进程锁定。去服务管理器确认 OracleService 和监听服务状态全部停止后再补 apply 即可。Windows 上还有一个隐蔽来源杀毒软件实时扫描锁定了文件。如果停完服务仍然报锁文件临时关掉文件实时保护再试一次是常见的排查手段。4.4 现象解压 zip 时提示输入密码或 CRC 校验失败从非官方渠道拿到的补丁包解压时毫无征兆地弹出密码框或者解压到一半报 CRC 错误。前者是 zip 伪加密文件头的通用位标记被改过并非真正加了密后者说明传输过程损坏也可能下载不完整。解决方法是先换 7-Zip 打开看看能不能直接列出内容伪加密的包通常用 7-Zip 可以直接解出来CRC 错误就重新下载对比文件大小或者核对官方公布的 md5 校验值。补丁包这种基础设施级的文件永远只从 My Oracle Support 或内部统一分发渠道拿。4.5 现象数据库起来后版本没变Bug 依旧opatch apply 显示 success但启动数据库后执行 SQL 还是旧行为opatch lsinventory里却能看见补丁在列。这种情况是只跑了 opatch、没跑 datapatch。12.2 以后 SQL 变更和二进制替换分离opatch 负责文件datapatch 负责数据字典漏了后者应用层的修复就不会生效。解决方式是启动数据库后执行datapatch看到 SQL patch 全部 applied 才算闭环。这是当前 12c 运维最大的理解偏差我每次培训新人时都把它当重点讲。5. 验证补丁从 lsinventory 到数据库侧的双向确认补丁打完了验证不是可选项。我见过太多人看完OPatch succeeded就交付结果两周后生产环境暴露出旧 bug回头一查 SQL 补丁根本没落地。验证必须双向OPatch 侧确认文件已替换数据库侧确认 SQL 变更已生效。5.1 OPatch 侧验证lsinventory 的正确用法最直观的验证命令是重新查 inventory确认 33174380 已经在已安装列表里opatch lsinventory | findstr /i 33174380这里findstr是 Windows 下的文本过滤命令等效于 Linux 的 grep。如果输出里出现了 33174380 这一行说明补丁进入了 Home 的 inventory。但 findstr 只能告诉你「有记录」补丁状态到底是 applied 还是 invalid还需要看完整输出。更严谨的验证用 bugid 参数直接查opatch lsinventory -detail -bugid 33174380-detail输出补丁的详细信息-bugid则按补丁号过滤。执行结果会明确显示该补丁的状态、安装时间、引用位置。我通常同时跑这两条findstr 快速确认detail 留存档。5.2 数据库侧验证registry$sqlpatch 与组件状态二进制替换成功不代表数据库层面的变更已生效所以还要登录数据库查补丁注册表视图。12.2 引入了dba_registry_sqlpatch视图它是 SQL 补丁状态的权威来源set linesize 200 col patch_id format 99999999 col action format a10 col status format a15 col action_time format a20 select patch_id, action, status, to_char(action_time, yyyy-mm-dd hh24:mi) as action_time from dba_registry_sqlpatch where patch_id 33174380;这条查询返回该补丁在数据字典层面的执行记录。关键看两列ACTION应为APPLYSTATUS应为SUCCESS。如果 STATUS 是WITH ERRORS或者根本没有返回行说明 datapatch 阶段出了问题需要回头查看日志排查。顺手再做一次组件验证确认数据库核心组件没有因为打补丁出现失效select comp_name, version, status from dba_registry order by comp_name;这条 SQL 输出全部注册组件及状态。正常情况下所有组件 STATUS 都是VALID出现UPGRADED或INVALID就要盯住尤其是 SDO、XDB 这类与应用强相关的组件。5.3 快速回归服务、端口与基本功能双向验证都通过后最后补一轮运行时回归。Windows 上最值得确认的是服务状态和监听端口是否恢复正常sc query OracleServiceORCL sc query OracleOraDB12Home1TNSListener netstat -ano | findstr 1521前两条确认实例服务和监听服务都处于 RUNNING后一条确认 1521 端口正在监听netstat输出的最后一列是 PID可以配合任务管理器确认它属于 oracle.exe。监听如果没起来数据库连不进来前面所有验证都白搭。到此补丁的验证闭环才算完整。我把第 5 章的验证点整理成一张自查表每次打完补丁照着走一遍比临时想命令可靠得多验证层次命令期望结果补丁文件状态opatch lsinventory -bugid 33174380显示补丁已应用SQL 补丁状态select from dba_registry_sqlpatchACTIONAPPLYSTATUSSUCCESS组件状态select from dba_registry关键组件 VALID服务状态sc query OracleServiceORCLRUNNING监听端口netstat -ano | findstr 15211521 端口 LISTENING6. 回滚意识与收尾习惯给 Windows 12c 留好后悔药补丁不是每次都顺真出了问题要有全身而退的路线。回滚的命令不少人不熟其实操作上比 apply 还简单前提是别慌cd /d C:\patch\33174380 opatch rollback -id 33174380-id后面跟补丁号opatch 会从 inventory 里找到这个补丁然后把文件替换回之前的版本。回滚完成后很多人又踩一次同样的坑忘了 datapatch。跟 apply 一样回滚二进制之后必须同步回滚 SQL 变更否则数据字典里还残留着补丁的修改记录。datapatch -revert -verbose-revert让 datapatch 反向执行与补丁对应的 SQL 变更。跑完之后再查一次dba_registry_sqlpatch确认对应补丁的 action 变为 ROLLBACK、状态变为 SUCCESS整个回滚才算干净。回滚的事说完我想认真分享一个自己的习惯。从那以后我每次给 Windows 上的 12c 打补丁都强制走一遍四件事先把 opatch version 和原始 lsinventory 输出存个文本再给%ORACLE_HOME%\OPatch目录留备份apply 之前确认实例和监听全部停止apply 之后数据库一启动就先跑 datapatch 再查 registry$sqlpatch。这套流程看着笨但已经帮我挡掉至少三次因漏跑 datapatch 导致的返工。补丁这件事最贵的从来不是下载时间和磁盘空间而是事后救火的时间成本前期多花十分钟把证据链留齐后面就能少熬几个夜。希望帮到你。本文还有配套的精品资源点击获取