简介这份资源是适用于WebLogic Server 12.1.3版本的官方补丁包p33385024_121300_Generic.zip面向负责企业级Java应用服务器运维的工程师。该补丁为跨平台通用补丁主要修复该版本已知问题并提升稳定性同时也是后续补丁p33494824的先决条件。压缩包共5个文件包含3个XML配置文件、补丁主体目录及一个readme说明文档整体仅917KB结构精简便于快速部署。现有276人已下载学习。通过安装此补丁运维人员可以为WebLogic环境打好必要基础避免因版本缺陷带来的安全风险并为后续功能增强补丁的顺利应用铺平道路配套的readme与配置文件有助于核对补丁信息降低误操作概率。 做WebLogic运维这些年补丁管理一直是个绕不开的活儿。前阵子接到一个环境业务系统跑在WebLogic Server 12.1.3.0.0上厂商要求打一个编号为p33385024的补丁给过来的安装包就是weblogic补丁p33385024_121300_Generic.zip。补丁编号、版本号、平台类型全写在文件名里了但实际装起来牵扯到OPatch版本、停机窗口、回滚方案等问题稍微准备不足就容易翻车。这篇文章就以这个补丁包为线索把WebLogic补丁安装从识别、准备到落地、回滚的完整流程讲清楚适合负责WebLogic日常运维或者第一次接触Oracle中间件补丁的同事参考。1. 拿到补丁包之后我先教你读懂文件名很多人拿到补丁包第一件事就是解压然后到处找README。我的习惯是先盯着文件名看一分钟这一分钟能把大部分信息拆完后面做事就有方向了。1.1 从 p33385024_121300_Generic.zip 能读出什么这个文件名结构很标准Oracle补丁包命名一般是p补丁编号_版本号_平台.zip。逐段拆开看p33385024补丁标识号。这个号是Oracle内部唯一编号下载、查询、回滚都靠它不能错一个数字。121300目标版本明确对应 WebLogic Server 12.1.3.0.0。这是12c R1的最后一个大版本很多老系统还在用它。Generic.zipGeneric代表跨平台通用包不区分Linux、Windows还是AIX下载时选这个最省事。如果文件名里写的是Linux-x86-64.zip之类的那就是有平台特化内容的包选择时要更谨慎。拆完文件名下一步动作就很明确了需要去核实现有环境是否为12.1.3.0.0以及这个补丁是要解决什么问题。Oracle补丁的类型也不止一种光是安装策略就有区别。1.2 补丁类型选型为什么不能乱打补丁WebLogic补丁常见的有三类理解它们的区别可以避免很多坑补丁类型说明安装时机One-off Patch单点问题修复包针对某个Bug风险最小遇到具体问题时PSU / SPU季度安全更新与关键修复合集包含多个修复定期维护窗口Bundle Patch某组件连续修复合集比如Coherence组件存在多个问题时p33385024这种独立补丁包一般归为One-off Patch或特定问题修复包针对性较强但也不排除包含安全更新内容。安装前务必打开解压后的README或补丁说明文档确认修复内容、依赖补丁和已知限制。直接用文件名猜功能在正式变更中是不够严谨的——README里会写清楚“此补丁解决什么问题、是否需要其他补丁前置、是否要求OPatch最低版本、是否影响现有配置”这些信息直接决定安装可行性。1.3 下载、校验和解压的第一次关键动作补丁包通常从My Oracle SupportMOS下载需要账号登录后在Patches Updates中搜索补丁编号。正规流程中下载后还要做两件事校验文件完整性在MOS下载页面一般能看到文件的MD5或SHA-1校验值。全平台通用做法是cksum p33385024_121300_Generic.zip或者用md5sum对比哈希值。传输过程中丢几个字节安装时未必报错但运行期可能出诡异问题这步不能省。解压到独立目录不要直接在一个杂乱目录里解压。建议单独建$HOME/patch/33385024作为临时工作目录解压后能看到一个与补丁编号一致的子目录里面是补丁文件、README等。解压后先翻README重点看“Prerequisites”和“Post-Installation”两段很多环境准备要求都写在其中。这个阶段我踩过一次印象很深的坑补丁包下载后直接解压到了用户家目录结果补丁拷来拷去最后丢了一部分文件安装时报文件缺失。从那以后所有补丁包都有固定的存放路径并且解压后先列出文件清单核对数量。2. 安装前的环境检查这里翻车的人最多补丁装不上十有八九不是补丁本身的问题而是环境不满足条件。WebLogic补丁安装对版本、OPatch工具、Java版本都有硬性要求每一样都要提前确认。2.1 WebLogic 版本与补丁编号的匹配关系补丁的版本号是12.1.3.0.0但并不代表这个版本以上的WebLogic就能安装这个包。应用补丁前必须在目标服务器上确认产品版本和已有补丁情况。查看WebLogic版本的位置和方法有多种查看安装目录下的注册表或版本文件在Middleware Home的inventory/registry.xml中记录了所有已安装组件和版本。通过OPatch查看已安装补丁进入$MW_HOME/OPatch目录执行./opatch lsinventory输出中会列出Oracle Home路径、版本以及已经打过的所有补丁编号。这里有一个容易忽略的点一个Middleware Home下面可能同时安装了WebLogic Server和其他产品组件如Coherence、SOA Suitelsinventory结果会很长注意先看顶部“Installed Top-Level Products”确认补丁要作用到的组件确实存在。如果目标组件压根没装补丁预检查阶段就会报错。2.2 OPatch 版本是第一个坎OPatch是Oracle提供的补丁工具补丁是否能被正确应用很大程度取决于这个工具的版本。补丁README中通常会写“OPatch 13.x or later is required”之类的字样如果现有OPatch低于要求补丁应用会直接终止。执行命令查看OPatch版本$MW_HOME/OPatch/opatch version如果版本不满足要求需要在MOS上单独下载对应版本的OPatch工具包进行升级。注意升级OPatch本身也是一次小型变更同样需要做好备份。升级方法一般是解压新OPatch并替换原目录或者通过官方提供的升级脚本完成。替换前我习惯把旧OPatch目录改名备份比如OPatch_bak20241201这样万一新工具异常还能立即回退。2.3 Java 环境与系统预检查WebLogic 12.1.3默认运行在JDK 7上但补丁安装过程中的脚本有的仍会调用java -version做环境判断。提前确认以下几点当前使用的JDK版本。命令java -version或者看$MW_HOME/wlserver/.product.properties里记录的Java版本。JAVA_HOME环境变量是否指向统一管理的JDK目录。多个WebLogic实例共用一台机器时JAVA_HOME指错目录会造成连锁反应。系统层面是否有足够磁盘空间和临时目录权限。OPatch解压、备份过程中会在/tmpLinux或临时目录写大量文件空间不足会导致“Unable to create local file”之类报错。用df -h检查空间预留至少是补丁包大小的3到5倍。环境预检查阶段还可以调用OPatch的自检功能./opatch prereq CheckSystemPrereqs这条命令会读取补丁目录下的配置文件一次性检查操作系统的内核参数、依赖库、磁盘空间是否满足要求。多个环境差异较大时这一步能提前暴露80%的兼容性问题。2.4 准备变更窗口与备份补丁应用后WebLogic Server需要完全停止才能保证环境一致性。这意味着必须预留业务停机窗口。变更窗口建议分成三段补丁应用预计10到30分钟、系统启动验证预计10分钟、预留回滚时间如果失败需要裁掉补丁。总时长按1小时准备比较稳妥。备份是补丁变更中不可省略的环节至少覆盖以下内容Domain目录包含config、bin、security等核心配置内容备份方式可以直接压缩整个目录。Middleware Home下的补丁安装清单$MW_HOME/inventory目录里的内容记录着组件和补丁状态操作前备份一份。在补丁应用过程中OPatch也会自动创建backup目录默认路径在Oracle Home下的.backup隐藏目录中。这个后备目录不要手动删除回滚时OPatch会依赖它恢复旧文件。有一次我遇到过OPatch在备份阶段就失败的场景原因是变更用户对Middleware Home下的.backup目录没有写权限。所以在执行补丁之前我一般会手工创建一个.backup目录并赋予当前用户读写权限能省掉一堆麻烦。3. 补丁应用实操一步步走完整个流程环境准备好、窗口申请好接下来才是正式的安装动作。这一节我把完整的实操过程按顺序写出来每一步都解释为什么这么做。3.1 停机顺序比想象中重要WebLogic域中各角色有依赖关系停机顺序和启动顺序相反。推荐顺序是停受管服务器Managed Server。通过WebLogic控制台或命令操作逐个停止避免同时停导致状态文件冲突。停管理服务器AdminServer。待所有受管服务器状态变为SHUTDOWN后再停。停止NodeManager进程。NodeManager如果单独部署需要单独停止。确认没有Java进程还占用Middleware Home目录。执行ps -ef | grep java检查这是Windows下最容易漏的一步Oracle Home目录被Java进程占用时补丁应用不存在报错但替换文件可能只成功了一半。很多同仁在停管理服务器之前就急着执行opatch导致OPatch在处理替换文件时提示文件被占用。所有服务必须彻底停掉再进入下一步这是原则不是建议。3.2 解压补丁包的正确位置和方式补丁包上传到服务器后在Middleware Home之外的临时目录解压。注意不要在Middleware Home目录内直接解压更不要解压到WebLogic安装目录中。补丁目录只是OPatch读取的只读输入不参与中间件运行放安装目录里反而可能污染环境变量查找路径。解压操作cd /app/weblogic/patch unzip p33385024_121300_Generic.zip -d p33385024 cd p33385024解压完成后先看目录内容其中有一个以补丁编号命名的子目录里面包含etc/、files/等文件夹以及补丁特定的脚本。部分补丁包还包含多个独立目录这时要仔细看README确认哪个目录是需要apply的目标补丁。3.3 执行 opatch apply 的完整现场补丁目录准备好之后切换到Oracle软件安装用户我们环境里一般是weblogic用户进入OPatch目录执行apply。命令格式cd $MW_HOME/OPatch ./opatch apply /app/weblogic/patch/p33385024/33385024执行过程中OPatch会先做预检查包括检查补丁编号和Oracle Home组件匹配情况。检查兼容性冲突如果存在冲突补丁OPatch会列出冲突清单。有些补丁之间是互斥的需要先卸载旧补丁或者使用force参数但生产环境我不建议使用force除非严格评估过后果。生成备份文件开始替换或新增文件。执行过程中观察输出重点看每一行是否报ERROR或WARN。有些WARN是正常提示比如关于旧配置文件被保留的提示但涉及版本冲突的WARN就要停下来分析。整个apply过程结束时的核心提示是一段类似OPatch succeeded.或Patch 33385024 successfully applied.看到succeeded才能认为安装成功。如果中途失败OPatch通常会自动回滚已做的文件变更但输出中会有OPatch failed和具体错误码这时候不要盲目重跑要先看清楚失败阶段。3.4 补丁验证与启动确认补丁应用成功后验证动作同样重要。常用的验证手段有三个执行./opatch lsinventory看到补丁编号和补丁描述在列表内。查看补丁所在目录的日志文件确认没有应用过程的异常记录。启动管理服务器和受管服务器观察日志中是否出现版本匹配错误、类加载异常等。启动顺序与停机顺序相反先启动NodeManager再启动管理服务器最后逐台启动受管服务器。WebLogic启动时如果补丁与版本不兼容常会在日志中抛出UnsupportedClassVersionError或NoClassDefFoundError一旦出现这类异常优先怀疑补丁文件替换不完整。启动成功后还需要登录WebLogic控制台检查各服务的健康状态必要时调用几个核心接口做冒烟测试。4. 常见报错与回滚把这些坑提前排掉补丁安装过程中一定会遇到的坑我把这些年排查的经验整理成了一份速查表遇到问题可以按图索骥。4.1 环境类报错空间、权限与临时目录报错关键字原因处理方式Unable to create local file临时目录空间不足或权限不足清理临时文件检查目录权限扩展磁盘Insufficient space备份区域空间不够为Middleware Home所在文件系统预留充足空间Permission denied当前用户对ORACLE_HOME无写权限切换软件安装用户通过sudo或su这类问题看似简单但生产环境中经常遇到“有空间但目录挂载点不同”的情况。比如/tmp和/app是不同分区/tmp满了但/app有大量空余OPatch同样会失败。所以检查空间时要看OPatch实际使用的目录所在分区。4.2 OPatch 版本不满足要求时的处理OPatch版本过低时报错一般类似This OPatch version is too low to support the patch处理方法不是绕过而是升级OPatch。到MOS下载与WebLogic版本匹配的OPatch工具包解压后备份原目录再替换。升级后重新执行“SystemPrereqs检查”然后再跑apply。这个过程中有个细节OPatch工具包解压后目录名通常带日期或版本号正式替换时要注意确保脚本执行权限避免因权限缺失导致新工具无法运行。4.3 补丁应用失败后的回滚操作只要OPatch应用过程中创建了备份理论上就可以回滚。回滚命令cd $MW_HOME/OPatch ./opatch rollback -id 33385024回滚的适用场景包括补丁导致启动异常、业务接口报错、应用不兼容等。这里要特别提醒回滚前必须再次停止WebLogic Server理由与安装时一致。曾经有一次我图省事在管理服务器运行状态下直接执行rollback结果OPatch提示文件被占用回滚到一半才报错后续清理非常被动。回滚完成后再执行一次lsinventory确认补丁已从列表移除然后重启服务验证。4.4 安装后启动故障检查补丁应用成功但服务起不来这种场景最让人头疼。常规检查路径如下看启动日志最后500行定位关键异常代码。常见的是类文件缺失、版本不一致、配置文件解析失败。清理WebLogic缓存后重启。缓存目录一般在domain的servers/servername/cache和tmp下安全做法是备份这两个目录后删除。很多类加载异常其实是旧缓存导致的。如果涉及配置文件变化检查config.xml在备份前后的差异确认补丁没有把自定义配置重置。在这里分享一个我自己的操作习惯变更前把domain目录完整打成一个tar包单独存放补丁或回滚后再做一次diff对比能快速判断补丁是否修改了非预期范围内的内容。补丁变更不只是让文件替换成功更重要的是确保业务行为没有被破坏。这个内容后续如果想做得更省力可以进一步研究OPatchAuto的批量补丁能力它能把“检查、应用、回滚”整合成自动化流程适合多套环境统一处理。但对于单套环境的临时补丁手动走一遍这个流程反而更容易看清每一步发生了什么。本文还有配套的精品资源点击获取 WebLogic补丁安装全流程指南：从补丁包识别到安全回滚
简介这份资源是适用于WebLogic Server 12.1.3版本的官方补丁包p33385024_121300_Generic.zip面向负责企业级Java应用服务器运维的工程师。该补丁为跨平台通用补丁主要修复该版本已知问题并提升稳定性同时也是后续补丁p33494824的先决条件。压缩包共5个文件包含3个XML配置文件、补丁主体目录及一个readme说明文档整体仅917KB结构精简便于快速部署。现有276人已下载学习。通过安装此补丁运维人员可以为WebLogic环境打好必要基础避免因版本缺陷带来的安全风险并为后续功能增强补丁的顺利应用铺平道路配套的readme与配置文件有助于核对补丁信息降低误操作概率。 做WebLogic运维这些年补丁管理一直是个绕不开的活儿。前阵子接到一个环境业务系统跑在WebLogic Server 12.1.3.0.0上厂商要求打一个编号为p33385024的补丁给过来的安装包就是weblogic补丁p33385024_121300_Generic.zip。补丁编号、版本号、平台类型全写在文件名里了但实际装起来牵扯到OPatch版本、停机窗口、回滚方案等问题稍微准备不足就容易翻车。这篇文章就以这个补丁包为线索把WebLogic补丁安装从识别、准备到落地、回滚的完整流程讲清楚适合负责WebLogic日常运维或者第一次接触Oracle中间件补丁的同事参考。1. 拿到补丁包之后我先教你读懂文件名很多人拿到补丁包第一件事就是解压然后到处找README。我的习惯是先盯着文件名看一分钟这一分钟能把大部分信息拆完后面做事就有方向了。1.1 从 p33385024_121300_Generic.zip 能读出什么这个文件名结构很标准Oracle补丁包命名一般是p补丁编号_版本号_平台.zip。逐段拆开看p33385024补丁标识号。这个号是Oracle内部唯一编号下载、查询、回滚都靠它不能错一个数字。121300目标版本明确对应 WebLogic Server 12.1.3.0.0。这是12c R1的最后一个大版本很多老系统还在用它。Generic.zipGeneric代表跨平台通用包不区分Linux、Windows还是AIX下载时选这个最省事。如果文件名里写的是Linux-x86-64.zip之类的那就是有平台特化内容的包选择时要更谨慎。拆完文件名下一步动作就很明确了需要去核实现有环境是否为12.1.3.0.0以及这个补丁是要解决什么问题。Oracle补丁的类型也不止一种光是安装策略就有区别。1.2 补丁类型选型为什么不能乱打补丁WebLogic补丁常见的有三类理解它们的区别可以避免很多坑补丁类型说明安装时机One-off Patch单点问题修复包针对某个Bug风险最小遇到具体问题时PSU / SPU季度安全更新与关键修复合集包含多个修复定期维护窗口Bundle Patch某组件连续修复合集比如Coherence组件存在多个问题时p33385024这种独立补丁包一般归为One-off Patch或特定问题修复包针对性较强但也不排除包含安全更新内容。安装前务必打开解压后的README或补丁说明文档确认修复内容、依赖补丁和已知限制。直接用文件名猜功能在正式变更中是不够严谨的——README里会写清楚“此补丁解决什么问题、是否需要其他补丁前置、是否要求OPatch最低版本、是否影响现有配置”这些信息直接决定安装可行性。1.3 下载、校验和解压的第一次关键动作补丁包通常从My Oracle SupportMOS下载需要账号登录后在Patches Updates中搜索补丁编号。正规流程中下载后还要做两件事校验文件完整性在MOS下载页面一般能看到文件的MD5或SHA-1校验值。全平台通用做法是cksum p33385024_121300_Generic.zip或者用md5sum对比哈希值。传输过程中丢几个字节安装时未必报错但运行期可能出诡异问题这步不能省。解压到独立目录不要直接在一个杂乱目录里解压。建议单独建$HOME/patch/33385024作为临时工作目录解压后能看到一个与补丁编号一致的子目录里面是补丁文件、README等。解压后先翻README重点看“Prerequisites”和“Post-Installation”两段很多环境准备要求都写在其中。这个阶段我踩过一次印象很深的坑补丁包下载后直接解压到了用户家目录结果补丁拷来拷去最后丢了一部分文件安装时报文件缺失。从那以后所有补丁包都有固定的存放路径并且解压后先列出文件清单核对数量。2. 安装前的环境检查这里翻车的人最多补丁装不上十有八九不是补丁本身的问题而是环境不满足条件。WebLogic补丁安装对版本、OPatch工具、Java版本都有硬性要求每一样都要提前确认。2.1 WebLogic 版本与补丁编号的匹配关系补丁的版本号是12.1.3.0.0但并不代表这个版本以上的WebLogic就能安装这个包。应用补丁前必须在目标服务器上确认产品版本和已有补丁情况。查看WebLogic版本的位置和方法有多种查看安装目录下的注册表或版本文件在Middleware Home的inventory/registry.xml中记录了所有已安装组件和版本。通过OPatch查看已安装补丁进入$MW_HOME/OPatch目录执行./opatch lsinventory输出中会列出Oracle Home路径、版本以及已经打过的所有补丁编号。这里有一个容易忽略的点一个Middleware Home下面可能同时安装了WebLogic Server和其他产品组件如Coherence、SOA Suitelsinventory结果会很长注意先看顶部“Installed Top-Level Products”确认补丁要作用到的组件确实存在。如果目标组件压根没装补丁预检查阶段就会报错。2.2 OPatch 版本是第一个坎OPatch是Oracle提供的补丁工具补丁是否能被正确应用很大程度取决于这个工具的版本。补丁README中通常会写“OPatch 13.x or later is required”之类的字样如果现有OPatch低于要求补丁应用会直接终止。执行命令查看OPatch版本$MW_HOME/OPatch/opatch version如果版本不满足要求需要在MOS上单独下载对应版本的OPatch工具包进行升级。注意升级OPatch本身也是一次小型变更同样需要做好备份。升级方法一般是解压新OPatch并替换原目录或者通过官方提供的升级脚本完成。替换前我习惯把旧OPatch目录改名备份比如OPatch_bak20241201这样万一新工具异常还能立即回退。2.3 Java 环境与系统预检查WebLogic 12.1.3默认运行在JDK 7上但补丁安装过程中的脚本有的仍会调用java -version做环境判断。提前确认以下几点当前使用的JDK版本。命令java -version或者看$MW_HOME/wlserver/.product.properties里记录的Java版本。JAVA_HOME环境变量是否指向统一管理的JDK目录。多个WebLogic实例共用一台机器时JAVA_HOME指错目录会造成连锁反应。系统层面是否有足够磁盘空间和临时目录权限。OPatch解压、备份过程中会在/tmpLinux或临时目录写大量文件空间不足会导致“Unable to create local file”之类报错。用df -h检查空间预留至少是补丁包大小的3到5倍。环境预检查阶段还可以调用OPatch的自检功能./opatch prereq CheckSystemPrereqs这条命令会读取补丁目录下的配置文件一次性检查操作系统的内核参数、依赖库、磁盘空间是否满足要求。多个环境差异较大时这一步能提前暴露80%的兼容性问题。2.4 准备变更窗口与备份补丁应用后WebLogic Server需要完全停止才能保证环境一致性。这意味着必须预留业务停机窗口。变更窗口建议分成三段补丁应用预计10到30分钟、系统启动验证预计10分钟、预留回滚时间如果失败需要裁掉补丁。总时长按1小时准备比较稳妥。备份是补丁变更中不可省略的环节至少覆盖以下内容Domain目录包含config、bin、security等核心配置内容备份方式可以直接压缩整个目录。Middleware Home下的补丁安装清单$MW_HOME/inventory目录里的内容记录着组件和补丁状态操作前备份一份。在补丁应用过程中OPatch也会自动创建backup目录默认路径在Oracle Home下的.backup隐藏目录中。这个后备目录不要手动删除回滚时OPatch会依赖它恢复旧文件。有一次我遇到过OPatch在备份阶段就失败的场景原因是变更用户对Middleware Home下的.backup目录没有写权限。所以在执行补丁之前我一般会手工创建一个.backup目录并赋予当前用户读写权限能省掉一堆麻烦。3. 补丁应用实操一步步走完整个流程环境准备好、窗口申请好接下来才是正式的安装动作。这一节我把完整的实操过程按顺序写出来每一步都解释为什么这么做。3.1 停机顺序比想象中重要WebLogic域中各角色有依赖关系停机顺序和启动顺序相反。推荐顺序是停受管服务器Managed Server。通过WebLogic控制台或命令操作逐个停止避免同时停导致状态文件冲突。停管理服务器AdminServer。待所有受管服务器状态变为SHUTDOWN后再停。停止NodeManager进程。NodeManager如果单独部署需要单独停止。确认没有Java进程还占用Middleware Home目录。执行ps -ef | grep java检查这是Windows下最容易漏的一步Oracle Home目录被Java进程占用时补丁应用不存在报错但替换文件可能只成功了一半。很多同仁在停管理服务器之前就急着执行opatch导致OPatch在处理替换文件时提示文件被占用。所有服务必须彻底停掉再进入下一步这是原则不是建议。3.2 解压补丁包的正确位置和方式补丁包上传到服务器后在Middleware Home之外的临时目录解压。注意不要在Middleware Home目录内直接解压更不要解压到WebLogic安装目录中。补丁目录只是OPatch读取的只读输入不参与中间件运行放安装目录里反而可能污染环境变量查找路径。解压操作cd /app/weblogic/patch unzip p33385024_121300_Generic.zip -d p33385024 cd p33385024解压完成后先看目录内容其中有一个以补丁编号命名的子目录里面包含etc/、files/等文件夹以及补丁特定的脚本。部分补丁包还包含多个独立目录这时要仔细看README确认哪个目录是需要apply的目标补丁。3.3 执行 opatch apply 的完整现场补丁目录准备好之后切换到Oracle软件安装用户我们环境里一般是weblogic用户进入OPatch目录执行apply。命令格式cd $MW_HOME/OPatch ./opatch apply /app/weblogic/patch/p33385024/33385024执行过程中OPatch会先做预检查包括检查补丁编号和Oracle Home组件匹配情况。检查兼容性冲突如果存在冲突补丁OPatch会列出冲突清单。有些补丁之间是互斥的需要先卸载旧补丁或者使用force参数但生产环境我不建议使用force除非严格评估过后果。生成备份文件开始替换或新增文件。执行过程中观察输出重点看每一行是否报ERROR或WARN。有些WARN是正常提示比如关于旧配置文件被保留的提示但涉及版本冲突的WARN就要停下来分析。整个apply过程结束时的核心提示是一段类似OPatch succeeded.或Patch 33385024 successfully applied.看到succeeded才能认为安装成功。如果中途失败OPatch通常会自动回滚已做的文件变更但输出中会有OPatch failed和具体错误码这时候不要盲目重跑要先看清楚失败阶段。3.4 补丁验证与启动确认补丁应用成功后验证动作同样重要。常用的验证手段有三个执行./opatch lsinventory看到补丁编号和补丁描述在列表内。查看补丁所在目录的日志文件确认没有应用过程的异常记录。启动管理服务器和受管服务器观察日志中是否出现版本匹配错误、类加载异常等。启动顺序与停机顺序相反先启动NodeManager再启动管理服务器最后逐台启动受管服务器。WebLogic启动时如果补丁与版本不兼容常会在日志中抛出UnsupportedClassVersionError或NoClassDefFoundError一旦出现这类异常优先怀疑补丁文件替换不完整。启动成功后还需要登录WebLogic控制台检查各服务的健康状态必要时调用几个核心接口做冒烟测试。4. 常见报错与回滚把这些坑提前排掉补丁安装过程中一定会遇到的坑我把这些年排查的经验整理成了一份速查表遇到问题可以按图索骥。4.1 环境类报错空间、权限与临时目录报错关键字原因处理方式Unable to create local file临时目录空间不足或权限不足清理临时文件检查目录权限扩展磁盘Insufficient space备份区域空间不够为Middleware Home所在文件系统预留充足空间Permission denied当前用户对ORACLE_HOME无写权限切换软件安装用户通过sudo或su这类问题看似简单但生产环境中经常遇到“有空间但目录挂载点不同”的情况。比如/tmp和/app是不同分区/tmp满了但/app有大量空余OPatch同样会失败。所以检查空间时要看OPatch实际使用的目录所在分区。4.2 OPatch 版本不满足要求时的处理OPatch版本过低时报错一般类似This OPatch version is too low to support the patch处理方法不是绕过而是升级OPatch。到MOS下载与WebLogic版本匹配的OPatch工具包解压后备份原目录再替换。升级后重新执行“SystemPrereqs检查”然后再跑apply。这个过程中有个细节OPatch工具包解压后目录名通常带日期或版本号正式替换时要注意确保脚本执行权限避免因权限缺失导致新工具无法运行。4.3 补丁应用失败后的回滚操作只要OPatch应用过程中创建了备份理论上就可以回滚。回滚命令cd $MW_HOME/OPatch ./opatch rollback -id 33385024回滚的适用场景包括补丁导致启动异常、业务接口报错、应用不兼容等。这里要特别提醒回滚前必须再次停止WebLogic Server理由与安装时一致。曾经有一次我图省事在管理服务器运行状态下直接执行rollback结果OPatch提示文件被占用回滚到一半才报错后续清理非常被动。回滚完成后再执行一次lsinventory确认补丁已从列表移除然后重启服务验证。4.4 安装后启动故障检查补丁应用成功但服务起不来这种场景最让人头疼。常规检查路径如下看启动日志最后500行定位关键异常代码。常见的是类文件缺失、版本不一致、配置文件解析失败。清理WebLogic缓存后重启。缓存目录一般在domain的servers/servername/cache和tmp下安全做法是备份这两个目录后删除。很多类加载异常其实是旧缓存导致的。如果涉及配置文件变化检查config.xml在备份前后的差异确认补丁没有把自定义配置重置。在这里分享一个我自己的操作习惯变更前把domain目录完整打成一个tar包单独存放补丁或回滚后再做一次diff对比能快速判断补丁是否修改了非预期范围内的内容。补丁变更不只是让文件替换成功更重要的是确保业务行为没有被破坏。这个内容后续如果想做得更省力可以进一步研究OPatchAuto的批量补丁能力它能把“检查、应用、回滚”整合成自动化流程适合多套环境统一处理。但对于单套环境的临时补丁手动走一遍这个流程反而更容易看清每一步发生了什么。本文还有配套的精品资源点击获取