简介：本资源为Oracle 12c数据库在Windows平台上的补丁安装包，对应补丁编号p33174380，版本号122010，面向需要在Windows Server或Windows 10/11环境下部署、升级Oracle 12c的数据库管理员与运维工程师。压缩包内共约2000个文件，以msb、dll、sql、plb、exe、jar等类型为主，涵盖可执行程序、动态链接库、SQL脚本、PL/SQL二进制库及Java组件，另有bat批处理、xml配置、sym符号文件与readme说明等，整体约780.27MB，目录结构完整，便于按模块定位所需组件。内容预览中可见asmcmdcore、asmproxy、cvuhelper.bat、acfsdriverstate.bat等与ASM及集群验证相关的工具脚本，说明该补丁包覆盖数据库核心与集群文件系统驱动层面。目前已有1433人学习下载，适合需要完成Oracle 12c补丁升级、环境校验与故障排查的读者参考使用。
1. 从 p33174380 这个补丁号说起：12c 在 Windows 上到底缺了什么
手上拿到一个p33174380_122010_MSWIN-x86-64.zip，第一反应往往不是「这是啥」，而是「Oracle 12c 在 Windows 上又出什么幺蛾子了」。p33174380 是 Oracle 官方补丁编号，122010 对应 12.2.0.1 这个版本线，MSWIN-x86-64 说明它是 Windows 64 位平台的补丁包。这类 zip 通常不是完整安装介质，而是打在已有 12.2.0.1 库上的补丁集，解压后能看到 README、opatch 目录和一堆 patch 子目录。
真正让人头疼的是：12c 在 Windows 上装完、跑一段时间后，会出现监听起不来、实例莫名挂掉、OPatch 报版本冲突、卸载残留注册表导致重装失败。这些问题单靠重装解决不了，必须靠补丁和清理。这篇笔记就围绕这个补丁包，把「12c 在 Windows 上怎么打补丁、怎么清干净、怎么验证」讲透，适合正在维护 12c 单机库或准备重装的 DBA 和运维。
2. 解压 p33174380 之前：先搞清 12c 补丁在 Windows 上的目录结构
2.1 补丁包里的目录到底对应什么
把p33174380_122010_MSWIN-x86-64.zip解压到一个短路径下，比如D:\patch\33174380，不要放在桌面或带中文、空格的路径里。解压后典型结构是这样的：
| 目录/文件 | 作用 | 是否必须 |
|---|---|---|
README.html/README.txt | 补丁说明、前置条件、已知问题 | 必读 |
etc/config/ | 动作配置，决定 opatch 怎么执行 | 必须保留 |
files/ | 实际替换的二进制和 SQL | 必须保留 |
<patch_id>/ | 子补丁目录，含etc和files | 视补丁而定 |
opatch/ | 有时自带 opatch 版本 | 看 README |
很多人解压完直接进files找 exe，这是错的。Windows 上 opatch 依赖etc/config/inventory和action文件来决定复制哪些文件、执行哪些 SQL。目录结构被破坏，opatch 会报Unable to determine patch type。
2.2 打补丁前必须确认的三件事
第一，确认当前 OPatch 版本。12.2.0.1 自带的 opatch 往往太老，打新补丁会直接失败。进%ORACLE_HOME%\OPatch执行：
opatch version如果低于补丁 README 要求的最低版本，先去 MOS 下载对应 opatch 替换，替换前把旧 OPatch 目录改名备份。
第二，确认 ORACLE_HOME 和实例状态。补丁要在库关闭、监听停止的状态下打。用管理员身份开 CMD：
set ORACLE_HOME=D:\app\oracle\product\12.2.0\dbhome_1 set PATH=%ORACLE_HOME%\bin;%ORACLE_HOME%\OPatch;%PATH% sqlplus / as sysdba进去后执行shutdown immediate，再exit。监听用lsnrctl stop停掉。
第三，检查有没有残留的 opatch 锁。如果之前打补丁中断过，%ORACLE_HOME%\OPatch下会有临时目录，直接删掉再继续，否则新补丁会卡在Prerequisite check failed。
提示：Windows 上路径长度是硬限制，ORACLE_HOME 尽量控制在 30 字符以内，补丁解压路径同理，否则 opatch 复制文件时会报路径过长。
3. 用 opatch apply 把 p33174380 打进去：命令、参数与失败回看
3.1 最小可复现的打补丁流程
确认实例和监听都停了之后，在补丁解压目录的上一级执行。假设解压到D:\patch\33174380，补丁根目录就是它本身：
cd D:\patch\33174380 opatch applyopatch 会自动读取当前目录的etc/config，识别出这是 12.2.0.1 的补丁，然后做前置检查、备份、复制文件、执行 SQL。整个过程会输出大量日志，重点看最后几行：
OPatch succeeded.表示成功。OPatch failed with error code 73通常是 inventory 不一致。OPatch failed with error code 104多半是文件被占用，检查有没有没停干净的服务。
如果补丁包里有多个子补丁，opatch 会依次处理，不要中途 Ctrl+C。Windows 上中断后残留的%ORACLE_HOME%\.patch_storage会让下次 apply 直接报冲突。
3.2 参数怎么改：-invPtrLoc 和 -jre 的用法
有些环境 ORACLE_HOME 下没有oraInst.loc，或者 inventory 指向了旧路径，这时要显式指定：
opatch apply -invPtrLoc D:\app\oracle\oraInst.loc-invPtrLoc告诉 opatch 去哪里读中央 inventory，Windows 上这个文件默认在C:\Program Files\Oracle\Inventory或 ORACLE_HOME 上级。如果报Central Inventory not found，就是它没找对。
另一个常见参数是-jre，当 opatch 自带的 JRE 和系统 Java 冲突时指定：
opatch apply -jre D:\app\oracle\product\12.2.0\dbhome_1\jdk一般不需要改，除非报Java could not be loaded。改之前先确认 ORACLE_HOME 下确实有 jdk 目录。
3.3 打完补丁后的收尾动作
apply 成功后不要急着起库。先执行：
cd %ORACLE_HOME%\OPatch opatch lspatches确认新补丁号出现在列表里。然后加载 SQL 变更，12c 的补丁通常要求跑datapatch：
cd %ORACLE_HOME%\OPatch datapatch -verbosedatapatch会把补丁里的 SQL 应用到 CDB 和 PDB。如果库是 CDB 模式，要确认每个 PDB 都 open 了，否则会报PDB not open。跑完再看dba_registry_sqlpatch视图，状态是SUCCESS才算真正完成。
4. 12c 卸载不干净怎么排查：注册表、服务与残留目录
4.1 卸载残留的四个藏身点
12c 在 Windows 上用自带 deinstall 卸载后，经常留下这些东西，导致重装时报「已存在实例」或监听端口被占：
| 残留位置 | 具体内容 | 清理方式 |
|---|---|---|
| 注册表 | HKEY_LOCAL_MACHINE\SOFTWARE\Oracle | 备份后删除对应键 |
| 服务 | OracleService<SID>、OracleOraDB12Home1TNSListener | sc delete删除 |
| 目录 | ORACLE_BASE、ORACLE_HOME 残留 | 手动删，注意先停服务 |
| 环境变量 | ORACLE_HOME、TNS_ADMIN | 系统属性里清掉 |
注册表是重灾区。HKLM\SOFTWARE\Oracle下会有KEY_OraDB12Home1之类的键，deinstall 有时删不干净。删之前先导出备份，这是后悔药。
4.2 用命令定位占用端口的进程
重装前如果报 1521 被占，用这条命令找：
netstat -ano | findstr :1521拿到 PID 后：
tasklist | findstr <PID>如果是残留的 oracle.exe，先sc stop对应服务，再sc delete。服务名可以用sc query state= all | findstr Oracle列出来。删服务要在管理员 CMD 里做，普通权限会报拒绝访问。
4.3 彻底清理的推荐顺序
血泪经验是：先停服务，再跑 deinstall，再删注册表，最后删目录。顺序反了，deinstall 会因为找不到文件而报错，注册表反而留得更深。deinstall 在%ORACLE_HOME%\deinstall下，执行：
cd %ORACLE_HOME%\deinstall deinstall -home %ORACLE_HOME%它会交互式问你是否保留某些组件，按实际情况选。跑完后手动检查上面表格里的四个位置，确认干净了再重装。
5. 避坑与排查：12c 打补丁和清理时最容易翻车的五件事
现象一：opatch apply 报 “Prerequisite check failed”，日志里说 inventory 不一致。原因：之前打过补丁但没跑 datapatch，或者手动改过 inventory。解决：先opatch lsinventory -detail看当前状态，对比补丁 README 的前置补丁列表，缺哪个先补哪个，不要跳版本。
现象二：datapatch 跑到一半报 “PDB not open”。原因：CDB 模式下 PDB 处于 mounted 状态。解决：先alter pluggable database all open;，再重跑 datapatch。如果 PDB 已经 open 还报，检查v$pdbs里的 open_mode。
现象三：卸载后重装，监听起不来，报 “TNS-12560”。原因：旧监听服务没删干净，或者注册表里还留着旧 ORACLE_HOME 路径。解决：sc query找残留服务删掉，注册表里搜旧路径全部清掉，再重建监听。
现象四：补丁打完后实例起不来，alert log 报 “ORA-01092”。原因：datapatch 没跑或跑失败，数据字典和二进制版本不匹配。解决：进sqlplus / as sysdba，startup upgrade，手动跑?/rdbms/admin/catbundle.sql，再shutdown正常启动。
现象五：解压 zip 时提示 “invalid zip archive: could not find eocd”。原因：下载不完整或用了不支持的压缩工具。解决：重新下载，用 7-Zip 或系统自带解压，别用某些在线解压工具。校验文件大小和官方公布的一致再解压。
注意：每次打补丁前把
%ORACLE_HOME%\.patch_storage和%ORACLE_HOME%\OPatch备份一份，出问题能快速回退，比重新装库省几个小时。
6. 补丁打完怎么验证：三个视图加一个回退习惯
补丁和清理都做完，别只看 opatch 输出就收工。我一般会查三个地方确认状态。第一，opatch lspatches看补丁列表，确认 p33174380 在列。第二，进库查dba_registry_sqlpatch：
select patch_id, action, status, action_time from dba_registry_sqlpatch order by action_time desc;status是SUCCESS才算 SQL 层也生效了。第三，查v$instance和v$version，确认实例正常 open 且版本号带上了补丁标识。
回退这件事，Windows 上比 Linux 麻烦。opatch 的rollback依赖.patch_storage里的备份，如果之前清理时把它删了，就只能重装。所以我的习惯是：打完补丁、验证通过后，把.patch_storage整个目录复制到另一个盘存着，命名带上补丁号和日期。下次再打新补丁前，先确认这个备份还在。
另一个习惯是每次动 ORACLE_HOME 之前，用expdp把关键 schema 导一份，哪怕库不大也导。补丁本身不碰数据文件，但 datapatch 失败导致库起不来时，有逻辑备份心里不慌。这些动作花不了多少时间，真出事的时候就是救命的那一下。希望帮到你。
本文还有配套的精品资源，点击获取
