WebLogic补丁安装实战：OPatch应用、验证与滚动升级全解析

发布时间：2026/10/15 23:17:14
WebLogic补丁安装实战：OPatch应用、验证与滚动升级全解析
简介WebLogic补丁p33385024_121300_Generic.zip是面向Oracle WebLogic Server 12.1.3版本的企业级安全与稳定性更新包适用于所有平台可作为后续补丁安装的前置依赖。压缩包体积仅917KB包含5个文件其中3个XML文件用于补丁配置与清单记录1个核心补丁目录及1个readme说明文档结构精简便于运维人员快速识别与应用。目前已有278人学习/下载适合负责WebLogic环境维护的DBA或中间件管理员参考。通过该补丁包读者能够了解官方补丁包的标准目录构成、补丁安装脚本的调用方式以及安装前后的验证思路同时可结合readme中的说明顺利完成补丁部署并规避常见问题为后续升级更高版本补丁打好基础。1. weblogic补丁p33385024_121300_Generic.zip拿到手先别双击它只认opatch第一次接手WebLogic的人看到 weblogic补丁p33385024_121300_Generic.zip 通常有两种反应要么直接解压把里面文件往安装目录一铺要么不知道该放哪在群里追问这个zip要装到哪个路径。A同学用第一种方式处理过结果AdminServer再也起不来最后靠快照回滚才恢复现场。这个补丁包不是给你手工覆盖文件的它必须由opatch这个工具来认领、验证、备份和登记。p33385024是一个补丁号121300对应WebLogic Server 12.1.3.0.0Generic表示跨平台通用包。它解决的通常是运行期暴露的缺陷比如某个接口偶发异常、某个模块的已知问题具体内容以包内附的README说明为准。我把拿到包之后的所有动作按顺序拆开环境准备、apply、排查、验证、回滚以及集群环境下不停机打补丁的做法。适合刚从WebLogic入门、第一次被安排打补丁的新人也适合想确认自己没漏步骤的运维老手。2. 装前准备读懂文件名的三个字段并对齐五项环境指标打补丁最大的翻车点不在apply本身而在准备阶段。准备阶段做够了apply其实就是一条命令加一段等待准备阶段偷懒后面全是玄学错误。这一章先说命名规则再给一份可以直接抄走的环境检查清单。2.1 文件名拆解p33385024、121300、Generic 分别代表什么weblogic补丁p33385024_121300_Generic.zip这个文件名不是随便起的它包含三个关键字段。p33385024是补丁标识。WebLogic体系里所有补丁都有统一编号无论单点修复还是周期更新。33385024这个编号就是之后所有查询和回滚操作要用到的ID比如opatch rollback -id 33385024。别在变更记录里只写文件名把补丁ID单独记一行。121300对应WebLogic Server 12.1.3.0.0。这里的121300是版本号的紧凑写法12.1.3.0.0。看到这串数字要立刻确认自己管理的实例版本是哪个版本不符时apply会在早期阶段拒绝执行。Generic表意是跨平台通用包。同一个补丁如果按平台分开发布文件名里会带Linux、Windows之类的平台词Generic说明这个包可以用于多个操作系统。但跨平台不意味着跨版本也不意味着可以绕过版本检查。inventory登记的版本不对Generic照样拒绝安装。补丁安装后opatch会在中央inventory里登记补丁ID、应用时间、影响的组件。下次打新补丁时冲突检测就是拿inventory里的记录和这次要打的内容做比对。所以永远不要手工删除补丁压缩包里的文件也不要把解压出的二进制直接复制到WebLogic安装目录。绕过了opatchinventory里就没有记录后续补丁全部无法安全叠加。2.2 五项环境检查OPatch、JDK、ORACLE_HOME、磁盘、补丁基线我一般按固定顺序检查五项不用纸笔也能保证一项不漏。先执行下面这组命令# 1. 查看OPatch工具自身版本 $ORACLE_HOME/OPatch/opatch version # 2. 查看当前ORACLE_HOME和已装补丁清单 $ORACLE_HOME/OPatch/opatch lsinventory -detail # 3. 确认JAVA_HOME和JDK版本 echo $JAVA_HOME $JAVA_HOME/bin/java -version # 4. 确认补丁解压空间足够 df -h /tmp第一行确认opatch工具本身。补丁包会对opatch有最低版本要求这个要求写在补丁包的README里。如果opatch version输出的版本号低于README列出的最低版本不要继续第一件事先升级opatch。第二行的lsinventory是本次操作里最常用的命令。-detail参数让输出包含每个补丁的详细描述。看输出时重点确认两件事一是ORACLE_HOME路径是不是目标WebLogic安装目录很多机器上会装多个中间件产品把补丁打到另一个产品目录里是常见事故二是已装补丁列表里有没有和33385024冲突的条目。冲突检测在apply阶段也会做但提前看到能节省一次失败等待。第三行确认JDK。WebLogic 12.1.3支持JDK 1.7和1.8补丁README里会写明用哪个版本做验证。这里注意opatch进程本身用JDK启动打补丁时如果JAVA_HOME指向高版本JDK部分老补丁的脚本可能出现兼容性问题一般建议按README指定版本。第四行确认磁盘空间。补丁apply会备份被覆盖文件备份体积通常是补丁本身的一到三倍/tmp太满会导致apply中途退出。2.3 解压前先做文件校验别拿坏包做白工拿到zip后先做两件事校验文件完整性再确认包内结构。cd /tmp/patch md5sum p33385024_121300_Generic.zip # 将输出的MD5与补丁发布页提供的哈希比对 unzip -o /tmp/patch/p33385024_121300_Generic.zip -d /tmp/patch/patch_contents ls -la /tmp/patch/patch_contentsmd5sum这一步很多人跳过我建议不要跳。WebLogic补丁包是用zip打包的网络传输偶尔会造成二进制损坏。哈希对不上就把包重新下载不要拿半损坏的包去测试apply的容错能力。unzip解压后进入补丁子目录正常会看到README.txt、metadata.xml和一个与补丁号同名的目录。README是安装说明metadata.xml是opatch读的元数据。解压成功后花两分钟把README里的最低OPatch版本、前置补丁要求、适用版本抄在变更单上。这三行信息在apply失败时会用得上。如果解压时报CRC错误或者文件数量和发布说明不一致直接重新下载不需要继续排查环境。常见误用有人为了省事直接把zip解压到ORACLE_HOME下解压过程把补丁文件撒在WebLogic安装根目录里。这样既不会被opatch识别还污染了原目录严重时启动类加载器会优先读到补丁里的新类和旧类混在一起报一些看起来像灵异事件的ClassCastException。正确做法是解压在临时目录由opatch去拷贝和备份。3. 应用补丁的标准流程停节点、apply、盯日志准备做完进入正题。这一章按顺序讲三件事如何安全停止节点、如何执行apply、如何读日志。第一次打补丁的人最容易在这里犯一个错误把opatch apply当成普通shell脚本跑完看个状态就完事。3.1 停机停哪个、怎么停、停完要确认什么打补丁前先停服务。这里分两种情况单机环境或可以停机的集群全部停下来只想不停机看你手里的补丁是否支持滚动升级第6章展开讲。# 进入域目录执行脚本停止AdminServer cd $DOMAIN_HOME/bin ./stopWebLogic.sh # 停止受管服务器逐个执行 ./stopManagedWebLogic.sh ManagedServer1 # 确认进程已退出 ps -ef | grep weblogic.Server | grep -v grep停机时有个习惯值得养每次执行完停止脚本都查一次进程列表。WebLogic停止脚本偶发出现进程挂住不退的情况特别是受管服务器还有在线会话时。进程没有真正退出后续apply虽然能运行但补丁覆盖的jar可能被进程句柄占用Windows下直接报错Linux下不报错但运行态类不一致等下次重启才爆发。stopWebLogic.sh会依次关闭AdminServer和所有受管服务器stopManagedWebLogic.sh后跟服务器名。如果你是手动kill一定要先kill受管服务器再kill AdminServer反过来会造成节点在管理端残留注册信息。补丁是否需要停整个域不一定。单机必须全停。集群且支持滚动时可以用不停机方式。需要停整个域时先停所有受管服务器再停AdminServer。许多人在受管服务器还活着时重启AdminServer也无碍但补丁类操作要干净进程全退后再apply。3.2 执行 opatch apply命令、常用参数、执行成功的样子环境就绪后执行apply。最标准的命令# 1. 进入解压后的补丁目录 cd /tmp/patch/patch_contents/33385024 # 2. 执行apply其中$ORACLE_HOME是WebLogic安装根目录 $ORACLE_HOME/OPatch/opatch apply /tmp/patch/patch_contents/33385024这个命令会做完整的冲突检测、磁盘空间检查、备份和安装。等待时间取决于补丁大小短则几分钟长则十几分钟。输出最后出现OPatch succeeded字样时apply第一阶段完成。常配参数说明-silent静默应答适合自动化脚本。第一次手工打补丁不建议用交互输出里能提前看到警告。-invPtrLoc /xx/oraInst.loc指定中央inventory位置。一台机器装了多个中间件产品时系统可能找不到inventory报Unable to locate oracle inventory这时必须显式传该参数。-jdk /路径指定opatch运行时的JDK。多JDK共存的环境不要省这个参数。-merge把本次补丁与已装补丁做部分合并。有这个参数不代表所有冲突都能解决README里声明不支持合并的补丁强行使用更容易把inventory搞乱。我一般只在补丁说明明确支持merge时才用。apply的过程分四个阶段先读metadata做版本和依赖校验再做冲突与磁盘检查然后备份旧文件并写入新文件最后更新inventory。前两个阶段失败不会留下任何变更后两个阶段如果失败需要按日志判断是否回滚。apply执行期间不要开第二个opatch也不要手工去改ORACLE_HOME里的文件否则inventory会与磁盘不一致。有的环境里opatch会写入一个中央inventory锁第二个进程会直接失败但这不是它防并发的原因它是靠单进程设计来避免覆盖。3.3 输出只是信号日志才是证据apply命令给了OPatch succeeded也不急着启动服务先看日志。# 查看最新opatch日志 ls -lt $ORACLE_HOME/cfgtoollogs/opatch/ | head -5 tail -200 $ORACLE_HOME/cfgtoollogs/opatch/opatch2024*.log日志路径固定文件名带时间戳。若日志目录里出现多个opatch开头的文件选时间最近的。日志里需要关心的关键词Verify if the patches have been applied说明前置补丁缺失。把日志里列出的依赖补丁装上再继续。Conflict detected冲突检测失败。不要直接强上先看冲突的是哪个补丁ID再判断是回滚旧补丁还是评估合并。OUT OF SPACE磁盘不足清理空闲空间后重新apply。This patch is not applicable to this version版本不匹配。确认WebLogic的小版本号是否真的对应12.1.3.0.0以及是否缺了某个中间补丁基线。有个不成立的判断方法只看apply返回值是否为0。补丁工具的退出码与环境脚本有关部分环境即使apply失败退出码也是0日志里却带着大堆异常。读日志时不用找最后一个Exception要找第一个Error根因通常在中间位置。4. 避坑apply 失败与启动异常的 5 个排查现场这一章记录我实际遇到或帮同事排查过的五类高发问题。每条按现象、原因、解决三个层次写可以直接拿来对照。4.1 OPatch 版本过低apply 在准备阶段直接退出现象opatch apply 执行后几秒内退出日志开头出现OPatch version xxx is older than the minimum required version后续没有更多有效输出。原因补丁发布时要求一个最低OPatch版本服务器上的OPatch还是WebLogic安装时自带的旧版无法识别该补丁的metadata格式或依赖关系。解决按补丁README里标注的最低版本升级OPatch。常见做法是从更高版本的WebLogic安装包里拷贝新OPatch目录覆盖旧目录或使用补丁发布方单独提供的OPatch升级包。替换前先把原OPatch目录整体备份到/tmp替换后执行opatch version确认版本号已变化。升级OPatch本身不影响WebLogic运行但要在停机窗口内做。4.2 已装补丁与新补丁冲突apply 报 Conflict detected现象apply过程中止日志明确写着Conflict detected with the already installed patch后面跟一组补丁ID。原因目标机器之前装了别的补丁它和新补丁修改了同一批文件或依赖关系opatch拒绝在同一inventory里登记两个互相打架的补丁。解决先分析不要直接rollback。执行opatch analyze把冲突范围列出来判断旧补丁是否还需要保留。如果旧补丁没有保留价值先rollback旧补丁再重新apply新补丁。如果旧补丁是安全基线的一部分不要自行回滚找变更负责人确认合并方案或确认新补丁是否支持-merge。擅自用-merge绕过冲突会把inventory搞成黑匣子后续回滚时哪张补丁都摘不利索。4.3 apply 成功但启动报 PermGen 内存溢出现象补丁装完后启动WebLogic日志里出现OutOfMemoryError: PermGen space或java.lang.OutOfMemoryError: GC overhead limit exceeded。原因补丁给运行时jar包增加了类和方法的规模原有JVM参数里的永久代空间不够用。JDK 7使用PermGenJDK 8改用元空间参数对应的名字不同。解决修改域目录下bin/setDomainEnv.sh里的JVM内存参数。JDK 7环境把-XX:MaxPermSize调大常见做法是512m起步JDK 8环境调整-XX:MaxMetaspaceSize并一并检查-Xmx是否偏小。改完先启动AdminServer验证再逐个启动受管服务器。如果以前没加过MaxPermSize参数直接追加而不是改动原有-Xmx。4.4 opatch 说成功了lsinventory 里却找不到补丁ID现象apply输出显示OPatch succeeded但执行opatch lsinventory | grep 33385024 什么都搜不到。原因最常见有两种。第一种是打补丁时环境变量ORACLE_HOME指向了另一个实例补丁装进了别的安装目录当前shell里的ORACLE_HOME不是真实的WebLogic目录。第二种是apply过程中途被中断文件替换完成但inventory写入没有完成。解决先用opatch lsinventory -detail确认当前inventory对应的ORACLE_HOME路径再对照补丁实际打入的路径。路径不一致的换成目标ORACLE_HOME重新执行apply。路径一致但inventory未登记的重跑一次apply多数情况下opatch会检测到文件已置换并补齐登记。不要手工往inventory里写条目那只会伪造记录。4.5 补丁打了重启后冒出各种类加载异常现象补丁后重启节点日志里出现NoSuchMethodError、ClassNotFoundException或ClassCastException类型各不同指向的类名看着也不像同一个功能模块。原因最常见的是在WebLogic进程未完全停止时执行apply进程句柄还在补丁覆盖文件后运行中的类加载器与磁盘内容不一致重启后有些老类还在缓存里新类只有一部分被加载于是出现这类莫名的类异常。解决确认所有节点已退出重新执行一次apply保证文件完整再逐台重启。如果某台节点反复出现同样异常考虑先rollback再apply不要在同一台节点上反复局部替换。类加载层面的问题往往不是补丁本身有Bug而是替换动作不干净。5. 装后验证与回滚把看起来成功变成确实成功OPatch succeeded只是安装过程的结束补丁是否生效要到服务和版本信息层面验证。这一章列三个验证动作和一个回滚动作顺序执行下来变更记录才算完整。提示OPatch succeeded 只代表安装过程没报错不代表补丁被记录到 inventory。任何验证都以 lsinventory 为准。5.1 lsinventory 复查只认补丁ID和安装时间apply完成后第一件事不是启动而是查inventory。# 精确搜索补丁ID $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 33385024 # 想看更详细的信息可以加-detail $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep -A 5 -i 33385024第一行输出会出现包含补丁ID、安装时间、补丁类型和影响组件的信息。没搜到就是没装进这个ORACLE_HOME和4.4对照处理。第二行是加-detail再看一遍主要为了确认安装时间和影响的组件列表方便变更记录里填写。把这次输出保存到变更记录附件里后续回滚或叠加新补丁时可以直接对照基线。5.2 启动服务并核对版本线索inventory登记不等于类加载正常。启动服务验证功能层面# 启动AdminServer并后台跟踪日志 cd $DOMAIN_HOME/bin ./startWebLogic.sh /tmp/admin_start.log 21 tail -f /tmp/admin_start.log启动日志里出现Server state changed to RUNNING后看两个地方一是启动过程中有没有WARN或ERROR级别的类加载异常二是管理控制台Home Servers界面里的版本显示是否正常。受管服务器逐台启动不要一次性全启便于定位是哪台环境问题。另外建议在无业务流量的情况下做一次连通性检查比如从管理端口访问应用首页确认补丁没有破坏HTTP服务链。这个动作不复杂但能把能启动和能服务分开确认。验证动作命令/工具预期结果失败处理补丁登记opatch lsinventory出现33385024按4.4处理服务启动startWebLogic.shRUNNING无类加载异常按4.5处理业务连通访问应用首页HTTP 200检查补丁影响组件5.3 什么时候用 rollback以及怎么用补丁影响了业务或启动失败需要回退。命令是# 回滚指定补丁 $ORACLE_HOME/OPatch/opatch rollback -id 33385024 # 如果失败查看依赖信息 $ORACLE_HOME/OPatch/opatch rollback -id 33385024 -report参数说明-id指定回滚对象补丁号-report预演回滚过程先看输出里是否提示其他补丁依赖33385024。有依赖回滚会直接失败。回滚成功后同样查inventory确认33385024不再出现。需要特别提醒的是回滚不是reverse apply别指望把zip里的文件再手动铺回去。opatch回滚会从备份区还原被覆盖前的文件这个备份在apply阶段就自动创建了。如果apply过程中有人手工清理了备份目录回滚可能不完整。回滚完成后再按5.1和5.2走一遍验证。一个补丁从安装到回滚全程都要留日志存档这条记录比口头描述可靠得多。6. 不停机打补丁滚动升级的适用条件与我的实操习惯6.1 滚动升级不是所有补丁的默认模式滚动升级Rolling Patch是指集群环境里逐台替换节点让业务不中断完成补丁。但它有三个硬前提。第一个前提补丁本身支持滚动。补丁的README里会明示是否支持Rolling Patch有些补丁修改的组件是全局性的比如AdminServer的代码没法通过单个节点替换来生效。第二个前提集群节点数不少于两台且负载允许逐台重启。一台扛不住流量时滚动过程本身就是风险。第三个前提AdminServer必须先重启一次。受管服务器在启动时会与AdminServer校验版本一致性两侧版本不一致节点可能无法注册。常见做法是业务低峰期先重启AdminServer逐台操作受管服务器stopManagedWebLogic.sh停服opatch apply安装startManagedWebLogic.sh启动等待RUNNING后确认日志无异常全部节点完成后做一次整体lsinventory验证。6.2 滚动升级的执行脚本与逐台检查习惯下面是我常用的滚动操作脚本只是骨架根据域名替换变量# 逐台滚动升级执行示例 SERVER_NAMEManagedServer_1 DOMAIN_HOME/app/weblogic/domains/base_domain PATCH_DIR/tmp/patch/patch_contents/33385024 # 停节点 $DOMAIN_HOME/bin/stopManagedWebLogic.sh $SERVER_NAME sleep 10 ps -ef | grep $SERVER_NAME | grep -v grep || echo 进程已退出 # 安装补丁 $ORACLE_HOME/OPatch/opatch apply $PATCH_DIR # 验证补丁ID $ORACLE_HOME/OPatch/opatch lsinventory | grep 33385024 # 启动节点 $DOMAIN_HOME/bin/startManagedWebLogic.sh $SERVER_NAME # 等待状态 sleep 20 tail -20 $DOMAIN_HOME/servers/$SERVER_NAME/logs/$SERVER_NAME.log参数说明SERVER_NAME每次换成目标节点名sleep时间按服务器性能调整目的是等待旧进程完全退出和启动进程加载完成。grep -v grep这段是为了过滤掉grep自身进程判断节点是否真正退出有输出说明进程还在需要再等或者手动处理。实际操作时我习惯每台节点装完先看一遍日志再动下一台不批量执行。我吃过一次亏两台受管同时apply一台成功一台冲突现场乱成一团最后逐台回滚重来。从那以后我给自己定了个规矩滚动升级里节点一台一台过验证项一个不能少。打补丁这件事前期环境检查占六成apply只占两成验证占两成。把这三个部分拆开对待WebLogic的补丁安装会从玄学操作变成稳定流程。希望这个流程对你有用。本文还有配套的精品资源点击获取