简介WebLogic Server 12.1.3版本的基础补丁包p33385024_121300_Generic.zip面向企业级Java应用运维人员用于修复已知缺陷并增强服务器性能与安全性且适用于所有操作系统平台。压缩包大小为917KB共5个文件以xml配置、txt说明及补丁内容文件为主xml与readme文档可帮助快速核对补丁清单与部署要点。该包已吸引278人学习/浏览是WebLogic生命周期管理中优先安装的基础补丁也是后续补丁p33494824成功应用的前置依赖。通过应用此补丁可及时获得官方修复与改进降低系统安全隐患为后续版本更新奠定基础。1. 一个补丁文件名的背后先搞清你手上拿的是什么任何在 WebLogic 上跑过生产环境的人看到weblogic补丁p33385024_121300_Generic.zip这种文件名第一反应不应该是“又一个压缩包”而是先把它拆开读p33385024是补丁编号121300指向 WebLogic 12.1.3.0.0Generic表示这个包不区分操作系统Linux 和 Windows 都能用。换句话说你手上拿的是一份针对 12.1.3 这个特定版本的补丁更新包主要用来修复该版本已经暴露出来的缺陷和安全问题。它解决的问题可能是一条具体的 bug也可能是一个安全通告里提到的漏洞不打这个补丁你的中间件就一直带着已知风险在跑。这篇文章只做一件事把从拿到 zip 到成功把补丁打进去并验证生效的整个路径讲透包括命令、参数、前置检查以及最容易让新手翻车的那几个环节。适合谁看接手的同事临时把一个补丁包丢给你、让你“赶紧打一下”的运维或者正在整理 WebLogic 版本合规清单的中间件管理员又或者第一次接触 OPatch 这个工具的开发者。整个过程不玄学但细节非常多——环境变量少了、OPatch 版本不够、服务没停干净任何一步都能让你在 apply 阶段就卡住。2. 装补丁前的三道检查OPatch 版本、环境变量和补丁冲突2.1 核对环境ORACLE_HOME 与“Generic”的真实含义Generic不是指“随便解压到哪都能用”它表示这个补丁包内部包含了对多种平台的支持安装时会根据当前机器的操作系统自动选择对应文件。但正因为它是通用的你更需要确认两件事一是补丁编号是否适用于你当前的 WebLogic 小版本二是你的 ORACLE_HOME 路径到底指向哪里。常见的做法是# 查看 WebLogic 安装主目录通常从环境变量或启动脚本里就能看到 echo $ORACLE_HOME # 如果环境变量没有从安装目录反查 ls /opt/weblogic/Middleware ls /opt/weblogic/Middleware/wlserver # 确认版本 cd /opt/weblogic/Middleware/wlserver/server/bin ./version.sh 2/dev/null | grep WebLogic Server这里最关键的是wlserver目录它就是 OPatch 工具眼中的 ORACLE_HOME。也就是说你的 ORACLE_HOME 不是整个 Middleware而是 Middleware 下的wlserver目录。很多人第一次打补丁失败就是因为把 ORACLE_HOME 设成了 Middleware 根目录导致 OPatch 根本找不到自己的元数据目录。另外检查当前 WebLogic 的小版本。补丁编号一般会注明适用的版本范围比如 p33385024_121300 就是针对 12.1.3.0.0 这个基线。如果你的环境已经打了很多其他补丁小版本号会高于 0此时不能只看文件名要结合现有的补丁列表来判断。2.2 OPatch 版本检查与升级最容易被卡在门口的原因OPatch 是 Oracle 官方提供的补丁工具WebLogic 12.1.3 的 OPatch 位于$ORACLE_HOME/OPatch目录下。打补丁时OPatch 版本如果低于补丁包要求的最低版本会直接报一个类似 “OPatch version mismatch” 的错误连安装入口都不让你进。所以先把 OPatch 版本查清楚export ORACLE_HOME/opt/weblogic/Middleware/wlserver ls $ORACLE_HOME # 查看 OPatch 版本 $ORACLE_HOME/OPatch/opatch version正常输出类似OPatch Version: 13.9.4.2.0如果你的 OPatch 版本过低解决办法是下载对应的 OPatch 更新包来覆盖到$ORACLE_HOME/OPatch目录下。覆盖前先备份原有 OPatchmv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak unzip OPatch-xxx.zip -d $ORACLE_HOME $ORACLE_HOME/OPatch/opatch version注意覆盖 OPatch 后补丁工具的元数据目录通常是$ORACLE_HOME/.patch_storage这个目录不会被覆盖所以旧补丁记录不会丢。升级 OPatch 本身也算一种变更建议在操作记录里单独标注时间点。2.3 补丁冲突预检与数据备份装了再卸载的后悔药在真正执行 apply 之前OPatch 需要检查已安装的补丁列表确认新的补丁包不会和已有补丁冲突。这一步可以主动先跑一遍export ORACLE_HOME/opt/weblogic/Middleware/wlserver $ORACLE_HOME/OPatch/opatch lsinventory这个命令输出当前已安装补丁的完整列表每一行包含补丁编号、描述和安装时间。你要做两件事第一确认 p33385024 不在列表中防止重复安装第二确认列表里没有与 p33385024 冲突的其他补丁冲突信息一般在补丁包的 README 里有明确说明。备份策略上我最常用的方案不是备份整个 Middleware 目录——那样太耗时而是把 ORACLE_HOME 下可能被覆盖的目录做一次快照。具体来说tar -czf /backup/wlserver_before_p33385024.tar.gz \ $ORACLE_HOME/lib \ $ORACLE_HOME/server \ $ORACLE_HOME/modules \ $ORACLE_HOME/.patch_storage这三块是 WebLogic 补丁更新时最常触动的区域。如果真的打坏恢复思路就是把这三个目录还原回去再执行必要的回滚操作。生产环境建议把备份文件放到和安装目录不同的物理分区上避免同盘故障导致连后悔药都没了。3. 用 opatch apply 把 p33385024 装进 WebLogic最小可执行步骤3.1 停服与解压补丁目录结构长什么样停服是整个环节里优先级最高的一步。AdminServer 和所有 ManagedServer 都必须停下来否则 OPatch 在更新 jar 包时会被 JVM 的文件锁挡住。确认方式# 找到 WebLogic 进程确认服务已完全停止 ps -ef | grep weblogic jps -l | grep weblogic如果还有进程残留建议用kill正常关闭等待几十秒再确认一次避免直接kill -9留下状态不一致的隐患。停服之后把补丁包解压到一个临时目录。补丁包解压后会生成一个目录目录名就是补丁编号里面是 install 脚本和补丁核心文件。mkdir /tmp/weblogic_patches cd /tmp/weblogic_patches unzip p33385024_121300_Generic.zip ls -la /tmp/weblogic_patches/33385024解压完成后目录里通常能看到files、etc子目录以及README.txt或PatchApply之类的内容。README 建议扫一眼里面会写明补丁对应的 bug 号、影响的模块以及是否包含“不可回滚”的特殊说明。少数补丁存在“不能 rollback”的限制README 里会显著标出不看的后果是打完后发现有问题却卸不回来只能靠备份还原。3.2 执行 applyopatch apply 的完整命令与参数进入补丁目录执行以下命令export ORACLE_HOME/opt/weblogic/Middleware/wlserver export PATH$ORACLE_HOME/OPatch:$PATH cd /tmp/weblogic_patches/33385024 $ORACLE_HOME/OPatch/opatch apply -verbose-verbose是强烈建议加的它会把 apply 过程中每个步骤的日志都打印到控制台。如果不加遇到失败只会看到一句错误提示加一个日志文件路径排查起来要多绕一圈。apply 过程中如果报错多数情况会提示查看$ORACLE_HOME/cfgtoollogs/opatch/opatch2024-xx-xx.log这样的日志文件这个位置要记住。整个过程耗时取决于机器性能和包的大小一般从几分钟到二十分钟不等。执行到末尾通常会出现OPatch succeeded.此时补丁已经被写入.patch_storage和系统库存目录中。注意apply 完成后日志文件里的 “succeeded” 代表补丁被正确记录但这与实际运行是否正常是两回事后面还需要单独验证。参数还有些灵活用法以下是我实际用过、比较实用的几种# 静默模式脚本化管理时用日志写入指定文件 $ORACLE_HOME/OPatch/opatch apply -silent -log /home/weblogic/logs/opatch_apply.log # 指定 JDK当环境中存在多个 JDK 时强制指定 $ORACLE_HOME/OPatch/opatch apply -jdk /opt/java/jdk1.8.0_2023.3 打补丁过程中失败时的现场判断apply 失败并不罕见常见原因是补丁包要求的 OPatch 版本不满足、文件被占用、磁盘空间不足或者补丁冲突前检没通过。失败时第一反应是看日志。-verbose已开的话终端里最后几十行通常就是错误堆栈没开的话去cfgtoollogs/opatch目录找最新的日志文件。重点看错误语言里有没有 “conflict” 或 “no more space” 这样的字眼。第二反应是对照 README 里的前置条件。比如有的补丁要求 WebLogic 版本必须先低于某个版本才能打补丁本身已经包含了大量类文件的替换如果基线版本不对日志会提示 “Apply aborted, backed up files will be restored.”——这种情况下 OPatch 会尝试还原旧的类文件到原位置。遇到 apply 中途失败千万不要不清理现场就直接重跑。正确处理是先把当时正在执行的补丁目录还原$ORACLE_HOME/OPatch/opatch rollback -id 33385024如果 rollback 本身也失败说明.patch_storage里的状态已经乱了这种局面只能从备份还原 ORACLE_HOME。这也是前面强调备份的原因。4. 验证补丁生效与回滚让变更可撤销的手段4.1 opatch lsinventory确认补丁被记录apply 成功之后第一个验证动作是重新查看补丁库$ORACLE_HOME/OPatch/opatch lsinventory | grep 33385024输出中如果出现补丁编号、描述和安装时间说明补丁已写入库存。这一步看着简单但有一个容易被忽略的细节你 grep 到的补丁编号必须和文件名里的编号一致注意有的补丁包 install 后会显示两个编号——一个是基础补丁号另一个是它的“子补丁”两者共存是正常的。更完整一点可以用$ORACLE_HOME/OPatch/opatch lsinventory -details这个命令会列出每个补丁的具体文件变更记录适合确认补丁确实新增或替换了哪些 jar 包。如果你在做变更记录建议直接把这个命令的输出留档作为补丁生效的凭证。4.2 回滚操作opatch rollback 的正确姿势如果打了补丁后某个业务接口出现异常并且初步怀疑就是补丁导致的可以回滚。WebLogic 12.1.3 的补丁系统支持通过 OPatch 回滚前提是该补丁本身是可回滚的。$ORACLE_HOME/OPatch/opatch rollback -id 33385024 -verbose回滚命令的核心是-id参数它对应补丁编号。个别场景下如果补丁存在多个子补丁直接按顶层级补丁号回滚即可OPatch 会自动处理依赖关系。回滚完成后再看一次$ORACLE_HOME/OPatch/opatch lsinventory | grep 33385024这里注意有些回滚场景并不能把这个编号从库存里完全删除而只是标记成 “missing”。如果看到补丁号还在但上面标注了 missing 或 rolled back说明回滚动作本身已经生效不要误以为回滚没执行。判断依据是该补丁对应的类文件是否已经被替换回旧版本而不是单纯看编号还在不在。4.3 启动服务复验从日志里看补丁是否真的生效补丁库里记录了不代表运行时代码就一定是新的。真正的验证还得靠进程跑起来。先启动 AdminServer再逐个启动 ManagedServer# 启动 AdminServer nohup /opt/weblogic/Middleware/user_projects/domains/base_domain/startWebLogic.sh /tmp/start_admin.log 21 # 查看启动日志 tail -f /tmp/start_admin.log日志里出现Server state changed to RUNNING基本说明启动无碍。然后确认补丁涉及的模块在运行期是否正常——比如补丁如果修的是某个安全 bug测试方式是访问对应管理后台或调用相关接口如果修的是某个数据源问题就去执行一遍受影响的 SQL 或服务调用。这里需要特别说明的是WebLogic 启动时类加载器会把补丁替换过的 jar 包加载进 JVM。因此逻辑上只要补丁替换文件正确、服务能正常启动新代码大概率已经生效。要求更高的团队会去校验 jar 包的内容例如cd $ORACLE_HOME/server/lib unzip -p weblogic.jar META-INF/MANIFEST.MF | grep Implementation-Version通过 MANIFEST 里的版本号或构建时间判断是否包含了补丁后的构建信息。这个方法不一定对所有补丁适用但可以作为一个辅助判断手段。5. 装 WebLogic 补丁常见问题排查5 个踩坑记录5.1 现象opatch apply 报 “OPatch version mismatch”这是新手遇到最多的错误。明明补丁包解压正常但执行 apply 时 OPatch 直接退出日志里写着当前 OPatch 版本太低无法应用该补丁。原因补丁包对 OPatch 工具版本有最低要求原环境的 OPatch 版本低于基准线。这不是补丁包的问题而是环境工具陈旧。解决下载与 WebLogic 12.1.3 匹配的 OPatch 更新版本覆盖到$ORACLE_HOME/OPatch。覆盖前备份旧目录。覆盖后再跑opatch version确认版本达标。mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak unzip OPatch-13.9.4.2.0.zip -d $ORACLE_HOME $ORACLE_HOME/OPatch/opatch version5.2 现象apply 执行到一半报文件锁占用执行opatch apply时日志中提示某个 jar 包或目录被占用无法覆盖写入。原因WebLogic 服务没有完全停干净。特别是 AdminServer 停了但某些托管进程还在跑或 Java 进程的线程还没完全释放文件句柄。解决先查进程再决定是否强制结束。确认所有 weblogic 进程都不存在后再重新执行 apply。如果之前 apply 已经在半途失败不要在同一目录直接再跑先做一次回滚再重打。ps -ef | grep weblogic | grep -v grep kill -9 [pid] # 确认进程消失 jps -l5.3 现象回滚失败后补丁状态变成 “missing”执行opatch rollback时中间断掉之后lsinventory里看到补丁编号仍在但状态显示为缺样本或有些文件已被还原、有些没被还原半打状态。原因回滚本身就是多文件操作过程中断电或磁盘问题导致中断OPatch 未能完整结束。解决先尝试重新执行 rollback 命令多数情况下 OPatch 会从上次中断点继续。若仍然失败则只能从备份中恢复文件。这也是我在前面反复建议备份的原因——到了这一步备份就是唯一的后悔药。$ORACLE_HOME/OPatch/opatch rollback -id 33385024 -verbose # 若失败恢复备份 tar -xzf /backup/wlserver_before_p33385024.tar.gz -C /5.4 现象打完补丁后节点服务起不来服务启动到一半日志出现 ClassNotFoundException 或 NoClassDefFoundError。原因补丁更新了类文件但某些缓存目录中还残留旧版本的编译缓存或临时类。WebLogic 的servers/[节点名]/cache和tmp目录经常保存旧版本资源。解决清理该节点对应的缓存目录后重启但注意清理前保留参数配置不要动config目录。只删 cache 和 tmp 目录是安全操作。rm -rf /opt/weblogic/Middleware/user_projects/domains/base_domain/servers/AdminServer/cache/* rm -rf /opt/weblogic/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/*5.5 现象Windows 下解压补丁报 “Path too long”原因补丁包内部目录层级很深加上 Windows 系统默认路径长度限制解压到桌面或 C 盘根目录下会触达 260 字符上限。解决把补丁包放到短目录下再解压例如C:\patches或D:\tmp。如果仍然不够可以把这个目录的路径长度截短或者用 7-Zip 解压时勾选 “解除路径长度限制” 的对应选项。# Windows 下不要解压到 C:\Users\... 深路径放在 C:\pt 这类短目录 # 示例C:\pt\p33385024这个坑在服务器上很常见尤其是远程桌面操作时顺手把 zip 拖到桌面结果就是解压都解不出来更谈不上 apply。6. 把补丁变更做成可复用的流程一份顺手、可复现的脚本习惯补丁安装本身是一次性操作但它的流程完全可以沉淀成固定套路。我自己的习惯是打完补丁后先做三件事补丁编号、日志、验证结果三份信息归档在一个目录下清理掉临时目录把 stdout 里的关键输出保存为文件防止日后翻历史时找不到证据。PATCH_ID33385024 OPATCH_HOME/opt/weblogic/Middleware/wlserver/OPatch ARCHIVE_DIR/backup/patch_records/$PATCH_ID mkdir -p $ARCHIVE_DIR # 记录 apply 前的补丁清单 $OPATCH_HOME/opatch lsinventory $ARCHIVE_DIR/opatch_lsinv_${PATCH_ID}_before.txt # 记录 apply 后的补丁清单 $OPATCH_HOME/opatch lsinventory $ARCHIVE_DIR/opatch_lsinv_${PATCH_ID}_after.txt # 留一份详细的补丁文件变更信息 $OPATCH_HOME/opatch lsinventory -details $ARCHIVE_DIR/opatch_details_${PATCH_ID}.txt如果打完补丁后需要比较前后差异这些记录会非常有用。所谓 “补丁是否生效”不要只靠眼睛扫一眼 apply 成功那句话实际运行验证才是兜底。尤其是在问题排查时这些文件可以作为“补丁已安装”的直接证据省去重复确认的时间。我还习惯把补丁 zip 包本身归档到独立目录并在归档文件名里加打补丁的时间。类似这种习惯看起来朴素但一年后当你需要回答“这台机器某个补丁到底是什么时候上的、验证到了什么程度”时这一条记录就能省掉半天追查。这个过程本身也是一种补丁管理的雏形——先把单机流程理顺再考虑批量化和自动化。至少在你的维护文档里可以确认每个节点当前的补丁状态、回滚方式和验证结论。等到节点数量变多了这套单机流程也能顺畅地扩展成批量执行脚本的蓝本先记录、再执行、后验证每一步都留日志每一步可回退最后统一对结果做 check。最后说句实在的——WebLogic 的补丁安装并不难但每次踩坑几乎都因为同一个原因跳过前置检查直接干活。这些年我养成的习惯是先把服务停干净再检查 OPatch 版本宁可多花十分钟做备份也不在出错后花一小时找后悔药。希望帮到你。本文还有配套的精品资源点击获取
