简介适用于Oracle 11.2.0.4的补丁集更新PSU补丁号p33477185发布于2022年1月面向Linux x86-64平台。这份资源主要为数据库管理员与运维工程师提供安全更新与性能修复可在对应版本环境中离线应用。压缩包共3658个文件以共享库、目标文件、XML描述和SQL脚本为主同时包含jar、可执行文件等辅助组件整体约436.52MB便于在隔离网络下部署。已有854人学习下载。包内附带PatchSearch.xml等元数据可辅助核对补丁适用性结合OPatch工具完成安装后通常需要重启数据库并执行验证以吸收安全修复与已知问题补丁帮助保持数据库系统稳定、安全运行。1. 这不只是一个补丁包DBA 手里最需要较真的那 220 个文件如果你的生产库还跑在 Oracle 11.2.0.4 上那么DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64这个文件名会频繁出现在你的运维清单里。它不是什么新功能包也不是随手解压就能用的升级工具而是 Oracle 在 2022 年 1 月发布的季度补丁集更新PSU解决的是这个版本里累计暴露的安全漏洞和严重回归问题。很多 DBA 一看是 PSU 就往后拖觉得不升级不影响业务但等到等保测评或安全事故复盘时才发现补丁基线早就落后了。这篇文章要解决的是这个补丁包到底包含什么、怎么安全地打上去、打在哪些环境上、以及最容易踩的坑在哪。适合所有还在维护 11.2.0.4 生产库的 DBA、运维工程师和刚接手旧库的交付团队。2. 把一个补丁包拆开看PSU 里到底装了什么为什么必须按季度打2.1 从文件名反推补丁身份版本、日期、平台和补丁号怎么读Oracle 的补丁包命名并不是随意拼出来的DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64这串字符每一段都有明确含义。DB-PSU表示这是数据库组的补丁集更新不是 GI 补丁也不是 OJVM 补丁11.2.0.4是它所基于的主版本也就是 11g R2 的最终版本220118是发布日期的压缩写法22 代表 2022 年01 代表 1 月18 代表 18 日p33477185是 My Oracle Support 上的补丁号下载和检索全靠它最后的Linux-x86-64限定了操作系统平台不能跨平台使用。读懂文件名是第一步但真正决定能不能打的是当前环境的补丁基线。常见做法是登录服务器后用opatch lsinventory查看当前已经安装的补丁列表。如果之前已经打过更高版本的 PSU那么这个 220118 的补丁就不需要重复安装如果安装的是比它更早的 PSU则需要先确认中间有没有跳过必须安装的补丁。还有一种情况是环境里已经安装了单点补丁one-off patch这些补丁可能会和 PSU 产生冲突需要逐个核对。我一般会在动手前先用一条命令把 inventory 完整导出并保存作为后续变更的基准。# 切换到 oracle 用户并加载环境变量 su - oracle # 确认当前 ORACLE_HOME 指向正确 echo $ORACLE_HOME # 输出当前已安装补丁列表结果保存到文件用于对比 $ORACLE_HOME/OPatch/opatch lsinventory /tmp/opatch_before_220118.txt这条命令的逻辑很简单$ORACLE_HOME/OPatch/opatch是 Oracle 自带的补丁管理工具lsinventory子命令会读取$ORACLE_HOME/.patch_storage和 central inventory 中的记录输出所有已安装补丁的编号、描述和安装时间。输出内容里需要重点看两个字段一个是Patch后面的数字另一个是Installed后面的日期。如果输出里出现OPatch failed或者找不到 inventory 的报错说明这个环境的补丁管理元数据本身就有问题后续打补丁大概率会失败需要先解决 inventory 问题再继续。2.2 PSU 与 CPU、RU 的区别为什么 11.2.0.4 停更后 PSU 反而更关键Oracle 的补丁体系在 12.2 之后做过一次改名12.2 之前的季度补丁叫 PSUPatch Set Update和 CPUCritical Patch Update12.2 之后改叫 RURelease Update和 RURRelease Update Revision。它们的区别在于CPU 只修复安全漏洞内容更小风险更低PSU 除了安全修复还包含该季度内修复的高影响 bug内容和风险都比 CPU 大。而 11.2.0.4 已经是 11g 的最终版本没有升级路径所以 PSU 就成了这个版本获得修复的唯一渠道。这里有一个容易混淆的点很多人把 PSU 当成普通更新包觉得可打可不打。实际上Oracle 在 2015 年就结束了 11.2.0.4 的标准支持2020 年底结束了扩展支持如果企业没有额外购买持续支持服务那么 2022 年之后的季度补丁本身就是最后一个安全防线。这个 PSU 里包含的修复一部分是安全漏洞的累积修复一部分是影响数据库稳定性或正确性的 bug 修复。对于还在运行的 11.2.0.4 生产库不打这个补丁意味着这些已知问题一直存在打了则可能引入一些行为变化比如某些 SQL 的执行计划可能发生变化或者内部视图的返回格式改变。这就是为什么打之前必须先看 Release Notes 里的已知问题列表。选型上我建议遵循一个原则如果库里跑的业务是核心交易类系统以稳定优先PSU 应该尽量打最新的季度补丁而不是停留在某一个旧补丁上如果是测试或开发环境可以把补丁窗口与项目迭代节奏对齐但至少要在生产环境升级前完成兼容性验证。不要因为 11.2.0.4 已经停止标准支持就放弃维护恰恰因为旧版本安全补丁的价值才更高。2.3 决定要不要打这个补丁的三个判据不打 PSU 的风险不是立刻爆发而是在某个临界点集中出现。最重要的判据是安全合规要求等保测评、密评、行业监管检查都会检查数据库版本和补丁级别如果补丁基线过低会被直接判定为不符合要求。其次是业务是否受已知 bug 影响去 Release Notes 里翻一下这个 PSU 修复的 bug 列表看有没有当前库上出现过的问题比如 ORA-600、ora-04031、异常耗 CPU 等如果有这个补丁就应该尽快打。第三个判据是当前环境的补丁基线离这个 PSU 差多远差的季度越多打的时候需要处理的前置补丁和冲突就越多趁早打比攒一年再打容易得多。还有一个容易忽略的点是这个 PSU 支持的数据库版本范围它适用于 11.2.0.4 的 x86-64 Linux 平台不适用于 12c 或更高版本也不适用于 Oracle 9i/10g。如果服务器上是 Linux x86 的 32 位版本或者 AIX/Solaris都需要下载对应的平台补丁包。确认这三点之后再决定进不进入补丁安装流程。不要单凭文件名里的版本号就决定打先用opatch lsinventory和 Release Notes 做一次完整的确认这是每次补丁操作前必做的动作。3. 动手前必须做的活儿把环境校到可以打补丁的状态3.1 用 opatch lsinventory 做第一次体检打补丁之前的检查不是走流程而是在为自己的操作降低回滚成本。第一次体检要确认四件事当前补丁基线、ORACLE_HOME 的 opatch 版本、是否有残留的失败安装记录、以及数据库和监听进程是否已经准备好停机窗口。其中 opatch 版本经常被忽略。Oracle 11.2.0.4 早期自带的 opatch 版本可能过旧而较新的 PSU 补丁对 opatch 的最低版本有要求。检查方法是用opatch version如果版本过低需要到 My Oracle Support 下载最新的 opatch 并将$ORACLE_HOME/OPatch替换掉。替换前记得备份原目录替换后再次执行opatch version确认版本已经更新。第二个容易忽略的点是数据库实例是否处于正常运行状态。打 PSU 的过程会替换数据库的可执行文件正常情况下数据库不需要关闭但如果你打算同时执行catbundle.sql去更新数据字典数据库就必须处于 mount 或 open 状态。至于打补丁前是否需要关闭实例取决于你用的是传统opatch apply还是opatch auto前者可以不停库后者会管理整个集群级别的升级。但不管用哪种方式我都建议在补丁窗口内完成全部操作不要让补丁安装在业务高峰时段进行。# 检查 opatch 版本确认满足补丁最低要求 $ORACLE_HOME/OPatch/opatch version # 用 opatch 检查补丁依赖重点看前置补丁是否满足 $ORACLE_HOME/OPatch/opatch prereq CheckApplicable -ph /tmp/33477185/33477185 # 查看当前补丁列表并输出详细内容 $ORACLE_HOME/OPatch/opatch lsinventory -detail /tmp/opatch_detail_before.txtopatch prereq CheckApplicable是一个很实用的预检命令它会模拟补丁安装过程检查当前的 ORACLE_HOME 是否满足这个补丁的依赖条件。输出里如果有缺失项需要先安装前置补丁如果有冲突项需要确认是覆盖关系还是排斥关系。命令执行完成后把/tmp/opatch_detail_before.txt保存好回滚时它是最好的对照物。执行 lsinventory 时要注意权限问题必须以 oracle 用户执行不是 root否则会读不到 inventory 报错。3.2 检查补丁冲突为什么同一台库不能同时打两个 PSU补丁冲突是打 PSU 时最让人头疼的问题。Oracle 补丁体系里同一类补丁是按时间线累积的较新的 PSU 已经包含了之前 PSU 的内容所以不能在同一 ORACLE_HOME 里同时存在两个 PSU。如果你之前打过p33477185之前的某个 PSU而那个 PSU 里有一个已经被新 PSU 修复的 bug那么新 PSU 安装时会因为文件版本冲突而拒绝安装。冲突检测会在opatch apply阶段自动进行报错信息里会说明哪个补丁与哪个补丁冲突以及冲突的具体文件。处理冲突的做法有三种第一种是如果旧 PSU 的内容已被新 PSU 完全覆盖直接用opatch rollback把旧 PSU 回滚掉再安装新 PSU第二种是如果旧补丁是单点修复one-off fix确认它修复的问题在新 PSU 里已经存在直接卸载旧补丁第三种是如果旧补丁修复的问题在新 PSU 里面没有对应修复则需要先联系 Oracle 支持确认两者能否共存不能共存时以安全补丁为优先。这里最容易犯的错误是直接在已安装旧 PSU 的环境上执行新 PSU 的安装报错后不分析原因就强制覆盖这会导致 inventory 记录和实际文件状态不一致后续再做任何补丁操作都会失败。# 查看当前环境已安装的所有补丁确认是否有旧 PSU $ORACLE_HOME/OPatch/opatch lsinventory | grep -Ei PSU|CPU|patch # 用补丁自带的依赖文件检查列出需要满足的前置补丁号 ls /tmp/33477185/33477185/etc/config/actions.xml /dev/null 21 echo 补丁目录结构存在在实际操作中我会在 lsinventory 输出里先找到 PSU 对应的补丁号然后确认这个补丁是在新 PSU 发布之前还是之后。如果环境里已经有比这个 PSU 更新的单点补丁那么大多数情况下不能直接安装先卸载较新的单点补丁再装 PSU装完后再重新打那个单点补丁。这个顺序不能反过来否则opatch apply会在检查阶段直接报错。3.3 备份与回滚策略打补丁之前必须留下的三样东西补丁操作的后悔药有三样ORACLE_HOME 的完整备份、数据库的当前状态记录、以及opatch lsinventory -detail的输出。其中 ORACLE_HOME 的备份是整个回滚的基础。对于 11.2.0.4ORACLE_HOME 目录一般在 6~10 GB 左右用tar打包需要十来分钟但这是所有回滚方案里最可靠的一种。数据库可以用冷备或expdp导出但 11.2.0.4 的 PSU 打补丁并不要求数据库全备因为补丁本身不修改数据字典内容除非你随后执行catbundle.sql。不过我的习惯是只要涉及生产库不管官方要求与否数据库库的备份至少保留一份不然在 catbundle 阶段如果有点小问题卡住你会很被动。补丁安装前的现状记录也很重要特别是各监听、ASM、集群资源的状态。打补丁后如果与现有环境不兼容需要恢复到原状没有 lsinventory 输出作为对照回滚时连哪些设置是原始状态都不确定。备份的具体策略见下表备份对象方式大小用途ORACLE_HOMEtar -czf6~10 GB回滚二进制文件状态数据库expdp或冷备视数据量防止 catbundle 阶段出问题补丁基线opatch lsinventory -detail几 KB对照安装前后差异这个表里的备份是有优先级的。ORACLE_HOME 的备份和 lsinventory 输出是必须的数据库备份在窗口时间允许的情况下做如果窗口非常短至少也要有最近一次的全备。打完补丁后只要发现二进制文件层面的异常先回滚 ORACLE_HOME 是最快的方式不需要动用数据库备份。只有catbundle.sql执行失败且修复不了时才需要考虑从数据库备份恢复。4. 把补丁打上去opatch apply 与 catbundle 的实操细节4.1 用 opatch apply 打补丁最小命令与后台日志安装 PSU 的过程分成两个阶段第一阶段用opatch apply替换二进制文件第二阶段用catbundle.sql更新数据字典。第一阶段相对直接但有几个细节需要注意。首先补丁包解压后要确认目录归属33477185目录必须属于 oracle 用户否则 opatch 在读取时需要切换权限容易在安装中途失败。其次执行 opatch apply 的环境变量必须正确ORACLE_HOME指向目标数据库的安装目录PATH里包含$ORACLE_HOME/binLD_LIBRARY_PATH不能指向其他版本的 Oracle 库否则 opatch 在启动时会加载错误的库文件导致报错。# 解压补丁包并设置权限 unzip -q /tmp/p33477185_112040_Linux-x86-64.zip -d /tmp/33477185 chown -R oracle:oinstall /tmp/33477185 # 切换到 oracle 用户确认环境变量 su - oracle export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export LD_LIBRARY_PATH$ORACLE_HOME/lib cd /tmp/33477185/33477185 # 执行补丁安装并通过日志实时观察 $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME /tmp/opatch_apply_220118.log 21 tail -f /tmp/opatch_apply_220118.logopatch apply是核心命令-oh参数指定 ORACLE_HOME实际安装的日志会写到当前目录的opatch子目录下。后台执行并用tail -f观察是比较稳妥的做法因为补丁安装可能需要几分钟到几十分钟不等前台执行一旦终端断开就会中断。安装过程中日志里会出现类似Patch applied successfully的提示如果中途出现ERROR或WARNING不要立刻终止先把日志保存好然后根据报错信息判断是继续还是回滚。补丁阶段安装完成后不一定要关闭数据库因为 Oracle 的替换文件不影响已连接会话的句柄但如果你接下来要执行catbundle.sql就需要数据库处于正常 open 状态。有一点需要特别强调opatch apply安装的是文件层级的补丁它不会修改数据字典。这也是为什么很多 DBA 打完补丁直接重启数据库就完事数据字典版本和补丁版本不一致后续可能出现缓存失效或执行计划异常。所以catbundle.sql这个步骤不能跳过。4.2 打补丁后必须执行的 SQL 脚本catbundle.sql 和数据字典校验打完 PSU 之后Release Notes 里都会要求执行$ORACLE_HOME/rdbms/admin/catbundle.sql参数带上psu apply。这个脚本做的事情是更新数据字典中的补丁版本记录将dba_registry_sqlpatch和dba_registry_history同步到当前 PSU 的版本。不执行这个脚本的后果是数据库实例可以正常运行但 Oracle 内部认为系统仍然处于旧的补丁基线后续安装任何补丁、执行datapatch、或者做健康检查时都会因为数据字典版本不一致而报错。更严重的是数据库中某些字典对象的定义会和新二进制文件不匹配后续访问这些对象时可能出现内部错误。-- 使用 sysdba 登录在 SQL*Plus 里执行脚本 sqlplus / as sysdba -- 切换到 PDB/CDB 模式开始执行 -- 注意11g 没有多租户直接执行即可 ?/rdbms/admin/catbundle.sql psu apply -- 执行完毕后查看补丁版本记录 SELECT version, id, status, action, action_time FROM dba_registry_sqlpatch ORDER BY action_time;执行catbundle.sql的要点是必须用 sysdba 登录而且数据库必须处于 open 状态。脚本执行时间一般在 5 到 20 分钟取决于数据字典里面对象数量。如果数据库是 RAC 环境只在一个节点上执行即可不需要每个节点都跑。脚本执行完成后用上面那条 SQL 查看dba_registry_sqlpatch正常情况下会看到一条id与补丁号相关的记录比如12397321或直接显示 PSU 编号status为SUCCESS。如果状态不是SUCCESS需要去查看registry$sqlpatch记录和alert日志找出失败原因再决定是否重跑脚本。这里有个常见坑catbundle.sql在早期版本里会在执行过程中产生严重的解析压力如果系统负载很高建议先停掉批处理任务再跑。4.3 重启与不重启的决定何时可以用 opatch auto 避免全部重启打完 PSU 和 catbundle 之后数据库是否需要重启取决于你使用的是哪一类补丁。对于 11.2.0.4 的 PSU大部分动态库和可执行文件的替换已经在opatch apply阶段完成正在运行的后台进程不受影响所以只要不重启数据库旧的进程镜像会继续保持运行实际上现在使用的仍然是旧版本的代码这不满足补丁生效的要求。严格来说PSU 里修复的很多问题需要在数据库重启之后才能让新代码完全接管。这就是为什么 Oracle 建议在维护窗口内完成打补丁并重启数据库。如果你的环境是 RAC可以采用滚动方式一个节点一个节点重启逐个重启实例避免整体停机。opatch auto是另一种选择它的用途不是避免重启而是帮你自动执行补丁安装和对应资源的重启适用于 Grid Infrastructure 环境。它会依次检查各节点执行补丁安装并根据补丁类型决定是重启整个集群还是只重启数据库实例。使用opatch auto的前提是 current working directory 里已经准备好了补丁目录并且需要 root 权限执行。如果你只有一套单机环境用opatch auto并不会比传统方式更省事反而因为自动化程度高出错后不好追踪。我建议单机环境用传统opatch applyRAC 环境且补丁涉及 GI 层面时用opatch auto。# 确认补丁安装完成状态为 applied $ORACLE_HOME/OPatch/opatch lsinventory | grep 33477185 # RAC 环境查看集群状态决定重启顺序 crsctl status resource -t # 重启数据库实例后检查进程版本是否已更新 sqlplus / as sysdba SELECT * FROM v$version;执行到这一步意味着补丁已经进入收尾阶段。最后要提醒的是补丁装完不是说结束就结束必须做一轮完整的功能验证包括应用登录、关键事务跑通、备份作业正常执行。如果验证阶段发现任何异常优先用opatch rollback回滚二进制再执行相应的数据字典回滚脚本回到预检查阶段的基线。5. 避坑把 p33477185 最容易翻车的 5 个姿势写清楚5.1 现象opatch 报 “Prerequisite check failed”原因当前 ORACLE_HOME 缺少该 PSU 要求的前置补丁或者 opatch 版本过低导致无法正确解析补丁元数据有时也会因为 Central Inventory 里记录了损坏的历史信息。最常见的还是前置补丁未满足比如某些 PSU 要求此前必须已经安装了特定的 CPU 或 PSU。解决先用opatch lsinventory查看已装补丁去 My Oracle Support 页面上该补丁的 README 里找到 Prerequisite 列表逐一对照。缺失的补丁先下载安装再回头执行opatch apply。如果是 opatch 版本过低更新 opatch 后重试。注意更新 opatch 前先把原$ORACLE_HOME/OPatch目录备份因为版本更新失败时没有备份会连原始的 opatch 都无法使用。5.2 现象打补丁后数据库起不来监听也起不来原因这种情况常发生在打补丁过程中环境变量没有正确加载比如用su - oracle而不是su oracle导致登录后ORACLE_HOME和PATH没有刷新成新值或者 ORACLE_HOME 的权限在补丁安装过程中被改动过导致数据库进程没有权限读取可执行文件。解决先用echo $ORACLE_HOME和which sqlplus检查环境是否符合预期再检查$ORACLE_HOME/bin下oracle可执行文件的属主和权限属主应该是 oracle权限至少 755。如果权限被改坏用chown -R oracle:oinstall $ORACLE_HOME修复。这一步解决不了时直接从 ORACLE_HOME 备份中恢复重新执行打补丁流程不要试图在损坏的二进制上修补。数据库起不来时先看alert_sid.log报错信息里通常会有明确的原因指向。5.3 现象catbundle.sql 执行报 ORA-04021原因ORA-04021 表示数据库里其他会话正在占用 library cache 中的某个对象或者对象正在被编译。这个报错在打补丁的窗口期很常见因为你可能没有停掉应用的连接或者还有计划任务正在运行与catbundle.sql要更新的对象产生了冲突。解决在维护窗口内打补丁时先确认没有应用连接在跑 DDL 或批量编译操作可以查询v$session里是否存在正在执行 DDL 的会话。最简单的方法是提前停掉应用关闭外部的定时任务只保留 DBA 的维护会话。如果 ORA-04021 已经出现可以先定位阻塞源用SELECT * FROM v$lock WHERE type DL查看进程持有锁的情况确认为编译锁冲突后等待持有会话结束后重启执行catbundle.sql。不要反复重启数据库来规避问题通常不在数据库重启而在并发会话。5.4 现象执行 opatch apply 时发现另一个 opatch 会话在跑原因这是多人在同一台服务器上合作的典型问题。补丁目录可能被共享或者前一个打补丁的人操作中断后没有清理opatch 自带的锁机制检测到$ORACLE_HOME/.patch_storage或 inventory 被占用直接报错退出。另一种可能是在同一个 ORACLE_HOME 上并发了两个 opatch 操作。解决先使用ps -ef | grep opatch查看是否确实有残留进程确认是残留进程就直接kill并删除 opatch 退出时残留的oraInventory锁文件。如果是因为有另一个任务正在安装补丁那就必须先等待它完成。我的习惯是在打补丁前用ps -ef | grep -E opatch|datapatch检查一遍避免这种无谓的报错导致补丁窗口浪费。5.5 现象打补丁后应用系统报驱动与数据库版本不一致原因数据库的某些内部字段或行为因为补丁更新发生了变化而应用连接池里的 JDBC 驱动版本过旧。典型场景是 Kettle 连接 Oracle 时使用ojdbc6.jar而版本还是 11.1 或更老打补丁前数据库对此兼容打补丁后某些特性或内部协议产生了不兼容。报错表现为连接失败或ORA-03134之类的驱动版本错误。解决确认应用使用的ojdbc6.jar版本是否为 11.2.0.4 及以上如果不是需要在应用端替换驱动。对于 Kettle 这类 ETL 工具直接把lib目录下的旧驱动替换成新的并重启 Kettle 进程。替换驱动后不用回滚数据库补丁驱动版本问题与应用有关跟数据库二进制无关。需要注意的是驱动是链接在应用端 classpath 里的不是数据库端的文件这个边界要分清楚。6. 打完之后怎么证明自己做对了验证和收尾的六个动作6.1 用 opatch lsinventory 确认补丁已 applied补丁装完后的第一件事不是急着入库验证业务而是确认补丁记录已经写入 inventory。执行opatch lsinventory在输出里找到33477185这一行确认状态为applied安装日期为当天。如果状态是not applied或者压根没有这一行说明补丁安装过程没有真正完成需要查看 opatch 日志确认。这个动作要和打补丁前的 lsinventory 输出做对比两边差异就能一目了然。# 确认补丁已写入 inventory $ORACLE_HOME/OPatch/opatch lsinventory | grep 33477185 # 输出示例中应有如下内容 # Patch 33477185 : applied on Wed Jan 19 10:22:34 CST 2022这一步是入库归档的凭证也是后续做补丁基线报告的依据。6.2 验证数据库版本和 PSU 版本一致性补丁安装完成后光看 opatch 输出还不够数据库内部也要确认。需要从 SQL 层面验证dba_registry_sqlpatch是否有对应的补丁记录并和opatch lsinventory输出的补丁号对应。-- 确认数据字典里的补丁记录 SELECT patch_id, action, status, action_time FROM dba_registry_sqlpatch WHERE patch_id 33477185; -- 确认数据库版本和补丁基线 SELECT * FROM registry$history;正常结果应当显示一条actionAPPLY、statusSUCCESS的记录。如果 SQL 查询不到说明catbundle.sql没有生效需要重跑。这一步做完后还要对数据库做一个基本的功能验证包括应用登录、事务提交回滚、常用存储过程编译。如果是 RAC把每个节点都测一遍避免因为只打了单节点补丁导致的版本不一致问题。6.3 打补丁后的收尾留档、更新运维脚本、通知下游补丁验证通过不代表工作结束收尾工作直接影响后续维护的顺利程度。需要做的事有三件第一把补丁号、安装时间、变更单号、回滚方式写入变更记录这个记录要放在运维文档里不能只存在个人笔记第二更新部署脚本或巡检脚本里的补丁基线版本否则下次巡检还会把当前环境识别为旧补丁第三发出通知给下游的应用开发和测试团队确认他们是否需要调整 JDBC 驱动或重新编译依赖了数据库的代码。下面这张表是留档信息的最小集。项目值补丁号p33477185补丁完整名称DB-PSU-11.2.0.4.220118 (Jan 2022)安装时间按实际时间填写变更单号CM-xxxx回滚方式opatch rollback -rollback_patch 33477185后重跑catbundle.sql回滚6.4 补丁管理的一点点经验版本基线比补丁本身更值钱打完这一个 PSU 后你会体会到补丁的安装过程本身并不算困难真正麻烦的是不知道当前环境处于哪个版本、和哪个补丁是配套关系、下次怎么追溯。我在维护多套 11.2.0.4 环境时会把每套环境维护一个补丁版本档案文件记录每个季度补丁的安装日期、操作人、回滚步骤以及对应的应用变更要求。这样每次升级只需打开档案就能判断是否漏打、是否有未完成的回滚任务不需要再逐台登服务器查。以后维护这套库时我还会坚持一个习惯每次补丁操作前强制先备份 ORACLE_HOME。很多人都嫌它耗时但它真的是回滚最容易的一粒后悔药。打完补丁之后不确认dba_registry_sqlpatch就走人的情况我也遇到过后来一次巡检数据时发现补丁版本不一致不得不重新安排维护窗口去补齐。打补丁这件事不需要多聪明耐心把检查做完、把记录留清楚就不会出大问题。希望这篇文章能帮你在下一次 PSU 维护里省一些摸索的时间。本文还有配套的精品资源点击获取