简介WebLogic Server 12.1.3补丁p33385024_121300_Generic.zip面向WebLogic系统运维与管理人员用于修复12.1.3版本已知问题并提升稳定性和安全性且是后续补丁p33494824_121300_Generic.zip安装的必要前置条件任何平台均可使用。压缩包共5个文件包含3个XML格式的补丁清单与配置信息可帮助核对补丁内容和安装环境另有补丁核心数据目录及readme说明文档整体体积仅917KB结构轻量便于快速分发部署。目前已有278人学习下载。获取该压缩包后可提前掌握补丁依赖关系、目录结构及关键配置文件的作用结合说明文档梳理安装前检查要点为后续更新维护提供清晰参考降低升级过程中的不确定性与风险。1. 从文件名读懂 weblogic 补丁p33385024_121300_Generic.zip 是什么、修什么这类 WebLogic 补丁包第一步就是拆文件名p33385024 是补丁编号121300 对应 WebLogic Server 12.1.3.0Generic 表示这个包和操作系统无关Linux、Windows、AIX 拿到都能解压使用。它就是给 12.1.3 打安全补丁集PSU的标准产物作用是把中间件安装目录里一批有已知问题的 class 和 jar 整体替换成修复版本。它解决的是很现实的问题漏洞扫描发现 12.1.3 存在已知安全缺陷生产环境又不能随便升级大版本只能靠补丁续命。适合两类人——手里拿到 zip 但没走过完整流程的运维新手以及打过补丁但想核对边界和踩坑点的熟手。下面的路径按“准备—安装—验证—回滚”推进命令可直接照抄。2. 打补丁前的三项准备OPatch 版本、JAVA_HOME 和可回滚的备份WebLogic 的补丁安装更像“外科手术”而不是“一键升级”。它由 OPatch 工具把补丁里的文件写进中间件安装目录同时更新中央库存。这一步之前如果环境不干净后面 apply 阶段出现的错误会非常难排查所以我把准备阶段压成三个检查项按顺序做完再动手。2.1 解压与预检先读 README 再动手补丁包在安装前必须先解压我习惯单独建一个 /tmp/patch 目录避免直接解到 MW_HOME 里把目录结构搞乱。解压后不要急着执行任何脚本先打开补丁目录下的 README.txt重点看三样东西最低 OPatch 版本、是否要求先打某个前置补丁、安装之后是否需要额外的手动步骤。mkdir -p /tmp/patch cd /tmp/patch unzip -q p33385024_121300_Generic.zip ls -l p33385024 less p33385024/README.txt这段命令把补丁包解压到独立目录然后列出补丁目录内容并打开 README。unzip 的 -q 参数只是减少解压输出真正要确认的是目录里出现了 README.txt 和 files 子目录files 里放的是补丁实际要落地的文件和清单。README 是这份补丁唯一的安装说明书里面写的 OPatch 最低版本和安装后步骤优先级高于网上的任何教程。我见过有人跳过 README 直接 apply结果死在“前置补丁未安装”这个检查项上反而多花半天。解压前我还建议先做一次校验和比对。官方补丁下载页会给每个 zip 的 checksum 值下载完先算一遍再解压避免文件在中转过程损坏装到一半才报错。cksum p33385024_121300_Generic.zip md5sum p33385024_121300_Generic.zip两个命令任选其一把输出和下载页给出的值对比。cksum 是 POSIX 标准命令AIX 上也能用md5sum 在 Linux 上更常见。参数上注意解压目录不要带空格和中文路径OPatch 对路径里的特殊字符很敏感这是 12.1.3 时代就一直存在的老问题。2.2 确认 OPatch 版本、JAVA_HOME 和中央库存权限WebLogic 的补丁不是双击安装包而是由 OPatch 这个命令行工具执行。OPatch 本体位于 MW_HOME/OPatch 下调用它之前必须先设置 JAVA_HOME否则工具连启动都做不到。export MW_HOME/opt/mw export JAVA_HOME/opt/jdk1.7.0_80 export PATH$JAVA_HOME/bin:$PATH $MW_HOME/OPatch/opatch version这段先定义两个核心环境变量再把 JDK 的 bin 目录加进 PATH最后打印 OPatch 版本。MW_HOME 要指向实际中间件安装根目录也就是 WebLogic 12.1.3 的安装位置JAVA_HOME 指向 JDK 根目录而不是 bin 目录。opatch version 的输出就是当前工具版本拿它和 README 里要求的最低版本比对。如果偏低需要先去官方渠道下载对应版本的 OPatch 更新包替换而不是侥幸硬上。接下来检查中央库存。Linux 和 AIX 上 OPatch 依赖一个叫 oraInventory 的目录来记录所有已安装补丁打补丁时需要在里面写记录权限不够会直接失败。cat /etc/oraInst.loc ls -ld /opt/oraInventory第一行读取库存配置文件inventory_loc 后面就是库存实际路径第二行看这个目录的属主和权限。常见问题是用 root 安装了中间件但日常用普通用户启动库存目录属主也是 root普通用户打补丁时没有写权限。解决方式有两个用库存属主用户执行 opatch或者用 root 把库存目录 chown 给启动用户。Windows 上库存写在注册表里一般不需要手动处理。2.3 停服顺序与备份给回滚留后悔药打补丁前必须停掉所有 WebLogic 进程。Windows 上文件被占用时安装会直接失败Linux 上虽然能覆盖文件但运行中的进程可能持有旧 jar 的句柄重启后才能发现问题。停服顺序有讲究先停受管服务器再停管理服务器最后停 NodeManager这样控制台不会在过程中反复尝试拉起服务。export DOMAIN_HOME/opt/domains/base_domain $DOMAIN_HOME/bin/stopManagedWebLogic.sh managed1 t3://admin-host:7001 $DOMAIN_HOME/bin/stopWebLogic.sh ps -ef | grep -E weblogic.Server|NodeManager | grep -v grep | wc -l前两行调用 WebLogic 自带的停止脚本分别是停受管服务器 managed1 和管理服务器第三行统计剩余相关进程数确认输出是 0 再继续。stopManagedWebLogic.sh 的参数是受管服务器名和管理服务器地址如果域里有多台受管机需要逐个停stopWebLogic.sh 不需要参数默认停 AdminServer。若执行后进程数不为 0说明有残留找到它的启动命令确认身份后手动结束不建议一上来就 kill -9容易把别的服务一起带崩。备份这一步很多人嫌占空间跳过我不建议省。OPatch 自身有备份机制回滚时会还原原文件但它的备份存放在 MW_HOME/.patch_storage 目录里这个目录一旦损坏回滚就没戏。我会额外把关键目录打包一份算是双保险。tar -czf /backup/mw_home_$(date %Y%m%d).tar.gz \ $MW_HOME/OPatch \ $MW_HOME/wlserver/server/lib \ $MW_HOME/oracle_common参数上选了三个目录OPatch 是工具本体server/lib 是 12.1.3 补丁主要改动的区域oracle_common 是共享组件目录。整个 MW_HOME 打包当然更全但生产环境动辄几十 GB不现实这三个目录覆盖了补丁改动最密集的部分真出问题时配合 OPatch 的自动备份足够恢复。3. 用 OPatch 安装补丁dryRun 预演、apply 执行与 lsinventory 核对环境准备好之后真正的安装过程反而很简单核心就三个命令dryRun 预演、apply 应用、lsinventory 核对。但每个命令的输出都有对应的检查点执行完只扫一眼最后有没有 success 就收工的话容易漏掉中间夹着的错误信息。3.1 先让补丁自己跑一遍 dryRun 预演流程上建议先做一次预演。dryRun 会把补丁的检查逻辑完整跑一遍——前置补丁、冲突检测、Java 版本、OPatch 版本——但不写入任何文件。这一步是免费的后悔药环境里的问题会在真正动手前全部暴露。$MW_HOME/OPatch/opatch apply -dryRun /tmp/patch/p33385024 echo $?参数说明-dryRun 是预演开关后面跟补丁目录的完整路径注意路径要指向包含补丁 ID 的目录而不是 zip 文件本身。命令执行完看两件事输出里是否出现类似 Prereq check 和 Conflict check 均通过的段落echo $? 返回 0 表示检查通过。如果输出里有 conflict 或 failure 字样不要继续先回头解决。预演的最大价值是把问题前置。库存里已经有冲突补丁、JDK 版本不匹配这类问题直接在 dryRun 阶段就报出来不会污染安装目录。我习惯把 dryRun 输出重定向到文件里留档后面如果真的翻车排查时有一份干净的执行记录可以对照。3.2 正式 apply执行方式与输出关键字预演通过后就可以正式应用补丁。执行方式上有个小习惯先从任意目录切到 OPatch 所在目录再执行或者直接用完整路径调用两种方式等价。Windows 环境对应执行 opatch.bat参数一致。cd $MW_HOME/OPatch ./opatch apply /tmp/patch/p33385024apply 阶段 OPatch 会执行五类操作再次校验环境、备份将被覆盖的文件、写入新文件、更新中央库存、输出安装报告。屏幕上滚动的内容很多重点盯三个关键字Applying patch、输出里补丁 ID 对应的应用记录、最后一行 OPatch succeeded。出现 OPatch succeeded 才算安装完成中途任何一步报错都会停在错误处不会继续。执行过程中不要用 CtrlC 中断。OPatch 的备份和写入是分阶段的中断可能导致库存记录和实际文件不一致这种状态比不打补丁更麻烦。整个 apply 通常在 5 到 20 分钟取决于机器磁盘速度。如果超过半小时没动静先看是不是磁盘满或者库存目录权限问题别盲目重试。注意apply 必须以 MW_HOME 属主用户执行不要在 root 下跑 opatch 再 chown那会把库存权限搞乱。3.3 lsinventory确认补丁真的进了库存安装成功之后还要用 lsinventory 确认补丁已经登记在中央库存里。这一步的作用是给后续排障留依据也防止后续重复安装。$MW_HOME/OPatch/opatch lsinventory | grep -i p33385024这条命令列出所有已安装补丁再通过 grep 过滤出 p33385024。如果能匹配到一行带补丁 ID 的记录说明补丁已登记。lsinventory 输出很长直接看全量容易眼花过滤是常用做法。如果后面需要更细的文件级信息可以加 -detail 参数。它会列出补丁修改过的具体文件和路径适合排查“某个 jar 到底有没有被替换”这种问题时使用。但 -detail 输出量很大平时不需要每次都跑。到这里安装阶段完成。注意此刻只是中间件这一层补好了domain 还没有重启新的 class 还没有真正进入运行态下一步的重启和验证才是让补丁生效的关键。4. 常见问题与避坑五个高频翻车点补丁安装的理论流程不长但实际执行时踩的坑几乎全在环境差异上。下面五个问题是我在实际操作中反复见过的每一条都按“现象—原因—解决”整理遇到时可以直接对号入座。4.1 现象opatch apply 几秒内报 OPatch 版本过旧打补丁时刚执行 apply输出里直接出现 OPatch 版本低于最低要求的错误安装中断。原因OPatch 工具本身也有版本生命周期12.1.3 的补丁对工具版本有硬性校验而服务器上的 OPatch 可能还是几年前的版本并不会因为中间件版本正确就自动可用。解决先执行 opatch version 确认当前版本再从官方补丁渠道下载对应的 OPatch 更新包。更新时把旧 OPatch 目录改名备份到其他位置解压新包覆盖到 MW_HOME/OPatch确认 opatch version 输出符合 README 要求后再重新执行 apply。这一步在 dryRun 阶段就能发现所以预演不要跳过。4.2 现象提示补丁已安装或者冲突无法继续执行 apply 时输出里有补丁已应用或者冲突提示安装被阻断。原因这个补丁之前已经通过其他渠道装过或者中央库存里残留了旧记录也有可能是 README 要求的多个补丁安装顺序没有遵守导致前置补丁状态不对。解决先用 lsinventory 过滤补丁 ID确认是否已存在。如果库存里已经有记录且版本正确就不用重复安装直接进入重启验证阶段如果确实要求装多个补丁按 README 给的顺序执行不要自己调整先后。检查完仍提示冲突的需要把冲突方先回滚再重新走流程。总的原则是让 OPatch 的库存状态和实际文件保持一致人工去改库存文件是最后的办法不建议一上来就动。4.3 现象opatch 起不来提示 JAVA_HOME 未设置或 JVM 初始化错误执行任何 opatch 命令都直接报错命令行提示 JAVA_HOME 环境变量没有定义或者 JVM 初始化阶段失败。原因OPatch 依赖完整的 JDK 环境而服务器环境变量里可能指向了系统自带的 JRE或者 JAVA_HOME 在 ssh 会话里没有继承。解决export JAVA_HOME 指向 JDK 安装根目录不要带 bin 后缀然后执行 $JAVA_HOME/bin/java -version 验证。注意确认这台机器上装的是 JDK 而不是 JREOPatch 需要用到 javac 和 jar 等工具链。设置完重新执行 opatch version确认能正常输出版本号再继续。这条我在新环境上几乎每次都要检查因为很多基础镜像只带 JRE。4.4 现象apply 成功但重启后报类加载或类型转换异常补丁确认安装成功重启管理服务器后控制台或日志里出现 ClassCastException、NoClassDefFoundError 这类错误部分功能不可用。原因补丁替换了 jar 里的类但域目录下还缓存着旧版本的 class 文件另外如果打补丁时服务器进程没有停干净部分文件被旧进程占用没替换成功也会在重启后暴露。解决先确认打补丁时所有 java 进程确实已退出然后清理域缓存目录清理范围和命令在 5.1 给出再重启。重启后如果错误消失说明是缓存问题如果依旧报错多半是文件替换不完整用 opatch rollback 回滚后重新走一遍干净流程。不要在这种状态下反复重启每次重启都会让排查更乱。4.5 现象清缓存时误删目录管理服务器起不来了在清理 tmp 和 cache 时命令范围写太宽把 domain 下的 config 或者整个 servers 目录一起删掉了控制台直接打不开。原因清缓存命令用了对整个 domain 目录的递归删除而 find 的匹配条件没有精确限定到 tmp、cache、stage 这几个固定目录。解决清理命令务必将范围限定在 servers 下的三级目录结构具体命令在 5.1 给出不要对 domain 做整目录递归操作。误删之后只能从备份恢复所以 2.3 里打的 tar 包这时候就是救命稻草。这类事故我见过不止一次从那以后我把清理命令固定成一段脚本不再临场手敲。5. 重启与生效验证清缓存、按序启动、日志确认与回滚补丁写入安装目录只是第一步让运行中的 domain 真正用上新 class还要经过缓存清理、重启、日志验证三个环节。这一章把每个环节的具体操作和判断标准写清楚。5.1 清理域缓存让新 class 在重启后真正生效WebLogic 在运行过程中会把编译后的 class 缓存到域目录下补丁替换了 jar 里的类旧的缓存如果不清理重启后可能继续加载旧版本。这一步不做就会出现 4.4 里描述的那类诡异错误。export DOMAIN_HOME/opt/domains/base_domain find $DOMAIN_HOME/servers -maxdepth 3 -type d \( -name tmp -o -name cache -o -name stage \) -exec rm -rf {} 这条命令在 servers 目录下查找名为 tmp、cache、stage 的目录并递归删除。maxdepth 3 是安全护栏确保只在 servers/服务器名/缓存目录 这个深度范围内操作不会碰到上层的 config 和 bin。执行之前先看一遍 find 输出的完整路径列表确认每条都在预期范围内再决定是否加 -exec 执行。这是清缓存事故的预防手段也是把 4.5 的坑从根源上封住的做法。清理完后不要急着启动先确认缓存目录已不存在再用 ls 看一下 servers 目录下只剩正确的子目录。Windows 上没有 find 命令可以手动打开域目录删除这三个文件夹效果相同。5.2 按顺序重启用运行日志确认补丁生效启动顺序和停止顺序相反先启动 NodeManager再启动管理服务器等管理服务器进入 RUNNING 状态后再启动受管服务器。这样控制台可以先确认补丁环境是否正常再让业务节点接入。$DOMAIN_HOME/bin/startNodeManager.sh $DOMAIN_HOME/bin/startWebLogic.sh tail -f $DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log第一行启动 NodeManager第二行后台启动管理服务器第三行实时跟踪管理服务器日志。判断标准是日志里出现服务器进入运行模式的关键信息随后管理控制台可以访问。如果日志里出现 Exception、ClassNotFound 或类型转换报错立刻停住排查不要继续启动受管服务器。日志验证我一般按下面这张表逐项确认检查点方法预期结果进程存在ps -ef 查相关 java 进程AdminServer 进程稳定存在日志关键字grep RUNNING出现进入运行模式的日志控制台访问浏览器打开 Console登录页正常加载补丁状态lsinventory 过滤 ID补丁 ID 仍在库存中版本核对setDomainEnv.sh 后执行 java weblogic.version输出与安装目标一致受管服务器启动后同样去对应受管服务器的日志目录确认运行状态并抽查业务接口的健康检查。到这里补丁才算是真正进入了生产运行态。5.3 opatch rollback补丁的后悔药怎么吃如果重启后业务表现异常或者补丁与现有应用不兼容就需要回滚。回滚前先把所有服务器和 NodeManager 停掉回到 2.3 的干净状态然后执行$MW_HOME/OPatch/opatch rollback -id p33385024rollback 的参数是补丁 ID也就是文件名里 p 后面那串数字。OPatch 会根据库存里记录的备份文件把补丁覆盖过的文件还原到安装前状态完成后同样输出 OPatch succeeded。回滚结束后重复 5.1 的缓存清理和 5.2 按序重启再验证一次业务是否恢复正常。关于回滚需要说清楚两点一是它只还原中间件安装目录不还原 domain 里的配置和应用应用自身的问题要靠应用备份恢复二是回滚依赖 .patch_storage 目录里的备份所以 2.3 里的手动 tar 仍然建议保留双保险不是多余的。6. 进阶习惯把补丁过程固化成一份可复用的检查脚本打补丁这件事熟练之后真正的风险不在命令而在“手滑”和“漏步骤”。我后来把整个流程整理成一件可以复用的事每次补丁前打一份环境快照补丁后再打一份然后对比差异让数据告诉我补丁到底改了什么。这个习惯适合所有版本的 WebLogic 补丁也适合定期审计服务器上的补丁状态。#!/bin/bash # 补丁快照记录库存、关键文件时间戳、补丁包校验值 MW_HOME/opt/mw SNAP_DIR/backup/patch_snapshots/$(date %Y%m%d_%H%M%S) mkdir -p $SNAP_DIR $MW_HOME/OPatch/opatch lsinventory $SNAP_DIR/lsinventory.txt 21 stat -c %y %n $MW_HOME/wlserver/server/lib/weblogic.jar \ $SNAP_DIR/timestamps.txt sha256sum /tmp/patch/p33385024_121300_Generic.zip \ $SNAP_DIR/patch_sha256.txt这段脚本在补丁前跑一次生成的快照目录里记录了补丁库存、核心 jar 的修改时间、补丁包本身的校验值。AIX 的 stat 参数和 Linux 不同脚本按 Linux 写如果跑在 AIX 上把 -c %y %n 换成对应的格式即可。补丁安装并重启完成后再跑一次然后对比前后两份库存cd /backup/patch_snapshots BEFORE$(ls -dt */ | sed -n 2p) AFTER$(ls -dt */ | sed -n 1p) diff $BEFORE/lsinventory.txt $AFTER/lsinventory.txt | grep p33385024能匹配到补丁 ID说明库存变化符合预期weblogic.jar 的时间戳也会比补丁前新。这样既不依赖人工记性也方便在复盘时拿数据说话。从那以后我每次给 WebLogic 打补丁都强制走一遍dryRun → 快照 → apply → lsinventory 对比 → 清缓存 → 按序重启 → 看日志一套流程走完才敢把补丁状态报出去。这套习惯帮我挡住了至少三次库存不一致和两次误删目录的事故希望帮到你。本文还有配套的精品资源点击获取