WebLogic补丁安装实战：从识别补丁编号到OPatch排错

简介这是面向WebLogic Server 12.1.3版本的通用补丁包主要用于修复该版本中的已知问题提升服务器运行的安全性与稳定性同时为后续补丁的安装提供必要的前置条件适合负责企业级Java应用运维与中间件管理的技术人员。压缩包体积仅917KB共包含5个文件其中3个为xml配置文件另有补丁目录与readme说明文档结构紧凑、定位清晰。目前已有276人学习下载。通过查看包内的xml与readme内容可以了解补丁的元数据、依赖关系及安装注意事项结合补丁目录中的文件运维人员可配合WLST脚本执行静默安装并使用opatch lsinventory命令验证补丁生效情况对于规范WebLogic补丁管理流程具有较强的实践参考价值。 第一次见到weblogic补丁 p33385024_121300_Generic.zip这个文件名的朋友十有八九会卡在同一件事上这串字符到底在说什么我该把它解压到哪里我的 weblogic 明明是 12.1.3为什么安装补丁的时候不是报版本不匹配就是报 OPatch 版本太旧这些困惑我都经历过而且是在一台跑了好几年的生产环境上当时安全审计要求必须补齐补丁整个窗口期只有两个小时。这篇文章不打算写成一页页的操作手册而是把我处理这个补丁包的全过程拆开讲文件名怎么读、安装前要核对什么、opatch apply的标准落地流程是什么、哪些坑是你大概率会踩的以及踩了之后怎么收场。适合正在给 weblogic 12.1.3 打补丁的运维和 DBA也适合第一次接触 Oracle 补丁机制、对“补丁依赖”没什么概念的开发同学。1. 先看懂文件名p33385024_121300_Generic.zip 到底在说什么1.1 三个关键字段补丁号、版本号、平台标识我们先把这个文件名拆开看。p33385024_121300_Generic.zip里藏着三块信息你只要看懂了它就不会再出现“下载了补丁却不知道该不该装”的尴尬。p33385024是 Oracle 的补丁编号它对应一个具体的补丁内容通常会伴随着 Oracle 关键补丁更新Critical Patch Update简称 CPU一起发布。你可以把它当成这个补丁的身份证号。121300表示这个补丁适用的 WebLogic Server 版本是12.1.3.0.0不是 12.2.1.3也不是 11g。这里就出现了一个非常常见的误区很多环境里跑的是 12.1.3但下载页面眼花缭乱一不小心就下成了 12.2.1.3 的安装包。别看两者都是 12 开头它们是完全不同的版本分支补丁不能混用。Generic表示这是一个通用平台补丁包理论上适用于 Linux x86_64、Windows、Solaris 等主流平台不区分 CPU 架构。Oracle 偶尔也会出平台专用的补丁包比如文件名里带Linux-x86-64或Solaris的那种就必须严格匹配操作系统。所以在解压任何补丁之前第一件事永远是确认当前环境里的 weblogic 版本。命令很简单在$ORACLE_HOME环境变量配置好的前提下执行java -cp $ORACLE_HOME/server/lib/weblogic.jar weblogic.version输出里会有WebLogic Server 12.1.3.0.0之类的版本行。对不上 121300 的就说明这个补丁不是给你这套环境用的直接停止不要心存侥幸。1.2 通用包的适用范围Generic 不等于无脑安装有些朋友看到 Generic 就以为“平台无关随便装”这个理解不完全对。补丁内容本身是通用的但安装工具、执行脚本和后续验证方式在不同操作系统上是有差异的。举个例子Linux 和 Unix 上执行的是OPatch/opatchWindows 上则是OPatch/opatch.bat环境变量的写法也不同Linux 用exportWindows 用set。这些细节在安装文档里都有但实际执行的时候最容易出问题的恰恰不是命令差异而是“补丁目录路径是否包含中文或空格”“当前用户对$ORACLE_HOME有没有写权限”这类看起来和补丁完全无关的事情。我的建议是拿到补丁包后先把压缩包里的README.txt解压出来完整读一遍。那里面会写明补丁对应的 CPU 月份、依赖的前置补丁、最低 OPatch 版本要求以及安装后的附加操作。这一步花不了几分钟但它能帮你避开后面一小时的折腾。2. 安装前准备环境核对、OPatch 升级和备份一步都不能省2.1 环境归档先记录当前状态再动手我处理补丁的习惯是“先拍照后手术”。这里的拍照不是截图而是把当前环境的几个关键状态完整记录下来方便安装后对比也方便出问题时回退判断。建议在补丁安装前把以下信息写成一份记录# 1. 记录 WebLogic 版本 java -cp $ORACLE_HOME/server/lib/weblogic.jar weblogic.version # 2. 记录 OPatch 版本 cd $ORACLE_HOME/OPatch ./opatch version # 3. 记录当前已安装的所有补丁 cd $ORACLE_HOME/OPatch ./opatch lsinventoryopatch lsinventory这一步很重要。它会输出当前环境已经打过的所有补丁编号这份清单是你判断“补丁是否冲突”的关键依据。Oracle 补丁之间偶尔会有前置依赖关系如果你少装了一个依赖补丁opatch apply会在预检阶段直接报出来不会等到中途才失败。提前走一遍lsinventory你心里就有底了。2.2 OPatch 工具版本是安装成败的第一个门槛补丁安装失败的报错里我见到的第一条高频错误就是“OPatch version is older than required”。这句话的翻译是你手上的 OPatch 工具版本太旧带不动这个补丁。WebLogic 12.1.3 环境里自带的 OPatch 版本往往偏老而 P33385024 这类后来发布的补丁可能要求 OPatch 13.9 甚至更高的版本。解决办法不是去改补丁而是先从 Oracle 官方下载对应版本的新 OPatch 工具解压后把$ORACLE_HOME/OPatch目录备份一份然后用新版本覆盖。老规矩覆盖前先备份。等补丁装完确认一切正常再决定要不要把旧 OPatch 删掉。这一步跳过的人基本都会在 apply 阶段被 OPatch 版本校验卡住白跑一遍流程。2.3 备份、内存和系统时间动手前的三件套很多事故都发生在“我备份了”和“我真的备份了”这两种状态之间。打补丁前我一般会做三层备份复制整个域目录尤其是config/config.xml、security目录和部署应用的applications目录。记录当前各服务器的启动参数和 JVM 参数方便后续恢复运行状态。把lsinventory的输出结果单独存一份方便回滚时对照。除此之外还有三个容易忽略的点。第一是磁盘空间opatch apply的应用过程会在$ORACLE_HOME下写入大量临时文件原文件也会做备份存储最好保证有至少 5GB 的可用空间可以通过df -h提前检查。第二是内存OPatch 本身运行在 JVM 上如果机器内存紧张可能会在应用过程中被系统 OOM 杀掉这时可以通过设置OPATCH_JAVA_MEMORY加大 JVM 内存。第三是系统时间如果有 NTP 时间同步补丁应用的日志时间戳会比较可信排查问题时也能少绕弯子。2.4 停机检查不是所有 weblogic 进程都叫 AdminServer打补丁前必须把域里的所有服务停干净。很多人只知道停 AdminServer结果忘了后台还挂着一个开发用的 ManagedServer或者忘了 NodeManager 还在运行。其实 NodeManager 进程不一定需要为补丁特意停止但 ManagedServer 没有全停补丁应用时修改的 jar 文件被占用Windows 下会直接报文件锁错误Linux 下则会因为文件正在被读取而写入失败。我踩过一次这种坑机器上同时起了三套 weblogic 环境一套查处生产一套查处测试结果只停了生产环境的进程测试环境的 ManagedServer 还开着同样会争用同一个$ORACLE_HOME。排查了半天最后用ps -ef | grep java把所有 java 进程列出来逐个核对路径才找到问题。所以做停机检查的时候一定要按“机器上所有 java 进程”来查而不是按“我这套域的进程”来查。集群环境的还要记住一点补丁需要在每个节点上都安装一遍不是只在管理节点打一次就算完事。如果你们是 AdminServer 和管理服务器分开部署的两台机器那就两台机器的$ORACLE_HOME都要跑一遍opatch apply。3. opatch apply 的完整落地流程从解压到业务验证3.1 解压与路径规范这些细节决定了你后面顺不顺先把补丁包上传到服务器然后解压到一个没有中文、没有空格、路径尽量短的目录。比如mkdir -p /u01/weblogic/patch/P33385024 unzip p33385024_121300_Generic.zip -d /u01/weblogic/patch/P33385024为什么要强调路径不能有中文和空格因为 opatch 底层还是走 shell 和 Java路径里有特殊字符时脚本解析很容易出边界问题。我就见过有人在 Windows 服务器上把补丁解压到C:\Users\张三\Desktop\patch这个目录结果 opatch.bat 怎么跑都报找不到补丁文件最后换到D:\patch就一路顺畅。这不是玄学是字符编码和文件名解析的兼容性问题。3.2 执行 apply完整命令和预期输出解压完成后按下面的步骤执行# 1. 设置环境变量以 Linux 为例 export ORACLE_HOME/u01/oracle/Middleware/Oracle_WLS export JAVA_HOME/u01/jdk1.8.0_202 export PATH$JAVA_HOME/bin:$ORACLE_HOME/OPatch:$PATH # 2. 切换进入补丁目录 cd /u01/weblogic/patch/P33385024 # 3. 执行补丁应用 $ORACLE_HOME/OPatch/opatch apply执行过程中你会看到类似这样的输出流检查 OPatch 版本和 OUI 版本验证补丁是否适用于当前 ORACLE_HOME检查补丁冲突和依赖关系复制新文件到$ORACLE_HOME对应位置生成备份文件到$ORACLE_HOME/.patch_storage目录最终输出OPatch succeeded.看到 “OPatch succeeded.” 并不代表万事大吉它只代表文件层面已经替换完成。真正要确认的是应用的 jar 包没有损坏、服务能正常起来、业务功能没有回归。3.3 第一轮验证查补丁清单看日志安装完成后第一件事是重新执行补丁清单检查cd $ORACLE_HOME/OPatch ./opatch lsinventory重点看输出里有没有P33385024这个编号以及它和 CPU 月份是否对应。再执行一次cd $ORACLE_HOME/OPatch ./opatch lspatches如果 P33385024 出现在已安装列表里就说明补丁已经登记进 Oracle 的补丁系统。与此同时去$ORACLE_HOME/cfgtoollogs/opatch/目录下翻一下最新的 apply 日志。日志末尾几行是关键如果这里报了 warning比如“某个 jar 文件校验不一致”或者“某个脚本未执行成功”虽然 opatch 退出码是 0也值得认真对待。我曾经遇到过补丁本身应用成功但因为磁盘空间不足个别备份文件没写完整后续回滚时根本找不到对应文件非常被动。3.4 启动服务和业务验证先 Admin再 Managed最后看业务补丁打完后不要急着把所有服务一次性拉起来。我的习惯是分三步走先启动 AdminServer看启动日志里有没有异常堆栈等Server state changed to RUNNING出现后再做下一步。再逐个启动 ManagedServer每启动一个就观察日志直到RUNNING状态稳定。最后做业务验证通过 Web 控制台登录管理界面再走一遍核心业务用例。这里顺带提一下weblogic remote console工具。如果你是远程管理多套环境并且平时就在用 Remote Console可以在补丁后启动它登录当前域确认域配置、数据源连接池、应用部署状态都是正常状态。它的好处是不用每次都去翻服务器上的日志文件一眼就能看到各服务器的健康情况和部署应用的最新状态。Remote Console 2.4.17 是目前比较新的版本连接方式和旧版差别不大但启动时注意 Java 版本兼容性太老或者太新的 JDK 都可能连不上。如果你平时用 IntelliJ IDEA 部署 weblogic 项目做联调补丁后第一次启动本地服务时最好在 IDE 里重新部署一次应用确认项目的编译产物和 weblogic 的类加载正常。这个场景虽然不是生产环境但能尽早暴露问题避免问题积累到生产窗口。4. 安装失败的典型场景和排查链路含回滚操作4.1 场景一OPatch 版本过旧第一次报错就卡住这个报错我在 12.1.3 环境里见得太多了。典型日志长这样You have attempted to apply a patch that requires OPatch version 13.9.x but the current OPatch version is 13.7.0.0.0遇到这种情况先不要慌张也不要试图绕过版本检查。正确做法是去 Oracle 官方技术支持的补丁下载页面搜索最新版本的 OPatch 工具下载后替换$ORACLE_HOME/OPatch。替换时把旧目录改名备份比如OPatch_backup_20240101再把新包解压为OPatch。替换后重新执行./opatch version确认版本号已经满足要求再回到第 3 章的执行流程。整个排查链路的关键是先看日志定位到“工具版本”还是“补丁内容”的问题。工具问题就换工具补丁问题就查依赖不要一上来就想到回滚。4.2 场景二前置补丁缺失或补丁冲突第二种典型失败是预检阶段报告补丁冲突或者缺失某些前置补丁Patch P33385024 requires patch(s) P12345678 Conflict(s) detected with patch P87654321遇到这种问题不要想着强装。Oracle 补丁系统设计的前置检查就是用来防止环境变成一团乱麻的。正确做法分两步排查执行opatch lsinventory看当前环境有哪些补丁。如果缺失前置补丁就去下载前置补丁先装前置再回来装目标补丁。如果和现有补丁冲突需要先读取补丁 README确认冲突原因。有些冲突是可以忽略的但更多时候需要先移除或回滚冲突补丁。最忌讳的做法是看到冲突提示后用-force参数强装。我见过试过的人最后几乎都花了更长时间去修环境。补丁管理是长线工作环境干净比一时快更重要。4.3 场景三Windows 环境下的签名、权限和杀毒软件问题WebLogic 12.1.3 在 Windows 10 上仍然大量存在所以 Windows 下的补丁安装问题非常有代表性。首当其冲的是权限问题。opatch apply涉及大量文件写入如果不以管理员身份运行命令提示符很可能会在写文件阶段直接抛访问拒绝。这个好解决右键“以管理员身份运行”即可。第二个坑和 SHA-2 代码签名有关。Oracle 较新的补丁包和 jar 文件使用了 SHA-2 签名而老版本 Windows比如 Windows 7 或 Windows Server 2008 R2 SP1如果没有安装 SHA-2 代码签名补丁系统在加载文件时会直接拒绝或提示签名无效导致补丁应用异常。如果你所在的环境恰好是老系统先确认系统层有没有装 SHA-2 补丁。我印象里 Windows 的 KB2999226 这类补丁就是做这个的虽然它主要是给开发库用的和系统签名更新也算同一类底层能力。这类系统层面的问题网上直接搜“sha-2补丁”就能找到对应的更新包提前装好能省去很多莫名其妙的问题。第三个坑是杀毒软件。补丁包里的 jar 文件在执行时会被解压、覆盖、重写这个行为和某些病毒行为有点像。如果杀毒软件的实时防护开着有可能在 opatch 写文件的过程中把关键文件隔离掉导致应用完成后一启动就报类找不到。我的建议是在补丁应用窗口内临时关闭实时防护或者把$ORACLE_HOME目录加入白名单打完补丁启动服务后再恢复防护。4.4 回滚操作和求救信息收集补丁一旦应用失败或者应用后服务启动异常不要慌先收集信息再做决定。需要收集的包括$ORACLE_HOME/cfgtoollogs/opatch/下最新的 apply 日志opatch lsinventory -detail的输出结果服务器启动日志里最早的异常堆栈确认要回滚时执行cd $ORACLE_HOME/OPatch ./opatch rollback -id P33385024这一步会把补丁应用前备份在.patch_storage里的文件恢复回去。前提是你没有清理过.patch_storage目录也没有因为磁盘空间不足导致备份不完整。这也是我在第 2 章反复强调要检查磁盘空间的原因——回滚机制依赖那个备份目录目录不完整回滚就会失败。5. 补丁管理的一次实践总结和长期建议5.1 把补丁包的命名规则整理成团队台账经过这一整套流程我对补丁管理的最大体会是补丁包本身不复杂复杂的是环境状态的管理。建议大家建一个补丁台账至少记录以下几列环境WebLogic 版本补丁编号补丁月份OPatch 版本安装日期执行人回滚状态生产-节点112.1.3.0.0P333850242024年某月 CPU13.9.x2024-xx-xx张三未回滚测试-节点112.1.3.0.0P333850242024年某月 CPU13.9.x2024-xx-xx张三未回滚有了台账之后下次再遇到新补丁你只要翻开表格就能马上判断当前环境的 OPatch 版本够不够用、有没有装过前置补丁、环境之间是否存在差异。这比临时执行lsinventory再人肉比对高效得多。5.2 单机、集群和开发环境的区别处理不同的环境类型补丁策略也应该不同。生产集群环境讲究的是“先测试、后生产、再灰度”开发环境则更看重“快速恢复”和“联调不停摆”。我现在的习惯是新补丁先在测试环境完整走一遍安装和回滚流程验证没问题后再安排生产窗口生产环境打补丁时必须走变更流程窗口期内除了补丁安装还要预留出业务回归的时间开发环境则只保留一份基准补丁版本不和测试混用避免开发同学调试时被补丁版本问题干扰。5.3 我的几点个人习惯最后聊几个我个人的小习惯。第一每次打补丁之前我都会在补丁目录下建一个文本文件记录服务器的 IP、weblogic 版本、补丁编号、开始时间这个文件在补丁窗口结束后会一直保留后续排查问题时非常有用。第二我习惯在补丁安装完成后用opatch lspatches的输出结果作为交付物发给相关同事让所有人都知道当前环境已经更新到哪个状态。第三遇到不确定的情况优先查 README 和官方文档而不是去论坛找所谓的高招。补丁这事本质上是个体力活但体力活也有章法。你把流程规范化把环境台账梳理清楚它就会变得非常可控。希望这篇文章能帮你在下一次 weblogic 补丁窗口里少走几步弯路。本文还有配套的精品资源点击获取