企业官网建设流程全解析

简介：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.0，Generic表示这个包不区分操作系统，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目录下。覆盖前先备份原有 OPatch：

mv $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 执行 apply：opatch 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_202

3.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 2>&1 & # 查看启动日志 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 version

5.2 现象：apply 执行到一半报文件锁占用

执行opatch apply时，日志中提示某个 jar 包或目录被占用，无法覆盖写入。

原因：WebLogic 服务没有完全停干净。特别是 AdminServer 停了但某些托管进程还在跑，或 Java 进程的线程还没完全释放文件句柄。

解决：先查进程，再决定是否强制结束。确认所有 weblogic 进程都不存在后再重新执行 apply。如果之前 apply 已经在半途失败，不要在同一目录直接再跑，先做一次回滚再重打。

ps -ef | grep weblogic | grep -v grep kill -9 [pid] # 确认进程消失 jps -l

5.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_ID=33385024 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 版本，宁可多花十分钟做备份，也不在出错后花一小时找后悔药。希望帮到你。

本文还有配套的精品资源，点击获取