简介这是一份面向Oracle数据库管理员的补丁更新包适用于Linux x86-64平台上的Oracle 11.2.0.4版本补丁编号p33477185属于2022年1月发布的Patch Set UpdatePSU旨在修复安全漏洞并提升数据库运行稳定性与性能。压缩包共3658个文件以so共享库和o目标文件为主分别达1619和1421个这些是补丁的核心编译产物同时包含182个xml、142个sql以及plb、class等脚本与配置用于执行数据库对象变更和补丁验证整体大小约436.52MB。包内PatchSearch.xml提供了补丁适用条件和安装校验信息33477185文件则为实际补丁程序。目前已有856人学习下载适合需要为生产环境打补丁、做季度更新的DBA参考使用。通过此补丁包使用者能够获取完整的补丁实体与元数据快速完成兼容性检查、OPatch部署以及补丁后的验证工作有效保障Oracle数据库系统安全高效运行。1. 这个补丁包是什么DB-PSU-11.2.0.4.220118 能解决的问题和适用人群DB-PSU-11.2.0.4.220118 是 Oracle 11.2.0.4 数据库在 2022 年 1 月发布的补丁集更新Patch Set Update补丁包编号 p33477185平台是 Linux x86-64。维护 11.2.0.4 的人都清楚这个版本早已过了免费支持期安全漏洞和已知 bug 的修复全靠周期性 PSU 撑着。一个反直觉的现象是很多库打上 PSU 之后之前时不时出现的 ORA-07445 和性能退化瞬间消失并不是补丁包改了什么玄学配置而是它把此前所有已知问题的修复都累积了进来。本文要讲清楚这个补丁包从下载、检查、安装、验证到回滚的完整操作路径适合正在维护 11.2.0.4 生产库、准备在下个维护窗口打补丁的 DBA也适合刚接手老旧数据库的运维工程师照着做一套标准流程。2. 为什么选 PSU 而不是 BP 或 RU11.2.0.4 的补丁体系与选型2.1 PSU、BP、RU 三种补丁方式的差异在 11.2.0.4 这个版本上官方主推的补丁模式是 PSU这一点很多从 12c 之后才接触 Oracle 的人容易混淆。12c 之后每个季度发布的叫 Release UpdateRU安装包命名和 PSU 完全不同目录结构也不一样而 11.2.0.4 的 RU 通常由支持团队按需签发绝大多数普通用户根本拿不到。真正面向一般用户只有两类PSU 和 BPBundle Patch。PSU 是累积性的补丁集每个季度新 PSU 都包含之前所有 PSU 已经修复的问题BP 早期主要用于 Windows 平台后来部分 Unix 平台也有但 BP 和 PSU 在同一套环境里互斥不能同时打在同一 ORACLE_HOME 中所以大部分 Linux x86-64 用户选型时直接锁定 PSU。补丁类型适用版本发布频率覆盖范围累积性PSU11.2 及更早版本每季度安全补丁 高影响 bug 修复累积BP部分平台早期 Windows 为主不定期捆绑若干已知问题修复累积RU12.1 之后每季度安全补丁 普通 bug 修复累积还有一个容易忽略的点PSU 虽然是季度发布但并不是越新越好。很多 DBA 习惯拿到最新 PSU 就打上去结果在生产环境里碰到补丁本身引入的新问题反而比不打的损失更大。业内通行的做法是避开刚发布一个月以内的新 PSU优先选择发布超过一个季度、已经被大量生产环境验证过的版本。DB-PSU-11.2.0.4.220118 是 2022 年 1 月的包部署之前要确认它有没有被后续 PSU 覆盖或标记废弃再决定是直接打这个还是跳过它打更新的季度包。12c 时代大家熟悉的 RU 命名是类似 12.1.0.2.2301 的格式和 PSU 的日期编码很像但实际安装方式不同RU 补丁包里除了二进制替换还带一个独立的 datapatch 工具做数据字典升级而 11.2.0.4 的 PSU 数据字典升级入口还是 catbundle.sql这两个流程不能互相替代。如果你平时管的是 19c 库突然接手一台 11.2.0.4最容易犯的错就是把 RU 的安装习惯搬到 PSU 上到处找 datapatch 命令实际上 11.2.0.4 根本没有这个工具。我一般会先跑一遍 opatch lsinventory看看当前环境是什么补丁基线再判断该走哪条流程。2.2 读懂 DB-PSU-11.2.0.4.220118 补丁包名称版本、日期、平台与依赖DB-PSU-11.2.0.4.220118 这串名字里包含关键信息DB-PSU 表示数据库的补丁集更新11.2.0.4 是基线数据库版本220118 是日历日期编码按 YYMMDD 理解即 2022 年 1 月 18 日对应 2022 年 1 月的 PSU 序列。p33477185 是补丁包在官方补丁检索系统里的编号下载时输入的就是这个 ID解压后得到的目录名也直接叫 33477185。最后的 Linux-x86-64 限定了操作系统与芯片架构绝对不能拿到 AIX 或 Solaris 的机器上用这是新手最容易翻车的点之一。关于依赖关系一个常见误区是认为这个 PSU 会依赖更早的旧 PSU 必须先装。实际上 PSU 是累积的p33477185 本身就包含前面每一个季度 PSU 的内容所以只需要基线是 11.2.0.4不需要提前装任何旧 PSU。它真正依赖的是两样东西一是 OPatch 工具的版本不能太老二是如果这台机器上同时安装了 Grid InfrastructureGIGI 侧的补丁版本要和 DB 侧匹配。官方 README 会明确写出最低 OPatch 版本要求和配套 GI PSU 补丁号下载完补丁包第一步永远是解压后打开 README先确认这两个数字再谈安装。另外注意补丁包里的子目录结构。解压 p33477185 之后通常会看到 33477185 主目录里面才是真正的补丁文件opatch 命令要从这个目录执行而不是从解压后的顶级目录直接执行。补丁包里还可能包含 readme 目录和 etc 目录这些是 opatch 运行时读取的辅助目录不要去手工改动。习惯上我会把整个解压目录放在 ORACLE_HOME 外面比如 /u01/patches 下避免 apply 过程中由于目录嵌套或权限问题误伤 ORACLE_HOME 内部文件。3. 安装前准备环境检查、备份与回滚预案3.1 检查补丁包完整性与 OPatch 版本所有生产环境的补丁操作第一步都应该是验证补丁包没有在下载或传输过程中损坏。补丁包在官方页面下载时会附带校验和下载完成后第一时间在目标机器上比对。Linux 下常用 md5sum 和 sha1sum如果校验值对不上直接重新下载省得安装到一半才报错那种情况清理现场非常痛苦。# 进入补丁包所在目录校验 zip 包的完整性 cd /u01/patches md5sum p33477185_112040_Linux-x86-64.zip sha1sum p33477185_112040_Linux-x86-64.zip # 解压补丁包 unzip -q p33477185_112040_Linux-x86-64.zip # 确认解压出来的目录结构 ls -d 33477185 ls 33477185这里把校验和比对结果和官方页面上的值进行人工核对不能只看命令能跑完就放过。unzip -q 是静默解压在此之前先跑一遍 unzip -t 做测试性解压更稳妥如果 zip 文件本身有问题-t 会直接给出 CRC 错误提示比解压到一半再报错更早暴露问题。OPatch 版本检查是另一道生死线。11.2.0.4 的 PSU 通常要求 OPatch 到某个特定版本以上具体数字在补丁包自带的 README 里写得很清楚。检查当前版本只需要一条命令# 检查 OPatch 版本 $ORACLE_HOME/OPatch/opatch version如果版本低于 README 要求先停止一切安装动作从官方补丁站点下载对应平台的 OPatch 替换包按说明替换 $ORACLE_HOME/OPatch 目录然后重新执行 version 命令确认。切记不要跨版本直接拿 12c 的 OPatch 替换到 11.2.0.4 的 ORACLE_HOME会造成命令格式不兼容反而把环境搞坏。3.2 备份数据库与 ORACLE_HOME 的三种方式打补丁属于高风险变更回滚预案不是可选项是必选项。11.2.0.4 的库哪怕是 RAC备份策略也可以很简单但一定要三样同时做ORACLE_HOME 目录打包、RMAN 全备、spfile 与控制文件的独立备份。# 方式一ORACLE_HOME 整体压缩备份 # 排除大目录临时文件、网络日志不要打进包里 tar czf /backup/oracle_home_$(date %Y%m%d).tar.gz \ --exclude$ORACLE_HOME/trace \ --exclude$ORACLE_HOME/network/log \ $ORACLE_HOME # 方式二RMAN 全备进入 rman 后执行 # RMAN backup database plus archivelog;方式一的 tar 备份是整个回滚预案的地基opatch 打补丁时会修改 ORACLE_HOME 里的一批可执行文件和共享库如果 apply 过程中发生文件损坏或者想整体退回直接把 tar 包解压回去是最快最稳的方案。tar 的时候要格外注意别把中间件或其他应用在 ORACLE_HOME 里创建的临时文件一并打包备份包越纯净恢复越快。RMAN 全备保护的是数据库文件本身。虽然 PSU 通常不碰数据文件但 catbundle.sql 升级数据字典一旦因为人为失误或断电中断数据库可能起不来这时 RMAN 备份就是最后的安全网。spfile 和控制文件的备份可以放进同一个 RMAN 会话不过我习惯额外用一条命令把参数文件导出成文本作为快速排查的参照物-- 在 sqlplus 里导出参数文件和记录控制文件位置 SQL create pfile/backup/init_$(date %Y%m%d).ora from spfile; SQL select name from v$controlfile;3.3 用 opatch prereq 做 DB-PSU 的冲突与依赖预检备份做完了还不能直接 apply。官方 opatch 提供了一套预检命令能把空间不足、补丁冲突、依赖缺失三类问题提前揪出来避免正式窗口打开之后才发现装不上。我的习惯是在打补丁前至少两天做一次预检把输出日志存档正式窗口开始时再快速重跑一遍确认环境没有变化。# 检查系统空间是否满足补丁包需求 cd /u01/patches/33477185 $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -oh $ORACLE_HOME # 检查与当前 ORACLE_HOME 已安装补丁的冲突 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -oh $ORACLE_HOME # 生成 apply 预演报告不实际修改环境 $ORACLE_HOME/OPatch/opatch apply -report -oh $ORACLE_HOME三条命令的核心差异要说清楚CheckSystemSpace 输出各目录的剩余空间需求和实际值如果 ORACLE_HOME 所在分区小于 1.5 倍 ORACLE_HOME 体积大概率报红CheckConflictAgainstOHWithDetail 检查当前库里已有补丁是否和这个 PSU 冲突打过 BP 的环境尤其要关注apply -report 在内存里模拟一遍 apply 流程输出详细的文件变更清单不落盘、不碰任何二进制文件可以放心在生产库上执行。预检通过之后还不能马上 apply需要再确认两件事一是 ORACLE_HOME 相关环境变量是否干净ORACLE_UNQNAME、ORACLE_SID 是否设置正确二是当前是否还有会话连着数据库应用连接池里的长连接会在 shutdown immediate 时拖慢停止速度严重的会耗掉大半个维护窗口。我的做法是在窗口开始前先查一下活跃会话提前和应用团队约定断开时间。4. 打上 PSU从停库到 catbundle.sql 的完整步骤4.1 用 opatch apply 打上 DB-PSU-11.2.0.4.220118 的标准命令序列准备做完正式窗口就可以按固定序列执行了。核心三步不变停止数据库和监听、执行 opatch apply、启动数据库后升级数据字典。下面先给出一套单机环境的完整命令序列然后逐段解释参数作用。# 设置环境变量 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH export ORACLE_SIDorcl # 停监听 lsnrctl stop # 停数据库 sqlplus / as sysdba SQL shutdown immediate; SQL exit; # 执行补丁 cd /u01/patches/33477185 $ORACLE_HOME/OPatch/opatch applyopatch apply 进入交互模式开始前打印补丁信息和目标 ORACLE_HOME并询问是否继续输入 y 回车。整个过程显示处理百分比耗时取决于 ORACLE_HOME 大小和磁盘速度一般十分钟到半小时不等中间不要 CtrlC 中断否则容易留下半替换状态。如果希望全程无人值守可以加 -silent 参数但实际生产我反而更推荐交互模式因为每到一个关键节点它都会明确打印当前动作方便操作人员确认进度。命令里还有两个参数值得说明。一个是 -oh当环境变量 ORACLE_HOME 没有正确导入时用 -oh 显式指定目标避免 opatch 找错 home这在同时装了多套数据库软件的机器上尤其重要另一个是 -local只在 RAC 滚动打补丁场景下使用表示只处理当前节点的 ORACLE_HOME不会广播到其他节点。单机环境不要加 -local加了反而会导致补丁状态在不同节点间不一致。4.2 实例、监听器与 ASM 的启停顺序启停顺序最容易出错的是 RAC 和多实例环境。单机环境先把监听停了再停库顺序反了会导致 shutdown 过程中新连接不断进来明明可以 immediate 关闭的实例硬生生拖到 abort。RAC 环境则要求先通过 srvctl 禁用数据库资源的自动启动再对每个节点单独停止服务# RAC 环境操作序列每个节点轮流执行 srvctl stop database -d orcl srvctl stop instance -d orcl -i orcl1 # 在节点1上本地执行补丁 ssh node1 cd /u01/patches/33477185 $ORACLE_HOME/OPatch/opatch apply -local -oh $ORACLE_HOME # 完成后启动节点1实例 srvctl start instance -d orcl -i orcl1RAC 滚动打补丁的要点是保持集群中至少一个节点提供服务所以每个节点独立 apply、独立启动全部节点打完后再启动数据库整体资源。这里有一个隐含依赖如果机器同时安装了 Grid InfrastructureDB PSU 要求 GI 侧已经处于可兼容的补丁基线否则数据库在 Cluster Ready Services 层注册时会报错。这个顺序是最常见的翻车点正确做法是先打 GI PSU 再打 DB PSU两者版本要在配套表里对齐。ASM 实例通常随 GI 管理不需要单独停。但如果你用的是没有纳入 GI srvctl 管理的 ASM 实例打补丁前要把 ASM 实例也 shutdown并确认 ASMSNMP 用户的认证方式避免补丁过程中 ASM 实例无法启动导致数据库实例跟着起不来。这个细节文档里写得细实际操作中很多 DBA 会漏。4.3 升级数据字典catbundle.sql 的执行二进制替换完成后最容易被跳过、也最不能跳过的步骤就是数据字典升级。很多 DBA 打完 opatch apply 就直接把库启动了业务一跑就报 ORA-04068 之类的 PL/SQL 错误就是这个环节没执行。11.2.0.4 的 PSU 数据字典升级入口是 catbundle.sql必须以 upgrade 模式启动数据库后执行# 启动到 upgrade 模式 sqlplus / as sysdba SQL startup upgrade; SQL ?/rdbms/admin/catbundle.sql PSU applycatbundle.sql 的参数中PSU 是固定标识apply 表示执行应用动作。这个脚本会遍历补丁包中的字典升级清单依次更新各个组件的数据字典、重新编译失效对象、更新版本元数据。执行过程中会产生大量日志输出建议直接重定向到日志文件便于事后审计sqlplus / as sysdba EOF startup upgrade; spool /backup/catbundle_apply.log ?/rdbms/admin/catbundle.sql PSU apply spool off shutdown immediate; startup; ?/rdbms/admin/utlrp.sql exit; EOF脚本执行完成后要立即关闭实例以 normal 模式重新启动然后运行 utlrp.sql 把仍然失效的 PL/SQL 对象再编译一次。判断标准很明确catbundle 日志里如果出现大量 ORA-XXXX 错误且不是已知忽略项说明字典升级没有干净结束此时绝对不要放业务流量继续排查问题必要时回滚重来。5. 验证、回滚与常见问题排查5.1 验证 DB-PSU-11.2.0.4.220118 生效的三种命令补丁完成后验证环节直接决定能不能放业务流量进来。我会同时用三种方式交叉确认opatch 层面的清单、数据字典的历史记录、告警日志中的版本信息。只看其中任何一种都有可能被假象骗过。# 方式一确认补丁出现在已安装清单里 $ORACLE_HOME/OPatch/opatch lsinventory | grep -i 33477185 # 方式二列出 ORACLE_HOME 实际生效的子补丁 $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep -i Patch description第一条命令返回 33477185说明二进制替换已经完成第二条可以看到补丁的具体描述验证平台和版本没有打错包。如果第一条有输出但第二条为空说明补丁状态异常需要查看 lsinventory 日志里是否有 failed inventory 的警告。数据字典层面的验证用 dba_registry_history这是 DBA 最直观的版本台账-- 查看 PSU 在当前库的历史记录 SELECT action, version, comments, action_time FROM dba_registry_history WHERE action LIKE APPLY% ORDER BY action_time; -- 查看数据库组件版本状态 SELECT comp_name, version, status FROM dba_registry ORDER BY comp_name;正常状态下dba_registry_history 里应新增一条 action 为 APPLY、version 包含 11.2.0.4.220118 的记录dba_registry 里各组件 status 都是 VALID。如果组件状态是 INVALID 或 DOWNGRADED说明 catbundle.sql 没有跑干净需要对照日志处理。告警日志的验证属于锦上添花但也有价值。用 tail 查看 alert_orcl.log如果 PSU 完整生效启动过程里通常会打印包含数据库版本升级信息的行和 dba_registry_history 里看到的版本号能对应上。5.2 回滚操作与前提条件回滚不是简单的 opatch rollback 一把梭。PSU 的回滚有严格的先后要求必须先回滚数据字典再回滚二进制。顺序反了字典版本比二进制新数据库启动后会出现对象版本不匹配应用报错比打补丁之前更严重。# 回滚步骤一以 upgrade 模式启动回滚数据字典 sqlplus / as sysdba SQL startup upgrade; SQL ?/rdbms/admin/catbundle.sql PSU rollback SQL shutdown immediate; SQL exit; # 回滚步骤二回滚二进制 cd /u01/patches/33477185 $ORACLE_HOME/OPatch/opatch rollback -id 33477185 # 回滚步骤三正常启动并重编译失效对象 sqlplus / as sysdba SQL startup; SQL ?/rdbms/admin/utlrp.sql回滚前还要确认一个前提这个 ORACLE_HOME 上不能存在比 p33477185 更新的补丁。如果有更新的 PSU 已经叠加上去直接回滚这个旧补丁会被 opatch 拒绝或者产生半回滚状态。正确做法是先回滚更新的补丁逐层回退到目标状态。另外如果执行过任何后续变更比如手工修改过字典对象或打过独立单补丁回滚的可行性就需要重新评估不能想当然。5.3 三个高频问题从 ORA-00942 到 opatch 报错下面三条是 11.2.0.4 打 PSU 过程中出现频率最高的故障按现象、原因、解决三步说明每条都是实际踩坑整理出来的。现象一catbundle.sql 执行时终端报 ORA-00942: table or view does not exist。 原因当前 sqlplus 连接不是 sysdba 权限或者数据库没有以 upgrade 模式打开。catbundle.sql 在普通用户 schema 下运行时访问系统表直接失败脚本自身不会给出友好提示。 解决确认执行前的连接身份是 sqlplus / as sysdba并检查 v$instance 的 status 是否为 UPGRADE。如果之前是 shutdown abort需要先 normal 启动再干净关闭然后重新 startup upgrade。现象二opatch apply 进行到一半报 Insufficient space日志文件戛然而止。 原因ORACLE_HOME 所在分区空间不足。opatch 在替换文件前会做全量备份需要的临时空间通常等于被替换文件的总大小分区剩余空间到临界值就会中断。 解决安装前用 df -h 预留至少 1.5 倍 ORACLE_HOME 体积的空间。已经卡住的话检查日志定位备份目录清理空间后从断点重跑或者恢复备份包后重新执行。现象三回滚时 opatch 提示 Patch 33477185 is not applied in the Oracle Home。 原因补丁清单里记录的补丁 ID 和回滚参数不一致或者先打了更新的补丁把这个 PSU 覆盖掉旧 ID 在清单中已被替换。 解决先用 opatch lsinventory 看当前实际安装的补丁 ID 与描述以输出为准如果确认被更高版本覆盖回滚策略改为在更高版本基础上做 forward 升级而不是强行回滚。6. 进阶技巧把 PSU 安装时间压缩一半的实操手法6.1 用 -report 预演报告做前置核查真正把安装时间压缩下来的不是 opatch 命令本身而是把原本用于停库之后才发现问题的检查全部前置。opatch apply -report 生成的预演报告会列出每一个待替换文件的源路径、目标路径、权限要求把这份报告提前发给应用团队和存储团队核对确认 ORACLE_HOME 里的文件级权限没有被人工改动过能避免很多半路发现的权限报错。6.2 多套 ORACLE_HOME 并行打补丁的注意事项生产机器上经常同时有几个数据库软件版本比如一套 11.2.0.4 的库给核心业务用另一套 12c 的库给测试用。两个不同版本的 ORACLE_HOME 打补丁互不依赖时可以用后台任务并行执行把维护窗口从串行的两小时压缩到一小时出头。并行时要注意磁盘 I/O同一块物理盘上同时打两个 PSUI/O 等待反而会让总耗时变长我的做法是把两个补丁目录放到不同文件系统或者错开半小时起步时间。数据字典升级不能在并行模式下跑仍然是每个实例单独串行执行。验证环节是我个人的小习惯打完补丁后第一时间把 opatch lsinventory 和 dba_registry_history 的输出归档到变更管理目录下次再打新季度 PSU 时翻一下上次归档五分钟就能确认当前环境起点不用重新猜测基线。早期我踩过最大的坑是图省事跳过了 catbundle.sql结果应用端报 ORA-04068后来老老实实把每个环节固定成脚本流程再没翻过车。希望帮到你。本文还有配套的精品资源点击获取
