简介本资源为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 和实例状态。补丁要在库关闭、监听停止的状态下打。用管理员身份开 CMDset ORACLE_HOMED:\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 会依次处理不要中途 CtrlC。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 去哪里读中央 inventoryWindows 上这个文件默认在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 的补丁通常要求跑datapatchcd %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备份后删除对应键服务OracleServiceSID、OracleOraDB12Home1TNSListenersc 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 sysdbastartup 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_sqlpatchselect 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 失败导致库起不来时有逻辑备份心里不慌。这些动作花不了多少时间真出事的时候就是救命的那一下。希望帮到你。本文还有配套的精品资源点击获取