简介WebLogic Server 12.2.1.4 的补丁集更新PSU资源补丁编号 36805124版本标识 240704面向需要维护 Oracle WebLogic 环境的中间件运维、系统管理员与 DBA。该补丁包集中修复了此前历次 WLS PSU 中累计的安全漏洞与稳定性问题从 210330 到 240704 的补丁集更新问题清单均包含在内部署后可提升生产环境的健壮性也可作为升级或打补丁时的离线安装包。压缩包大小为 127.48MB共含 2000 个文件以 class 类文件、xml 与 properties 配置、jar 依赖包为主另有 html 帮助文档、java 源码及补丁校验相关文件符合 WLS 补丁包典型的目录结构与文件组成。对应 WebLogic 12.2.1.4 平台安装流程可参照补丁自带说明操作。该资源已有 201 人学习/下载适合需要批量维护 WebLogic 集群或安全合规要求较高的企业 IT 团队。将补丁与历次更新说明打包在一起既可用于离线实施也便于补丁追溯与审计省去从官方门户逐一下载的麻烦。1. 36805124 这批 PSU2024 年 7 月的 WebLogic 12.2.1.4 季度补丁WebLogic 用户被安全扫描逼到墙角的时候脑子里蹦出来的第一个词通常是打补丁。如果你手上跑的是 12.2.1.4.0那补丁号 36805124、版本号 12.2.1.4.0.240704 的 WLS PATCH SET UPDATE就是 Oracle 在 2024 年 7 月放出的季度 PSU。命名里的 240704 表示 2024 年 7 月 4 日的构建批次36805124 是 My Oracle Support 上对应的补丁号下载补丁时认准这个号就行。这套补丁解决的事情分两类一类是安全漏洞修复另一类是 12.2.1.4 累积下来的功能性缺陷。只要你的环境还是 12.2.1.4.0安全扫描基本都会提示版本过旧而合规整改最常见的做法就是把版本升到最新的季度 PSU。这里有个关键点PSU 是累积的你直接打 240704之前几个季度的修复会一并包含在内不需要把 1 月、4 月的补丁逐个补一遍这能省下大量窗口时间。1.1 CPU、PSU、Bundle Patch 三个概念先理清Oracle 每年 1 月、4 月、7 月、10 月发 Critical Patch Update简称 CPU覆盖整个产品线的安全修复。WebLogic 的季度更新有两种主要形态PSUPatch Set Update和 Bundle Patch简称 BP。对 12.2.1.4 来说PSU 是推荐默认项它对标准功能和认证组合的影响最小是大多数企业保守升级的路径。Bundle Patch 包含的修复范围更广但同时变更风险也更高一般不是首选。我见过有同事一开始分不清这两个概念直接在 MOS 上搜WebLogic latest patch结果下载了 Bundle Patch 打到生产环境后面跟厂商兼容性认证对不上又灰溜溜回滚。所以记住一条经验没有特殊需求12.2.1.4 就选带 WLS PATCH SET UPDATE 字样的补丁也就是 36805124 这种。它对应的是当前季度 CPU 的安全修复再加上上一季度之后累积的缺陷修复覆盖面足够日常使用。1.2 为什么 240704 这一批不能拖WebLogic 历史上出过不少反序列化相关的安全漏洞攻击面集中在 T3、IIOP 协议上。安全扫描工具对 12.2.1.4 的老版本基本一扫一个准而且漏洞细节在公开渠道都能查到这意味着攻击者也在盯着同一份公告。打 PSU 不只是为了过扫描而是真正把这个攻击面堵上。另一个容易被忽略的点是Oracle 对旧 PSU 是滚动式淘汰的你拖得越久下一次升级跨度越大Readme 里的前置条件可能从 OPatch 13.9.4.2.5 一路跳到 13.9.4.2.6跨多个版本出问题的概率会成倍增加。所以我的建议很直接只要是 12.2.1.4.0 或更早版本的环境尽早定一个维护窗口把 240704 打上去同时顺手把 OPatch 工具也升到 Readme 要求的版本。下面这些步骤都是我在生产环境实际跑过的流程照着做基本不会翻车。2. 准备阶段Readme 没读完之前不要 opatch apply很多事故不是补丁本身的问题而是准备阶段偷懒。opatch apply 本身是成熟工具但它对环境的假设非常多ORACLE_HOME 不对、JAVA_HOME 不一致、磁盘空间不够都会在中途报一堆让人看不懂的错。准备阶段花半小时能省下事后两小时的排障时间。2.1 先确认补丁包和 OPatch 版本把补丁 36805124 的压缩包解压后先找到 README.txt 打开看。Readme 里除了操作步骤最要命的是环境要求里面会写明本补丁要求的 OPatch 最低版本、JDK 版本、还有哪些前置补丁。以 240704 这批 PSU 为例Readme 一般要求 OPatch 13.9.4.2.6 及以上JDK 使用 1.8。注意这里的 JDK 版本是认证版本不是随便一个 1.8 就行最好和你 WebLogic 安装时用的 JDK 保持一致。检查当前环境的 OPatch 版本$ORACLE_HOME/OPatch/opatch version如果版本低于要求先去 MOS 下载对应版本的 OPatch 工具包解压后替换$ORACLE_HOME/OPatch目录。替换前先备份原目录这个操作看似简单但万一你下载错了版本或者解压时覆盖了不该覆盖的文件后面所有 opatch 命令都会直接罢工。我习惯在替换后立刻再跑一次opatch version确认新版本生效了再继续。2.2 备份不是可选项是止损线打过补丁的人都知道opatch apply 失败最常见的后果不是补丁没打上而是中途报错后环境处于半更新状态最坏情况下 WebLogic 起不来这时候就只能靠备份恢复。所以备份不能只停留在口头上。我的备份顺序是停掉所有 WebLogic 相关进程AdminServer、ManagedServer、NodeManager停掉后对 Middleware 主目录做整体压缩备份tar -czf mw_home_$(date %Y%m%d).tar.gz MW_HOME对 Domain 目录单独备份特别要覆盖config、bin、security这几个子目录如果是虚拟机环境有条件就再做一次快照有些生产环境 MW_HOME 很大整体打包耗时太久那至少要把补丁会改动的OPatch、wlserver、oracle_common这几个目录备份出来。但我不太推荐这种精简备份因为补丁实际影响的文件范围你很难完全预测出问题时你就知道整包备份有多香了。备份文件建议放到 MW_HOME 之外的位置避免同一块磁盘故障一起带走。2.3 环境变量与执行用户最容易被忽视的坑opatch 对运行用户要求很严格Oracle 官方建议用安装 WebLogic 时的系统用户执行不要用 root否则可能因为文件属主混乱导致后续启动异常。执行前先确认env | grep -E ORACLE_HOME|JAVA_HOME which java java -version这里有个非常经典的坑JAVA_HOME 指向了系统自带的 OpenJDK而不是 WebLogic 认证的 JDK 1.8。opatch 脚本调用的是$JAVA_HOME/bin/java版本不匹配会直接报 UnsupportedClassVersionError看起来像是环境坏了其实是 PATH 和 JAVA_HOME 不一致。我的习惯是在执行补丁的会话里把 JAVA_HOME 显式 export 一遍不要依赖全局 profile 里的值。3. 正式执行从预检到 apply 完成的完整链路准备做扎实以后执行阶段反而简单但每一步都不能跳。opatch 虽然自动化程度高可它不会帮你判断现在停服务了没有备份做了没这些前置条件全得自己保证。3.1 停服务和预检补丁更新期间必须保证没有 WebLogic 进程在运行否则文件占用会导致更新失败。停服务之前先记录各服务的启动顺序和必要参数方便之后恢复。ps -ef | grep -i weblogic确认没有残留进程后进入补丁解压目录先做预检cd patch_dir/36805124 $ORACLE_HOME/OPatch/opatch prereq CheckApplicable -phBaseDir .预检通过后就可以正式应用$ORACLE_HOME/OPatch/opatch apply这时 opatch 会先做一系列检查然后列出将要更新的文件清单询问是否继续。确认后就开始复制 jar、class 文件并更新 inventory。整个过程中日志会打印 ApplySession 的字样持续几分钟到十几分钟不等取决于机器性能和环境大小。我见过有人在 apply 过程中按 CtrlC这是大忌。OPatch 的 ApplySession 不是事务性的中断后需要重新执行 opatch apply 来恢复而不是直接放弃。万一遇到这种情况先看日志再重新跑一遍多数情况能续上。如果重新跑还失败那就进入排障流程别硬试。3.2 apply 报错的几种典型场景报错特征常见原因处理方式OPatch 找不到 Oracle HomeORACLE_HOME 未设置或设置了多个确认环境变量后重新执行提示补丁与当前版本不匹配基础版本不是 12.2.1.4.0检查 lsinventory确认当前版本ApplySession 中途失败磁盘空间不足、文件权限问题df -h检查空间chown 确认属主依赖的前置补丁缺失缺了 Readme 中要求的前置条件逐个安装前置补丁后重试遇到报错不要慌先看$ORACLE_HOME/cfgtoollogs/opatch/下的日志里面会写明具体失败的步骤。opatch 的报错信息有时候很抽象但日志里通常会提供足够线索比如哪个文件无法写入、哪个 jar 被占用。还有一种情况是补丁本身没问题但你之前手动改过$ORACLE_HOME下的文件导致校验不一致这种只能对比原始文件恢复后重试。3.3 验证补丁是否真的生效apply 完成后第一件事是用 inventory 确认$ORACLE_HOME/OPatch/opatch lsinventory | grep 36805124能看到补丁记录说明 inventory 已经更新。如果想看更详细的信息可以加-detail参数。但注意inventory 记录了不代表运行时真的用了新版本还需要启动 WebLogic 验证。启动日志里会输出当前 WebLogic 版本信息类似weblogic.utils.Version: WebLogic Server 12.2.1.4.0.240704这种行。如果这里显示的还是 12.2.1.4.0那说明补丁没有完整加载需要回滚后重新排查。4. 补丁打上只是开始重启验证和域里的暗坑补丁能 apply 成功只能说明文件层面更新完成了真正的考验在重启。我见过太多打补丁半小时重启后排查一整天的案例问题基本都出在缓存、脚本、组件版本不一致这几个地方。4.1 正确的启动顺序补丁打完后启动顺序建议按 NodeManager、AdminServer、ManagedServer 来。每个组件启动后都等它完全进入 RUNNING 状态再启动下一个避免连接报错干扰判断。启动 AdminServer 时用nohup或startWebLogic.sh日志文件重点看有没有异常堆栈。启动完以后检查几个地方AdminServer 日志中没有新的 Exception、Error管理控制台能正常打开登录后版本信息显示 12.2.1.4.0.240704数据源、JMS 等资源能正常连接应用能正常访问跑一轮核心业务流程这些看起来基础但很多人补丁一打完就急着收工第二天业务上来报故障才发现问题。补丁窗口最好预留出观察期让业务同事配合做一轮冒烟测试别把验证压缩到只剩能开机。4.2 我实际踩过的两个后遗症第一个是缓存残留。WebLogic 运行一段时间后servers/Server名/cache目录下会有缓存的类文件。补丁更新了 jar 里的类但缓存里还是旧类结果启动后出现奇怪的 ClassNotFoundException 或者方法不存在。遇到这种问题在确认补丁没问题的情况下把对应 Server 的 cache、tmp 目录清理后再启动多半就能解决。清理前先确认当前 Server 已停止不然文件被占用删不掉。第二个是自定义脚本里的 CLASSPATH。有些环境用自定义脚本启动服务脚本里手工指定了一堆 jar 路径补丁更新后这些 jar 的版本可能已经变化但脚本路径还是旧版本。启动日志里明明显示新版本应用却还在用旧 jar这种问题排查起来最费时间。所以补丁窗口最好把自定义启停脚本也一起 review 一遍确认没有硬编码旧 jar 路径。4.3 NodeManager 版本不匹配的注意点如果环境里 AdminServer 和 NodeManager 是分开维护的打补丁时最好把整个 MW_HOME 下的组件一起更新。只更新管理节点不更新受管节点的 NodeManager 版本可能出现 NodeManager 无法管理该节点的现象。虽然 12.2.1.4 内部版本兼容性做得不错但为了减少变量所有节点的补丁尽量安排在同一窗口内完成。跨节点更新时先全部更新完、再统一重启比一个一个节点轮换更可控。5. 回滚与彻底卸载补丁级的回滚和 WebLogic 级的卸载补丁这件事永远要给自己留后路。后路分两层一层是单个补丁的回滚另一层是整个 WebLogic 的卸载。这两者的操作路径完全不同别搞混。5.1 用 opatch rollback 回滚单个补丁万一补丁导致严重问题或者和业务兼容性冲突回滚操作必须熟练。回滚单个 PSU 用$ORACLE_HOME/OPatch/opatch rollback -id 36805124回滚前同样需要停止 WebLogic 服务。这里有一个顺序问题要注意如果补丁之后你又打了其他补丁回滚要从最新的开始逆序进行否则 inventory 状态会乱。回滚完成后也要执行opatch lsinventory确认补丁已移除再启动服务验证版本回到原样。我建议在补丁窗口当天保留回滚能力也就是说至少保留补丁前的备份直到新版本稳定运行一段时间。我的经验是至少观察 3 到 7 天再清理备份避免打补丁没问题、跑了三天业务才暴露问题的尴尬局面。备份清理前最好和业务负责人确认一下别单方面决定。5.2 热词常搜的weblogic卸载到底怎么卸干净最近看到不少人在搜 weblogic 卸载这通常发生在两种场景一是老环境要腾出来给新版本二是要迁移到别的中间件。补丁回滚和完整卸载是两码事卸载涉及的是整个 WebLogic 安装不只是某个补丁。WebLogic 12c 之后的版本自带卸载工具一般在$ORACLE_HOME/oui/bin/uninstall。你可以用图形界面模式运行也可以找一下有没有响应文件支持静默卸载。但实际经验是这个卸载工具卸载得并不彻底典型残留包括$MW_HOME下的 cfgtoollogs、logs、patch_wls 等目录Domain 目录如果 Domain 独立于 MW_HOME 就更明显环境变量、启动脚本里遗留的引用系统服务自启动项如果配置了 systemd 或 init 脚本所以我给的建议是卸载工具跑完只是第一步手工再清理一遍重点看ps -ef | grep weblogic有没有残留进程再用find查有没有遗留的 Domain 和日志目录。如果是迁移场景干脆把旧主机整机退役比任何卸载都干净。如果是想保留数据做升级测试那卸载前先确认 Domain 和应用的备份别急着删。还有一点如果只是想清理旧补丁而不是卸载整个 WebLogic那用不到 uninstall走opatch rollback就对了。这两个命令的使用场景要分清我在实际工作中见过同事把卸载工具当成回滚工具用结果环境整个被拆掉幸好当时是测试环境。按照我的节奏一年四个 CPU 窗口每个季度花半天时间把补丁打上、验证一遍比攒一年再一次性升级省心得多。补丁这件事最贵的永远不是执行那几十分钟而是准备不充分导致的回滚和返工。希望这篇能帮你少走点弯路。本文还有配套的精品资源点击获取