WebLogic 12.2.1.4 PSU 36805124 安装实战与回滚指南
简介：一份面向WebLogic服务器运维与中间件管理人员的补丁集更新资源包，对应WebLogic 12.2.1.4.240704版本，补丁标识为36805124，用于修复该版本运行中暴露的已知缺陷，适合在生产环境升级前进行缺陷评估和补丁验证。压缩包内共两千个文件，主要包含编译后的class类文件、java源文件、xml与properties配置、jar依赖库，以及html说明文档、jsp页面、sql脚本、cmd命令等辅助内容，整体大小约为一百二十七点四八兆字节，目录按补丁模块组织，便于快速定位与提取。该资源已有二百零一人学习下载。补丁包不仅列出本次更新修复的错误，还汇总了自二零二一年九月三十日至二零二四年三月二十五日多个历史补丁集更新解决的问题，覆盖安全管理、核心域、部署工具、集群类型等WebLogic常用组件，帮助使用者了解各版本的缺陷修复轨迹，评估升级影响范围，制定更稳妥的实施与回退方案。 WebLogic 这个东西，很多年纪轻一点的开发可能都没怎么碰过了，但它在企业级 Java 应用里头的地位，扛过了二十年，现在依然是不少银行、保险、电信系统的底座。我最近刚给一套 12.2.1.4 的生产环境打了最新的 2024 年 7 月季度补丁，就是标题里这个WLS PATCH SET UPDATE 36805124。整个过程踩了几个不算深但很烦的坑，顺手整理成一篇实操笔记，希望能帮到正在准备动补丁或者被安全合规追着整改的同行。
这篇笔记的重点不是把命令贴一遍完事，而是把补丁安装的思路、为什么这么做、哪些步骤最好别省、出了问题怎么退回去，全部讲清楚。后面要装的这个补丁，Oracle 官网的补丁号是36805124，对应的 WebLogic 版本标识是12.2.1.4.240704，属于季度性的大补丁包（PSU）。它能修掉一批安全漏洞和稳定性问题，同时也会更新 WebLogic Server 里 WLS Core、JRockit、Coherence 等若干组件的版本信息。
1. 先搞清楚要装的是什么：PSU 和普通补丁的差别
1.1 版本号到底怎么读
官方给出的完整版本写法是12.2.1.4.240704。拆开看，12.2.1.4是 WebLogic 的主版本，表示这是 12c R2 这个大版本线的第四个补丁维护版本。后面的240704是日期标识，意思是这个补丁集对应的是2024 年 7 月 4 日发布的季度更新。
Oracle 对 WebLogic 的补丁发布频率是固定的，每年 1 月、4 月、7 月、10 月都会出一个大的 PSU 补丁包，同时也会发单独的 CPU（Critical Patch Update）公告。像24代表 2024 年，07代表 7 月，04代表公告发布日的第 4 天。这套日期规则基本通用，看到任何类似的四段式版本号，都能按这个思路解码。
1.2 CPU、PSU、SPU 到底有什么区别
很多刚接触 WebLogic 的人会被 CPU、PSU、SPU 这些缩写绕晕。我用最简单的话总结一下：
- CPU（Critical Patch Update）：Oracle 每个季度发布的紧急安全补丁集合，重点修安全漏洞，不包含非安全性的功能修复。
- PSU（Patch Set Update）：在 CPU 基础上增加了部分经过充分验证的稳定性和功能性修复，属于“安全加稳定”的合订本。一般建议生产环境优先选择 PSU。
- SPU（Security Patch Update）：早期叫法，某种程度上和 CPU 类似，现在已经逐渐被 CPU 的叫法取代。
- One-off Patch（单点补丁）：针对某个具体 Bug 打的小补丁，应用范围窄，不能替代 PSU。
这次要装的 36805124 就是一个PSU，意味着里面既包含了当季的安全漏洞修复，也附带了一些已修复的稳定性问题。对运维来说，打一个 PSU 比挨个安装多个单点补丁更省事，也不会因为补丁之间互相覆盖而产生冲突。
1.3 为什么不能跳过低版本补丁直接装最新的
曾有同事问我：既然 2024 年 7 月有 PSU，那我直接从没打过补丁的原版 12.2.1.4 跳到最新不行吗？
理论上 Oracle 允许你直接应用最新的 PSU，因为补丁包本身是累积的——也就是最新 PSU 已经包含了之前所有 PSU 的内容。但实际操作里，我不建议生产环境这么做。原因是：
- 中间长时间没打补丁，意味着 WebLogic 版本跨度大，升级过程中可能连带触发一些本来可以通过中间版本平滑过渡的兼容性问题。
- 很多组件（比如 JDK、Coherence）的 patch bundle 会随着 PSU 更新，跳过中间版本可能会导致某些应用的自定义证书、加密配置出现意外不兼容。
- 遇到问题时，Oracle Support 大概率会要求你先验证中间版本的日志记录，排查链条会特别长。
所以我的建议是：生产环境至少保持每季度跟一次补丁，别拖太久。如果确实已经落后很多版本，至少先在测试环境完整走一遍应用兼容性验证，再带着充分的心理准备和回滚方案上生产。
2. 打补丁之前的准备工作，比执行补丁本身更重要
2.1 先确认当前环境：版本、架构、补丁现状
开始之前，用下面这组命令快速体检环境：
# 查看当前 WebLogic 版本 cd $MW_HOME cat registry.xml | grep -i "WebLogic Server" # 查看已经安装的补丁 $MW_HOME/OPatch/opatch lsinventory重点关注输出里的Patch Level和Installed Top-level Patches列表。如果这里已经存在某条带234449、32922663之类编号的补丁记录，说明环境之前维护得还算及时；如果显示一大串 One-off Patch，或者干脆是空列表，就要格外留意后续的冲突检查。
另外，看清楚当前用的是 JRockit 还是 HotSpot JDK，WebLogic 12.2.1.4 对 JDK 版本有明确要求。新 PSU 一般要求 JDK 8u 至少到某个小版本，顺序错了会导致补丁应用后启动直接报UnsupportedClassVersionError。
2.2 补丁兼容性检查清单
去 Oracle Support 下载补丁时，页面会提供一份Readme文件，建议下载后先读，再动手。Readme 里最关键的信息包括：
- 补丁对应的最低 OPatch 版本要求。
- 是否要求必须安装某个前置补丁（比如某个特定的 Coherence 补丁）。
- 补丁安装后是否要求重新编译 stub（
rm -rf $DOMAIN_HOME/servers/*/tmp）。 - 补丁是否影响 WLST 脚本、数据源、JMS 等常用功能。
我习惯把 Readme 里提到的要求整理成一张清单，挨个核对。这里分享一个比较通用的检查表：
| 检查项 | 操作命令 / 判断标准 | 是否达标 |
|---|---|---|
| 当前 WebLogic 版本 | cat $MW_HOME/registry.xml | 12.2.1.4.x |
| OPatch 版本 | opatch version | 不低于 13.9.4.2.x |
| JDK 版本 | java -version | 1.8.0_xxx（按 Readme 要求） |
| 已装补丁列表 | opatch lsinventory | 记录当前状态 |
| 空间检查 | df -h /u01或系统盘 | 至少预留 5GB 以上 |
| 域目录备份 | tar czf | 完整备份 1 份 |
| 中间件安装目录备份 | tar czf | 有条件就备份 |
| 配置库（config.xml）备份 | 使用 WLST 导出 | 保留 1 份 |
提示：不要忽略 OPatch 版本要求。很多次补丁安装失败的原因，就是 OPatch 版本太低，
opatch apply会直接报错并中止。如果 Readme 要求 OPatch 13.9.4.2 以上，而系统还是 13.8，先单独升级 OPatch，再跑补丁。
2.3 备份的粒度要细，后悔药要备足
很多运维打补丁最怕的就是出了问题没退路，所以备份这一步千万别省。我个人推荐的备份方案是：
- 中间件安装目录（MW_HOME）整体备份：如果环境允许，直接把整个 WebLogic 安装目录打包，虽然大，但最稳。
- Domain 目录完整备份：包括
config、bin、lib、servers、security这些关键子目录。Domain 是业务核心，必须单独备份。 - 配置导出：用 WLST 连接 AdminServer，执行
export命令把当前配置导出为 XML 文件。这样就算回滚后配置异常，也能快速对比找回。
实际生产里，大部分企业会采用“介质备份 + 虚拟化快照”双保险。打完补丁再重启域，万一启动失败，虚拟化快照可以直接回滚到补丁前的状态，比解压缩 tar 包快得多。
2.4 停机窗口和变更步骤的评估
PSU 补丁的核心步骤是替换中间件安装目录下的 jar 包、注册表、组件配置，所以打完补丁后，整个域的实例都必须重启。特别要注意的是，如果环境里有多个 AdminServer（比如集群 + 多机部署），所有机器上的 WebLogic 安装目录都要打同样的补丁，且必须保证所有 AdminServer 和 ManagedServer 的补丁版本一致，否则集群节点之间可能因为二进制版本不一致出现异常。
所以，打补丁前一定要和业务方确认好停机窗口。一般来说，先打一个非核心测试机、把完整流程和启动验证做完，再造一个灰度环境，最后才是生产环境。这个顺序我建议固定下来，别嫌麻烦。
3. 补丁安装实操流程：从停服到验证
3.1 停掉服务和所有实例
这一步听着简单，但实际操作中有几个坑：
- 不要只停 AdminServer，ManagedServer 也要全部停掉。
- 如果使用了 NodeManager 守护进程，建议先把 NodeManager 也停掉，避免它自动拉起实例。
- 停服务前先记录一下当前 WLS 版本，方便之后核对是否变更成功。
停服务的方式推荐用域目录下的stopWebLogic.sh（Linux）或stopWebLogic.cmd（Windows），不要直接 kill 进程，除非已经出现无法正常停止的情况。直接 kill 会留下持久化文件和配置锁，后续启动时容易出现“Invalid state”之类的问题。
# 示例：进入域目录停止 AdminServer cd $DOMAIN_HOME/bin ./stopWebLogic.sh # 等 AdminServer 完全停止后，可以再确认进程是否存在 ps -ef | grep weblogic注意：如果当前环境是集群，建议逐个节点停止，并确认每个节点的
ServerState变为SHUTDOWN，再继续下一步。
3.2 解压补丁包并执行 opatch apply
补丁包下载好之后，通常是一个 zip 文件，如下：
unzip p36805124_122140_Generic.zip -d /u01/patch_dir cd /u01/patch_dir/36805124开始执行前，再次确认 OPatch 版本满足要求。然后执行：
$MW_HOME/OPatch/opatch apply这个命令会检查当前环境、比对补丁兼容性，如果一切正常会打印出待应用的补丁列表，并要求你输入y确认。
看到Applying patch...之后，系统会花几分钟到十几分钟时间做文件替换和注册表更新。期间千万不要中断，否则容易造成补丁目录信息不一致。可以同时看日志文件，比如：
tail -f $MW_HOME/cfgtoollogs/opatch/opatch2024-07-04_XXX.log安装完成后，如果输出包含：
OPatch succeeded.说明 apply 成功。如果中途报错，别慌，看错误类型，多数是 OPatch 版本不支持，或者缺前置补丁，按 Readme 的要求补齐再重新跑即可。
3.3 确认补丁登记状态
打完补丁后，用opatch lsinventory再查一遍，确认补丁编号 36805124 已经出现在已安装列表里。
$MW_HOME/OPatch/opatch lsinventory | grep 36805124同时也得确认版本号变成12.2.1.4.240704：
cat $MW_HOME/registry.xml | grep "12.2.1.4"如果这里能看到12.2.1.4.240704，说明补丁已经成功写入了注册表。注意，这一步只能说明补丁装上了，不代表服务能正常启动。
3.4 启动 AdminServer 和 ManagedServer 并验证业务
启动顺序一定是先 AdminServer，再 ManagedServer。别问为什么，问就是 WebLogic 的启动依赖集群配置和域配置，AdminServer 没起来，ManagedServer 即使起来了也是待定状态。
cd $DOMAIN_HOME/bin nohup ./startWebLogic.sh > /tmp/wls_admin.log 2>&1 &等 AdminServer 日志输出类似Server state changed to RUNNING时，再启动 ManagedServer。启动完成后，重点检查以下几点：
- 数据源是否能正常连接数据库，尤其是使用了 JDBC 数据源的应用，补丁更新后有时 JDBC 驱动会变。
- JMS 消息队列是否正常，持久化消息有没有丢失。
- 应用部署状态是不是
Active。 - 登录 Web Console，确认各服务器的健康状态是
OK。
如果这些都没问题，基本可以宣布补丁安装成功。
4. 补丁验证的细节和回滚的正确姿势
4.1 验证不只是看版本号
很多运维在补丁打完，看到版本号对了就认为任务完成。但补丁影响的是运行时行为，版本号只能说明文件被替换了，不代表应用还是好的。我习惯做一轮“业务冒烟测试”，包括：
- 使用测试账号走一遍核心业务接口（登录、查询、提交）。
- 检查关键日志，确认没有新增的 ERROR 或 WARN。特别是和 Coherence、事务、数据源相关的报错。
- 对比补丁前的日志基线，看看有没有新增异常堆栈。
- 如果是安全补丁，可以顺便确认一下公告里提到的 CVE 编号是否在环境里已经消失（比如某些校验逻辑不再触发）。
安全团队如果催得紧，可以在验证完功能后，按 Oracle 公告里的漏洞列表对照一遍系统输出的启动日志和扫描结果。不过要注意：不是所有 CVE 修复都能在运行日志里直接体现，很多是静态扫描或版本识别层面的变化，判“已修复”最直接的证据是补丁安装记录和版本号变了。
4.2 回滚补丁的正确打开方式
补丁出问题后，回滚的关键是找到正确的回滚顺序。假设你在这次变更中只打了一个 PSU，那么回滚命令很简单：
$MW_HOME/OPatch/opatch rollback -id 36805124但如果环境之前装过多个补丁，且存在依赖关系，回滚顺序就需要反过来。例如先装了 A 补丁，再装了 B 补丁，此时回滚要先回滚 B，再回滚 A，不能直接回滚 A，否则 B 的文件可能已经不完整。
回滚完成后，同样要执行：
$MW_HOME/OPatch/opatch lsinventory确认 36805124 已经从列表中移除。接着重启服务，做一遍和打补丁时一样的冒烟验证。这里我的实战经验是：回滚后的验证，至少要做到重启一次域并且跑通关键业务，而不是只确认版本号变了就完事。因为回滚后文件版本降回去了，某些新配置可能没有跟着消失，容易造成“半新半旧”的混合状态。
4.3 回滚后出现异常怎么兜底
回滚后最常见的异常是启动失败，报错通常是某个类找不到，或者 ClassCastException。这种问题的根因一般是回滚时只替换了 jar 包，但配置缓存或部署临时文件里还残留新版本的内容。解决方式：
- 清理 Domain 下
servers/*/tmp和servers/*/cache目录。 - 用备份的 Domain 目录覆盖回滚后的状态。
- 如果还不行，用引入的虚拟化快照恢复。
我自己遇到过一次特别蹊跷的情况：回滚之后opatch lsinventory显示补丁已经移除，但应用启动时依然调用新补丁里的某个类。查了半天，发现是 OSGi 缓存和部署计划缓存没有被清掉。把servers/*/data/nodemanager下的缓存文件也删掉之后，问题解决。
5. 实战问题排查与安全合规建议
5.1 OPatch 版本过低导致的 apply 失败
现象：执行opatch apply报错OPatch version is lower than required。
原因：PSU 补丁要求至少某个 OPatch 版本，老环境的 OPatch 一般都不达标。
解决：去 Oracle Support 下载最新 OPatch，先升级 OPatch，再重新执行 apply。
cd /u01/opatch_upgrade unzip p6880880_*.zip cp -r OPatch/* $MW_HOME/OPatch/这里额外提醒一句：升级 OPatch 前最好备份旧 OPatch，因为部分小版本可能存在兼容性差异，升级后某些老补丁的 rollback 可能受影响。
5.2 补丁冲突（Conflict）
现象：opatch apply提示Patch ... conflicts with another patch，然后中止。
原因：当前环境里已有一个 One-off Patch 和 PSU 修改了同一个文件，或者你之前手动替换过某个 jar。
解决：先用opatch lsinventory -detail查看冲突补丁的编号和内容，再决定是先把旧补丁回滚掉，还是升级到覆盖冲突的补丁版本。遇到这种情形，我建议先对照 Readme 确认冲突补丁是否是本 PSU 的前置补丁；如果是，直接回滚掉旧的即可。
5.3 域模式下启动卡住或节点同步失败
补丁更新后，如果集群有多台机器，且节点同步开启了“自动同步”，AdminServer 会把二进制变更下发到 ManagedServer 节点。但有些机器的bin/startManagedWebLogic.sh里写死了启动路径，导致同步失败。
排查：查看 ManagedServer 日志，如果出现Downloading new binary...后面跟着SocketException或IOException，多半是网络或权限问题。这台机器上的中间件安装目录需要手动打同一个补丁，或者检查mw_home路径配置。一般业务环境不建议依赖自动同步来批量推送补丁，手动逐台打，稳得多。
5.4 安全加固检查与审计项
打完补丁后，安全团队的审计通常需要你提供这样几项材料：
- 补丁编号和日期描述（36805124，2024-07-04）。
- 补丁应用前后的版本截图。
- 补丁回滚预案的文档。
- 所有节点的补丁状态确认（最好导出
opatch lsinventory的结果存档）。
如果单位有定期例行的安全扫描，建议扫描前先在测试环境验证补丁确实覆盖了扫描器认为存在的 CVE。这里容易踩的坑是：扫描器靠的是版本识别和端口响应指纹，而不是文件比对，所以哪怕打上了最新 PSU，扫描报告里可能依然显示旧指纹。这种情况得和扫描团队解释版本号需要以应用层的输出为准，或者由扫描工具进行深度匹配。
最后分享一点我的个人体会
WebLogic 补丁安装，技术本身并不复杂，但真正让人头疼的是变更管理和环境差异。我从一开始觉得“打个补丁就是把命令敲一遍”，到后来养成“每次变更前都写一份带验证步骤和回滚步骤的执行方案”，心态和效率都提高了很多。
经验一：把 OPatch 和补丁包备份成本地离线源。
很多企业生产环境不能直连外网，临时下载补丁往往要等审批。我在服务器上保留了一个patch_repo目录，每次下载完补丁和解压工具都会归档，标注日期和版本。这样下个季度再打补丁时，不需要重新找文件，也方便追溯。
经验二：记录每个环境的具体变更时间、操作人和结果。
别小看这个动作。出了问题时，能快速判断某次补丁变更是否是故障源头。我习惯用一张表格记录：环境、日期、补丁号、打补丁前后的版本、执行人、验证结果。将来做隐患回溯时，这张表价值巨大。
经验三：对生产环境，永远不要用“试试看”的心态来打补丁。
每一条命令，每一个参数，都应该先在测试环境验证过。我在这次 36805124 的升级里，先在测试机完整跑了一遍，确认无异常后才在生产执行。整个过程耗时 40 分钟，但面对生产时心里有底得多。
如果后续你也在准备给 WebLogic 打 PSU，我的建议很简单：把这篇笔记里的准备清单、执行步骤和验证方法当成模板，套到你的环境里跑一遍，大多数常规问题都能提前规避。补丁这种东西，只要流程规范、备份到位、验证充分，它就只是一个普通的日常变更；反过来，流程草率，再小的补丁也能让你熬夜到天亮。
本文还有配套的精品资源，点击获取