企业官网建设流程全解析

简介：本资源为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配置、msg提示信息等辅助文件，整体约780.27MB，目录结构完整，便于按模块定位所需组件。资源中涉及asmcmdcore、asmproxy、cvuhelper等ASM与集群验证相关工具，可用于补丁应用前的环境检查与依赖校验。目前已有1433人学习下载，适合需要完成Oracle 12c补丁升级、排查安装兼容性问题或搭建测试环境的技术人员参考使用。

1. 从一个补丁包名说起：p33174380 到底解决了 Oracle 12c 在 Windows 上的什么问题

如果你在 Windows 上装过 Oracle 12c，大概率见过这种文件名：p33174380_122010_MSWIN-x86-64.zip。第一次看到它的人通常会愣一下——这串字符既不像版本号，也不像安装包，解压出来一堆目录，完全不知道从哪下手。其实这是 Oracle 官方补丁包的标准命名：p后面跟补丁编号，122010对应 12.2.0.1 版本，MSWIN-x86-64说明它是 Windows 64 位平台的，.zip就是压缩包本体。搞懂这个命名规则，你就能在 Oracle 支持站点上一眼认出哪个补丁该下、哪个不该下。

这篇文章面向的是在 Windows 环境里维护 Oracle 12c 的开发和运维人员。你可能刚接手一套老系统，发现某个功能报错，查 MOS 文档说需要打补丁 p33174380；也可能只是想把补丁流程走一遍，搞清楚 OPatch 到底怎么用、补丁打完怎么验证。下面我会从补丁包的识别、解压、环境检查、OPatch 升级、补丁应用、冲突排查一路讲到回滚和验证，把 Windows 平台上打 Oracle 补丁的完整链路拆开。中间会重点说几个我踩过的坑，比如 OPatch 版本不匹配导致补丁根本打不上、Windows 服务没停干净导致文件被占用、补丁目录层级搞错导致 OPatch 找不到补丁定义。

2. 补丁包结构拆解与 Windows 环境预检

2.1 解压 p33174380 之后你会看到什么

拿到p33174380_122010_MSWIN-x86-64.zip之后，不要急着往数据库服务器上扔。先在一个临时目录解压，看看里面的结构。Oracle 补丁包解压后通常长这样：

p33174380/ ├── 33174380/ │ ├── etc/ │ │ └── config/ │ │ └── action.xml │ ├── files/ │ │ └── oracle/ │ │ └── ...（实际替换的文件） │ ├── README.html │ └── custom/ │ ├── pre/ │ └── post/ └── ...

关键目录是33174380这一层，它才是 OPatch 真正识别的补丁目录。很多人解压完直接把p33174380整个目录丢给 OPatch，结果报 “Patch ID not found” 或者 “No patch found in the specified location”。原因是 OPatch 需要的是包含etc/config/action.xml的那一层，也就是33174380这个子目录。

我一般会这样做：在 D 盘建一个D:\oracle_patches\目录，把 zip 解压到D:\oracle_patches\p33174380\，然后确认D:\oracle_patches\p33174380\33174380\etc\config\action.xml这个文件存在。如果不存在，说明解压层级不对，或者下载的包不完整。

提示：Windows 自带解压工具对长路径支持不好，如果解压报错，用 7-Zip 或 WinRAR，并且把目标路径尽量缩短，比如D:\pat\。

2.2 打补丁前必须确认的四个环境参数

Oracle 补丁不是随便找个 12c 库就能打的。补丁编号和版本号必须严格对应，122010意味着这个补丁只适用于 12.2.0.1 版本。你可以在数据库里跑下面这条 SQL 确认版本：

-- 查看数据库版本，必须返回 12.2.0.1.0 才能用这个补丁 SELECT version_full FROM v$instance;

如果返回的是 12.1.0.2 或者 12.2.0.1 以外的版本，这个补丁打不上，强行打会报 “OPatch failed with error code 73” 之类的错误。

第二个要确认的是 OPatch 版本。Oracle 12.2.0.1 自带的 OPatch 通常是 12.2.0.1.12 或更早，而 p33174380 这类补丁往往要求 OPatch 版本不低于 12.2.0.1.36。检查命令：

# 在 Oracle 的 OPatch 目录下执行，Windows 上用 opatch.bat cd %ORACLE_HOME%\OPatch opatch version

如果版本低于补丁 README 里要求的版本，需要先下载对应版本的 OPatch 并替换。替换前把旧的 OPatch 目录改名备份，比如OPatch_old，然后把新的 OPatch 解压到%ORACLE_HOME%\OPatch。

第三个是%ORACLE_HOME%路径里不能有空格和中文。Windows 上很多人把 Oracle 装在C:\Program Files\...，OPatch 处理这种路径时容易出问题。如果已经装了，补丁阶段可能报 “The Oracle Home path contains spaces”，这时候要么忍，要么重装到C:\oracle\product\12.2.0\dbhome_1这种干净路径。

第四个是磁盘空间。补丁解压后加上 OPatch 备份，至少预留 10GB 以上。%ORACLE_HOME%\.patch_storage目录会存补丁元数据和备份文件，空间不够会在应用阶段失败。

2.3 停库停服务：Windows 上最容易翻车的一步

Windows 和 Linux 打补丁最大的区别在于服务管理。Linux 上shutdown immediate之后基本就干净了，Windows 上还有一堆 Oracle 服务在跑。如果服务没停干净，OPatch 替换文件时会报 “File in use” 或者 “Access denied”。

正确的停库顺序是：

# 1. 先停监听 lsnrctl stop # 2. 再关数据库实例 sqlplus / as sysdba SQL> shutdown immediate; SQL> exit; # 3. 停所有 Oracle 相关 Windows 服务 # 以管理员身份打开 cmd，执行： net stop OracleServiceORCL net stop OracleOraDB12Home1TNSListener net stop OracleOraDB12Home1MTSRecoveryService net stop OracleJobSchedulerORCL

服务名根据你的实例名和 Oracle Home 名称会有所不同，用net start | findstr Oracle可以列出所有 Oracle 服务。注意OracleRemExecServiceV2这个服务有时候也会占用文件，如果 OPatch 报文件占用，把它也停掉。

注意：停服务之前确认没有人在连这个库，否则shutdown immediate会等很久，甚至需要shutdown abort。生产环境务必走变更流程。

3. OPatch 升级与补丁应用：从命令到参数逐个说清

3.1 升级 OPatch 的正确姿势

OPatch 升级本身不复杂，但 Windows 上有两个细节容易忽略。第一，替换 OPatch 目录之前，先把当前 OPatch 版本记下来，万一新版本有问题可以回退。第二，新 OPatch 解压后，目录权限要确认oracle用户（或者你安装 Oracle 时用的系统账户）有完全控制权限。

操作步骤：

# 1. 备份旧 OPatch cd %ORACLE_HOME% move OPatch OPatch_old_20240101 # 2. 解压新 OPatch 到 %ORACLE_HOME%\OPatch # 假设新 OPatch 压缩包解压后是 OPatch 目录 # 直接复制过去 # 3. 验证版本 cd %ORACLE_HOME%\OPatch opatch version # 4. 检查 OPatch 是否能正常识别 Oracle Home opatch lsinventory

opatch lsinventory这条命令很关键。如果它报 “Oracle Home is not registered” 或者 “Inventory is corrupted”，说明 Central Inventory 有问题，补丁肯定打不上。正常输出会列出当前 Oracle Home 里已安装的所有组件和补丁。

3.2 补丁冲突检查：别跳过这一步

在真正 apply 之前，必须跑一次冲突检查。Oracle 的补丁之间可能有重叠文件，如果之前打过其他补丁，直接 apply 可能覆盖掉之前的修复。

# 进入补丁目录的上一层，也就是包含 33174380 子目录的那一层 cd D:\oracle_patches\p33174380 # 执行冲突检查 %ORACLE_HOME%\OPatch\opatch prereq CheckConflictAgainstOHWithDetail -ph .\33174380

参数说明：-ph后面跟的是补丁目录路径，这里指向33174380这个子目录，不是p33174380。如果输出里有 “Patch conflict” 字样，需要看具体是哪个补丁冲突，然后决定是先回滚旧补丁还是联系 Oracle 支持要合并补丁。

我遇到过一种情况：之前打过 p3xxxxxxx 补丁，和当前补丁共享同一个.class文件，冲突检查报错。解决办法是先回滚旧补丁，再打新补丁。回滚命令后面会讲。

3.3 apply 命令的完整参数与日志解读

冲突检查通过后，就可以 apply 了。Windows 上必须用管理员身份的 cmd，否则 OPatch 没有权限写%ORACLE_HOME%下的文件。

# 确保在补丁目录的上一层 cd D:\oracle_patches\p33174380 # 执行补丁应用 %ORACLE_HOME%\OPatch\opatch apply .\33174380 # 如果想指定日志位置和额外参数 %ORACLE_HOME%\OPatch\opatch apply .\33174380 -log D:\oracle_patches\apply_p33174380.log

opatch apply执行过程中会做几件事：检查 Oracle Home 状态、检查补丁完整性、备份将被替换的文件到.patch_storage、替换文件、执行 SQL 脚本（如果有）、更新 inventory。整个过程可能持续几分钟到十几分钟，取决于补丁大小和磁盘速度。

日志里重点看几个地方：开头会打印 OPatch 版本和 Oracle Home 路径；中间会列出每个被替换的文件；结尾会显示 “OPatch succeeded” 或者具体错误码。如果看到 “OPatch failed with error code 73”，通常是 Oracle Home 路径问题或者权限问题；“error code 74” 一般是 inventory 损坏；“error code 239” 是补丁和当前环境不匹配。

提示：apply 过程中不要中断，不要关 cmd 窗口。如果中途失败，先看日志最后 50 行，再决定是重试还是回滚。

3.4 补丁后的数据库启动与数据字典更新

补丁 apply 成功后，还没完。Oracle 补丁分两类：一类只替换二进制文件，另一类还需要更新数据字典。p33174380 这类补丁通常需要在启动数据库后执行datapatch。

# 1. 启动监听 lsnrctl start # 2. 启动数据库 sqlplus / as sysdba SQL> startup; SQL> exit; # 3. 执行 datapatch cd %ORACLE_HOME%\OPatch datapatch -verbose

datapatch会检查dba_registry_sqlpatch视图，找出需要应用的 SQL 补丁，然后逐个执行。执行过程中如果报 “ORA-04021: timeout occurred while waiting to lock object”，说明有会话在占用对象，需要先 kill 掉相关会话再重试。

执行完datapatch后，用下面这条 SQL 确认补丁状态：

-- 查看 SQL 补丁应用记录 SELECT patch_id, action, status, action_time FROM dba_registry_sqlpatch ORDER BY action_time DESC;

status应该是SUCCESS。如果是FAILED，需要看datapatch的日志，通常在%ORACLE_HOME%\cfgtoollogs\sqlpatch\目录下。

4. 避坑与排查：Windows 打 Oracle 补丁的五个血泪教训

4.1 现象：OPatch 报 “Cannot find patch 33174380”

原因：补丁目录层级不对。OPatch 需要的是包含etc/config/action.xml的那一层，而不是最外层的p33174380。

解决：cd到p33174380目录，确认33174380子目录存在，然后opatch apply .\33174380。如果还是找不到，检查33174380\etc\config\action.xml文件是否存在，不存在说明解压不完整，重新解压。

4.2 现象：apply 到一半报 “File in use” 或 “Access denied”

原因：Windows 上有 Oracle 服务或进程还在占用%ORACLE_HOME%下的文件。常见的是OracleRemExecServiceV2、OracleJobSchedulerORCL没停，或者有 sqlplus 会话没退出。

解决：用net start | findstr Oracle列出所有 Oracle 服务，逐个停掉。用任务管理器检查有没有sqlplus.exe、tnslsnr.exe、oracle.exe残留进程，有就结束掉。然后重新 apply。如果 apply 已经部分执行，先看日志确认哪些文件被替换了，必要时回滚重来。

4.3 现象：datapatch 执行时报 “ORA-04021: timeout occurred while waiting to lock object”

原因：数据库里有活动会话持有数据字典对象的锁，datapatch需要排他锁才能更新。

解决：先查v$session找到阻塞会话，kill 掉。如果生产环境不能随便 kill，可以在维护窗口执行，或者用datapatch -force跳过锁检查（不推荐，可能导致数据字典不一致）。

-- 查找阻塞 datapatch 的会话 SELECT sid, serial#, username, program, machine FROM v$session WHERE status = 'ACTIVE' AND username IS NOT NULL;

4.4 现象：补丁 apply 成功但数据库启动报 “ORA-01092: ORACLE instance terminated”

原因：补丁替换了二进制文件，但datapatch没跑，或者跑失败了，导致数据字典和二进制版本不一致。

解决：先看 alert log 确认具体错误。如果确实是 SQL 补丁没应用，用startup upgrade模式启动数据库，然后手动跑datapatch。

sqlplus / as sysdba SQL> startup upgrade; SQL> exit; datapatch -verbose sqlplus / as sysdba SQL> shutdown immediate; SQL> startup;

4.5 现象：想回滚补丁但 OPatch 报 “Patch is not applied”

原因：补丁 apply 后 inventory 没有正确更新，或者回滚时指定的补丁目录不对。

解决：先用opatch lsinventory -patch确认补丁是否在 inventory 里。如果在，回滚命令是：

cd D:\oracle_patches\p33174380 %ORACLE_HOME%\OPatch\opatch rollback -id 33174380

注意-id后面跟的是补丁编号，不是目录名。回滚后同样需要跑datapatch来撤销 SQL 变更。

5. 补丁验证与回滚演练：把后悔药提前准备好

补丁打完不是终点，验证和回滚预案才是。我一般会在补丁 apply 成功后做三件事：确认 inventory 记录、检查关键文件版本、跑一遍业务冒烟测试。

确认 inventory：

%ORACLE_HOME%\OPatch\opatch lsinventory -patch

输出里应该能看到Patch 33174380以及 apply 的时间。如果看不到，说明 inventory 没更新，需要检查%ORACLE_HOME%\inventory目录权限。

检查关键文件版本，比如oracle.exe的修改时间应该是补丁 apply 的时间：

dir %ORACLE_HOME%\bin\oracle.exe

回滚演练建议在测试环境先做一遍。回滚分两步：先opatch rollback -id 33174380，再datapatch。回滚前同样要停库停服务，回滚后启动数据库，确认dba_registry_sqlpatch里对应记录变成ROLLBACK或者消失。

最后说一个我自己的习惯：每次打补丁前，把%ORACLE_HOME%\OPatch目录、%ORACLE_HOME%\inventory目录、以及%ORACLE_HOME%\.patch_storage目录整个备份一份。这三个目录加起来可能几个 GB，但真出问题的时候，直接还原比重新装库快得多。Windows 上 Oracle 补丁的玄学主要就在文件占用和路径上，把这两点控制住，剩下的就是按步骤执行。希望帮到你。

本文还有配套的精品资源，点击获取