简介该资源为 Oracle 数据库 11.2.0.4 版本的 PSU 补丁包补丁编号 p33477185发布于 2022 年 1 月面向需要为 Linux x86-64 平台数据库打补丁的 DBA 与运维人员用于修复安全漏洞、优化性能并解决已知问题。压缩包共 3658 个文件约 436.52MB以 so 动态库、o 目标文件、xml 元数据、sql 脚本及 plb、class、jar 等为主涵盖补丁程序、安装说明与依赖组件结构完整。目前已有 859 人学习下载。包内 PatchSearch.xml 提供补丁元数据与适用条件33477185 对应实际安装文件可配合 OPatch 完成解压、应用与验证借助这些内容读者能核对版本兼容性、按规范备份并部署补丁同时参考后置步骤与监控建议降低升级风险适合作为 11g 数据库补丁管理的实操参考。1. 从一次 PSU 补丁翻车说起DB-PSU-11.2.0.4.220118 到底装的是什么去年冬天某实验室一台跑了三年多的 Oracle 11.2.0.4 测试库突然在凌晨批量任务里报出 ORA-00600trace 文件里指向一个优化器相关的内部错误。查了一圈最终定位到是某个已知 bug而修复它的正是 2022 年 1 月发布的 PSU 补丁——DB-PSU-11.2.0.4.220118补丁号 p33477185平台 Linux x86-64。当时我以为打个补丁就是opatch apply一条命令的事结果因为 OPatch 版本太老、/tmp空间不够、以及漏跑了 datapatch前后折腾了整整一个下午。这套环境在政企、金融、制造业的内网里极其常见11.2.0.4 虽然早已不是主流版本但存量系统太多PSU 补丁的安装和回退依然是运维绕不开的基本功。这篇笔记写给正在给 11.2.0.4 打 PSU 的同行尤其是第一次独立操作、怕把库搞坏的新手——我会把版本选择、前置检查、安装步骤、datapatch 执行和回退方案一步步拆开照着走能跑通出了问题也知道去哪儿救。2. 装前把环境列清楚版本、OPatch 与空间的三重校验2.1 确认数据库版本和已装补丁清单动手之前先把当前库的底细摸清楚。很多人上来就解压补丁包结果发现 OPatch 版本不满足补丁要求或者当前已经装过更新的 PSU白忙一场。第一步永远是查版本和补丁列表。# 切换到 oracle 用户确认数据库版本 $ORACLE_HOME/bin/sqlplus -v # 查看当前已安装的补丁清单重点看有没有比 220118 更新的 PSU $ORACLE_HOME/OPatch/opatch lspatches # 查看 OPatch 自身版本11.2.0.4 打 2022 年补丁一般要求 11.2.0.3.20 以上 $ORACLE_HOME/OPatch/opatch versionsqlplus -v输出里要确认是11.2.0.4.0这个基线版本PSU 是叠加在基线之上的。opatch lspatches会列出所有已应用的补丁号如果里面已经出现了比 p33477185 更新的补丁就别再往下走了否则可能触发补丁冲突。opatch version这一条最容易被忽略——2022 年的 PSU 通常要求 OPatch 至少是 11.2.0.3.20低于这个版本opatch apply会直接报错退出。我一般会先把 OPatch 升级到对应版本再动 PSU升级方法在 2.3 节说。2.2 检查磁盘空间和临时目录补丁解压和安装过程对空间有硬性要求尤其是/tmp。11.2.0.4 的 PSU 解压后大概几百 MB但 OPatch 在 apply 阶段会往/tmp写大量临时文件空间不够会在中途报No space left on device而且这时候补丁可能已经改了一半回退起来很麻烦。# 检查 ORACLE_HOME 所在分区剩余空间建议至少留 5G df -h $ORACLE_HOME # 检查 /tmp 空间建议至少 2G不够就临时扩或改 TMP 环境变量 df -h /tmp # 如果 /tmp 确实紧张可以指定其他目录作为 OPatch 临时区 export TMP/u01/app/tmp export TMPDIR/u01/app/tmpdf -h看的是挂载点剩余空间不是目录本身大小。TMP和TMPDIR这两个环境变量要在执行opatch apply的同一个 shell 里 export否则不生效。我一般会在/u01/app下建一个tmp目录专门给 OPatch 用避免和系统/tmp抢空间。这一步做完环境层面的坑基本排掉了。2.3 升级 OPatch 到匹配版本如果 2.1 里查到 OPatch 版本偏低先升级它。OPatch 本身也是一个补丁包解压后覆盖原目录即可但要注意备份。# 备份现有 OPatch出问题可以回滚 mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak # 解压新版 OPatch 到 ORACLE_HOME unzip -q p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME # 确认版本已更新 $ORACLE_HOME/OPatch/opatch versionmv那一步是后悔药别省。解压完成后 OPatch 目录权限可能变成当前用户需要确认属主是 oracle:oinstall否则后续 apply 会报权限错误。opatch version输出正常就说明升级到位了。这里有个细节OPatch 升级不需要停库但 PSU 安装需要所以顺序是先升 OPatch再停库再打 PSU。3. 正式安装 PSU从解压到 opatch apply 的完整链路3.1 停库与解压补丁包PSU 安装要求数据库实例和监听都停掉但不需要停 ASM如果有独立 ASM 实例的话ASM 可以不停。停库顺序是先停监听再停实例或者反过来都行关键是确认进程真的退干净了。# 停监听 $ORACLE_HOME/bin/lsnrctl stop # 停实例注意用 sysdba 登录 $ORACLE_HOME/bin/sqlplus / as sysdba EOF shutdown immediate; exit; EOF # 确认没有残留的 oracle 进程 ps -ef | grep pmon | grep -v grepshutdown immediate比shutdown abort安全除非实例已经 hang 住否则别用 abort。ps -ef | grep pmon这条是确认实例真的停了有时候 shutdown 卡住但命令返回了pmon 还在这时候打补丁会出问题。停库之后解压 PSU 包# 解压 PSU 到独立目录不要解到 ORACLE_HOME 里 mkdir -p /u01/soft/psu220118 cd /u01/soft/psu220118 unzip -q p33477185_112040_Linux-x86-64.zip # 查看解压后的目录结构确认补丁号 ls -l解压出来的目录名通常就是补丁号里面有一个README.html和补丁子目录。我一般会先扫一眼 README 里的 Prerequisites 部分确认没有额外的前置补丁要求。这一步花两分钟能省掉后面报错再回头查的时间。3.2 用 opatch prereq 做安装前检查opatch apply之前强烈建议先跑opatch prereq它会检查补丁能不能装、有没有冲突、OPatch 版本够不够。这个命令不修改任何东西纯检查。cd /u01/soft/psu220118/33477185 # 检查补丁适用性-phBaseDir 指向补丁解压目录 $ORACLE_HOME/OPatch/opatch prereq CheckApplicable -phBaseDir /u01/soft/psu220118/33477185 # 检查补丁冲突 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/soft/psu220118/33477185CheckApplicable会输出补丁是否适用于当前 ORACLE_HOME如果报Not applicable多半是版本不对或者已经装过。CheckConflictAgainstOHWithDetail检查冲突如果报出某个已装补丁和当前 PSU 冲突需要先确认哪个更新通常保留更新的那个。这两条命令的输出要仔细看不要只看最后一行Prereq结果中间的WARNING也要读。3.3 执行 opatch apply 并观察输出检查通过后正式 apply。这一步会修改 ORACLE_HOME 下的二进制文件和库文件过程中不要中断不要开第二个窗口做别的操作。cd /u01/soft/psu220118/33477185 # 执行补丁安装-silent 减少交互日志同时输出到屏幕和文件 $ORACLE_HOME/OPatch/opatch apply -silent 21 | tee /u01/soft/psu220118/apply.log-silent会跳过确认提示适合脚本化操作但第一次装建议不加-silent看清楚每一步提示再回车。tee把输出同时写到日志文件出问题可以回溯。apply 过程中会看到Applying patch和Patching component之类的输出最后出现OPatch succeeded才算成功。如果中途报错日志里会指明是哪个文件或哪个检查失败根据报错去查不要盲目重跑。3.4 启动实例并执行 datapatchapply 成功只是把二进制补丁装上了数据库里的数据字典还没更新必须启动实例后跑 datapatch。这一步是 11.2.0.4 打 PSU 最容易漏掉的环节漏了会导致数据库行为不一致甚至起不来。# 启动实例到 mount 或 open 状态 $ORACLE_HOME/bin/sqlplus / as sysdba EOF startup; exit; EOF # 执行 datapatch它会读取补丁里的 SQL 并应用到数据库 cd $ORACLE_HOME/OPatch ./datapatch -verbosestartup之后数据库应该是 open 状态如果起不来先看 alert log。datapatch -verbose会输出每个 SQL 的执行情况最后显示Patch installation complete或类似信息。如果 datapatch 报错常见原因是实例没起全、或者之前有失败的 datapatch 残留需要先datapatch -rollback清理再重跑。跑完 datapatch整个 PSU 安装才算真正完成。4. 避坑与排查五个让我加班到深夜的 PSU 安装问题4.1 OPatch 版本过低导致 apply 直接失败现象执行opatch apply后立刻报错提示OPatch version 11.2.0.3.x is lower than the minimum required version补丁根本没开始装。原因11.2.0.4 自带的 OPatch 版本往往停留在 11.2.0.3.12 左右而 2022 年的 PSU 要求至少 11.2.0.3.20。版本不匹配时 OPatch 会拒绝执行这是保护机制不是 bug。解决按 2.3 节的步骤先升级 OPatch升级完再跑opatch version确认。升级 OPatch 不需要停库但升级后要重新执行opatch prereq检查因为新 OPatch 的检查逻辑可能和老版本不同。4.2 /tmp 空间不足导致 apply 中途失败现象opatch apply跑到一半报No space left on device补丁状态变成PARTIAL数据库起不来。原因OPatch 在 apply 阶段会把补丁文件复制到/tmp下做临时处理如果/tmp是独立分区且空间小于 2G很容易撑爆。撑爆之后补丁只应用了一部分ORACLE_HOME 处于不一致状态。解决先按 2.2 节的方法把TMP和TMPDIR指向空间充足的目录然后执行opatch rollback -id 33477185回退已应用的部分再重新 apply。如果 rollback 也失败就需要从备份恢复 ORACLE_HOME所以打补丁前对 ORACLE_HOME 做一次冷备是值得的。4.3 漏跑 datapatch 导致数据库行为异常现象apply 成功实例也能启动但某些 SQL 执行计划突变或者报出ORA-04061之类的错误查 alert log 没有明显异常。原因PSU 包含两部分二进制补丁和 SQL 补丁。opatch apply只装了二进制部分SQL 部分要靠datapatch写入数据字典。漏跑 datapatch 时二进制和字典不一致就会出现各种玄学问题。解决启动实例后立即执行datapatch -verbose确认输出里有Patch installation complete。如果已经漏跑了一段时间补跑 datapatch 即可不需要重新 apply。补跑前建议先做一次全库备份因为 datapatch 会修改数据字典。4.4 补丁冲突导致 prereq 检查不通过现象opatch prereq CheckConflictAgainstOHWithDetail报出某个已装补丁和当前 PSU 冲突提示Conflict with patch xxxxxxxx。原因当前 ORACLE_HOME 里已经装了一个和 p33477185 修改了相同文件的补丁两个补丁不能共存。常见于之前打过其他 PSU 或一次性补丁。解决先确认哪个补丁更新。如果已装的补丁比 p33477185 新就不需要再装这个 PSU如果已装的更旧需要先opatch rollback回退旧补丁再装新的。回退前务必确认旧补丁没有其他依赖回退后数据库可能需要重新跑 datapatch。4.5 回退时忘记回退 datapatch现象执行opatch rollback -id 33477185成功但数据库启动后报错或者行为仍然像装了补丁。原因rollback 只回退了二进制部分datapatch 写入的 SQL 变更还在数据字典里。二进制回退后字典和二进制又不一致了。解决rollback 之后启动实例到 open 状态执行datapatch -rollback回退 SQL 部分。顺序是先用 opatch rollback 回退二进制再用 datapatch -rollback 回退 SQL两步都完成才算真正回退。回退完成后建议重启一次实例确认 alert log 没有异常。5. 装完怎么验证三条命令确认 PSU 真正生效补丁装完不是看到OPatch succeeded就结束了得验证二进制和字典两边都到位。我一般用三条命令交叉确认少一条都不放心。第一条查 opatch 补丁列表确认 p33477185 在列$ORACLE_HOME/OPatch/opatch lspatches | grep 33477185输出里应该能看到33477185和对应的描述信息。如果 grep 不到说明二进制补丁没装上回头查 apply 日志。第二条查数据库注册的补丁信息确认 datapatch 生效-- 以 sysdba 登录后执行 SELECT patch_id, patch_type, action, status, action_time FROM dba_registry_sqlpatch ORDER BY action_time DESC;dba_registry_sqlpatch是 11.2.0.4 之后才有的视图里面记录了每次 datapatch 的操作。status列应该是SUCCESSaction是APPLY。如果这个视图查不到记录说明 datapatch 没跑或者没跑成功。第三条查组件版本确认 ORACLE_HOME 里的组件版本号有变化SELECT comp_id, version, status FROM dba_registry WHERE comp_id IN (CATALOG,CATPROC);CATPROC的 version 应该和 PSU 的版本对应status 是VALID。如果 status 是INVALID需要跑utlrp.sql重新编译无效对象。三条都对上才算真正装完。从那以后我每次打完 PSU都会把这三条命令走一遍再顺手看一眼 alert log 末尾有没有 ORA- 错误。补丁这东西装的时候小心验的时候较真后面才能睡得踏实。希望帮到你。本文还有配套的精品资源点击获取
