简介Oracle 数据库 11.2.0.4 版本的 2022 年 1 月 PSU 补丁包p33477185面向需要为 Linux x86-64 平台数据库补齐安全修复与性能改进的 DBA 和运维人员。压缩包约 436.52MB共 3658 个文件涵盖大量 so 动态库与 o 对象文件、xml 元数据与说明文件、sql 脚本以及 plb、class、jar、a 等组件整体呈现典型 Oracle 补丁目录结构便于按补丁 ID 和元数据核对适用条件。已有 861 人学习或下载。读者可借助其中的 PatchSearch.xml 了解补丁内容、适用条件与安装指导结合补丁程序用于 OPatch 补丁管理、兼容性确认和问题排查适合数据库版本维护、补丁管理与稳定性保障等学习场景。1. 先别急着解压DB-PSU-11.2.0.4.220118 在 11gR2 末期的真实定位某公司的业务库还停在 Oracle 11.2.0.42022 年初合规扫描把基线卡到 DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64。很多人以为这就是解压、opatch apply、重启库三件事真正动手才会发现 11gR2 末期的 DB-PSU 不是孤立的二进制补丁它要跟 OPatch 版本、中央清单、datapatch、无效对象编译、RAC 节点顺序一起看。这个包适合仍在维护 11.2.0.4 单机、RAC 或 Data Guard 环境、需要把数据库补丁基线推到 2022 年 1 月的从业者如果库已经升级到 12c 以上或者只是 GI 补丁需求不要拿它硬套。下面按拆包、前置检查、单机落地、RAC 与主备、避坑、验证回退的顺序拆一遍。2. 拆包与前置检查p33477185 的 README、OPatch 和空间账拿到 zip 不要直接解压到$ORACLE_HOME。先在/soft下建一个独立目录用 oracle 用户解压避免 root 解压后属主不对后面opatch apply报权限错误。DB-PSU 包通常包含 README、补丁元数据、二进制文件和 SQL 补丁文件真正决定能不能打进去的往往不是补丁本身而是 README 里的前置条件、OPatch 最低版本和 datapatch 说明。11.2.0.4 的 home 很多是几年前建的OPatch 版本停留在早期 11.2.0.3.x直接打 2022 年 1 月的 PSU 大概率会被拦下来。2.1 先读 README 的四个段落前置补丁、OPatch 最低版本、datapatch、回退补丁包解压后先找 README不要急着看opatch apply的输出。README 里我一般只盯四段Prerequisites、OPatch Minimum Version、Post-installation、Rollback。Prerequisites 决定有没有前置补丁、要不要先打 GI 补丁、当前 home 是否在支持列表OPatch Minimum Version 决定要不要先换 OPatchPost-installation 决定打完二进制后要不要跑 datapatch、utlrp、重启监听Rollback 决定出问题时能不能干净退回去。把这四项抄进变更单比凭记忆靠谱。README 段落要确认什么不确认的后果Prerequisites是否有前置补丁、是否要求 GI 先打、home 是否匹配打到一半被前置检查拒绝或打进去但组件不兼容OPatch Minimum Version当前 OPatch 是否达标opatch apply直接报错甚至留下半应用状态Post-installation是否要跑 datapatch、utlrp、重启监听二进制补丁进了 homeSQL 补丁没进数据字典Rollback回退命令、回退顺序、备份要求出问题时不敢退或者退不干净提示README 里的补丁号、平台、OPatch 最低版本、回退命令建议直接复制到变更单不要手打。p33477185 对应 Linux x86-64平台不对时不要试图“兼容”。2.2 OPatch 与中央清单版本不够时先换 OPatch不要硬打先确认当前 OPatch 版本和中央清单。opatch version看版本opatch lsinventory -detail看当前 home 已安装的补丁和 home 类型中央清单看目标 home 是否注册正常。换 OPatch 时先备份旧目录不要直接覆盖解压新 OPatch 后保持 oracle:oinstall 属主root 解压后记得 chown。换之前停掉所有使用该 home 的进程避免lsinventory读到一半被占用。# 确认当前 OPatch 版本和已安装补丁 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$PATH opatch version opatch lsinventory -detail | sed -n 1,60p # 看中央清单里目标 home 是否注册正常 grep -E HOME|LOC /u01/app/oraInventory/ContentsXML/inventory.xmlopatch version的输出必须不低于 README 要求lsinventory -detail里重点看 Oracle Home 路径、OPatch 版本、已打补丁列表确认没有历史遗留的半应用补丁。中央清单里HOME NAME和LOC要指向当前 homeRAC 环境还要确认每个节点的 DB home 都注册在同一个中央清单下。换 OPatch 的常见做法是mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak_$(date %Y%m%d)再把新 OPatch 解压到$ORACLE_HOME最后用opatch version和opatch lsinventory各跑一遍确认。2.3 空间、权限和补丁冲突检查三个命令把低级错误挡在停库之前空间和权限是典型的“停库之后才发现”的问题。$ORACLE_HOME要放二进制备份/tmp要放解压和临时文件补丁解压目录也要有空间.patch_storage里可能存着历史补丁的回退备份空间紧张时不要直接删先确认没有回退需求。权限方面补丁目录属主必须是 oracle:oinstallroot 解压后没有 chown 是常见翻车点。冲突检查用CheckConflictAgainstOHWithDetail输出 passed 才算过。# 空间ORACLE_HOME、/tmp、补丁解压目录都要看 df -h $ORACLE_HOME /tmp /soft du -sh $ORACLE_HOME/.patch_storage 2/dev/null # 权限补丁目录属主必须是 oracle:oinstall ls -ld /soft/p33477185 find /soft/p33477185 -maxdepth 1 -user root -print # 补丁冲突检查-phBaseDir 指向解压后的补丁目录 cd /soft $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /soft/33477185df -h看 avail 而不是只看 sizedu -sh .patch_storage看历史补丁占用的空间空间不够时优先扩容或清理旧日志不要动当前补丁的备份。find输出为空说明补丁目录没有 root 属主文件有输出就先 chown。冲突检查的-phBaseDir指向解压后的补丁目录不是 zip 文件也不是$ORACLE_HOME。报冲突时记录冲突补丁号回到 README 看是否要求先回退或改用合并补丁不要用跳过参数硬打。3. 单机落地从 opatch apply 到 datapatch 的完整命令链单机环境最容易出问题的不是opatch apply而是“打完二进制不跑 datapatch”和“跑完 datapatch 不编译无效对象”。11.2.0.4 的 DB-PSU 包含 SQL 补丁opatch apply只把二进制和 SQL 文件放进 home真正把 SQL 补丁注册到数据字典的是datapatch。顺序我一般按停业务→停监听→备份→opatch apply→启动到 open→datapatch -verbose→utlrp.sql→验证→开监听。中间任何一步报错都停下来看日志不要带着半应用状态开业务。3.1 停库前把备份和回退路径做实停库前先确认库状态、归档模式、运行中的 job 和活跃用户会话。dba_jobs_running有记录时先确认能不能停v$session里 typeUSER 且 statusACTIVE 的会话要通知业务方退出。停监听不是必须但能避免打补丁期间业务连进来。备份至少是 RMAN 全备加归档备份或者冷备$ORACLE_HOME和数据文件回退路径要写清楚opatch rollback -id 33477185和datapatch -rollback的顺序按 README 来不要临场猜。# 单机环境确认库状态、归档模式、运行中的 job sqlplus -s / as sysdba SQL set lines 200 select status, log_mode, open_mode from v$database; select count(*) as running_jobs from dba_jobs_running; select count(*) as active_sessions from v$session where statusACTIVE and typeUSER; SQL # 停监听和数据库单机 lsnrctl stop sqlplus -s / as sysdba SQL shutdown immediate SQLshutdown immediate之前确认没有长事务必要时先alter system checkpoint。RAC 环境不要用这套单机命令后面第 4 章单独说。备份完成后在变更单里记下备份集号或快照名回退时不用翻聊天记录。没有备份的库不要直接试补丁这是血泪经验不是流程口号。3.2 opatch apply 的命令与日志判读进入解压后的补丁目录执行opatch apply如果目录不在当前路径显式传补丁目录。执行过程中会做前置检查、备份、应用二进制看到ApplySession failed、OPatch failed with error code就停不要继续启动数据库。日志在$ORACLE_HOME/cfgtoollogs/opatch/下按时间排序找最新一份重点看 Prerequisite check 和错误码。成功后opatch lspatches应该能看到 33477185。cd /soft/p33477185 $ORACLE_HOME/OPatch/opatch apply # 如果补丁目录不在当前目录显式指定 # $ORACLE_HOME/OPatch/opatch apply /soft/p33477185 # 看最近一次 opatch 日志 ls -lt $ORACLE_HOME/cfgtoollogs/opatch/ | head tail -80 $ORACLE_HOME/cfgtoollogs/opatch/opatch*.logopatch apply的退出码不是 0 就不要往下走。前置检查失败常见原因是 OPatch 版本、补丁冲突、空间、权限应用阶段失败要看到具体文件或命令。日志里Prerequisite check和ApplySession是两块重点。成功后用opatch lspatches确认补丁号再启动数据库。注意ORACLE_HOME和PATH要指向目标 DB home不要打到 GI homeRAC 里每个节点的 DB home 都要单独打。3.3 datapatch 与 utlrpSQL 补丁落地和无效对象编译opatch apply完成后启动数据库到 open确认open_mode是 READWRITE再跑datapatch -verbose。datapatch会读取 home 里的 SQL 补丁按顺序应用到数据字典并在dba_registry_sqlpatch里登记。失败时看$ORACLE_BASE/cfgtoollogs/sqlpatch下最新时间戳目录的日志不要直接重跑。datapatch成功后跑utlrp.sql编译无效对象再看dba_objects里 invalid 数量。# 启动数据库到 open确认可读写 sqlplus -s / as sysdba SQL startup select open_mode from v$database; SQL # 执行 datapatch先 verbose 看每个 SQL 补丁 $ORACLE_HOME/OPatch/datapatch -verbose # 编译无效对象 sqlplus -s / as sysdba SQL ?/rdbms/admin/utlrp.sql select count(*) as invalid_objects from dba_objects where statusINVALID; SQLdatapatch -verbose会输出每个 SQL 补丁的应用状态成功时dba_registry_sqlpatch有 33477185 的记录。失败时先看日志里的 ORA 错误和失败补丁号再决定回退还是重跑不要在数据库没 open 可读写时跑 datapatch。utlrp.sql跑完再看 invalid 数量11.2.0.4 里少量 invalid 可能是已知对象但dba_registry里的核心组件必须是 VALID。RAC 里 datapatch 只在一个节点跑一次不要每个节点都跑。4. RAC 与 Data GuardDB-PSU 的节点顺序和主备取舍单机按上面走一遍基本能落地RAC 和 Data Guard 的坑在顺序。DB-PSU 只打 DB homeGI home 的补丁是另一个包不要把 DB-PSU 打到 GI home。RAC 中每个节点的 DB home 都要opatch apply但datapatch只在一个节点跑一次因为数据字典共享。Data Guard 要先确认备库是否处于 Active Data Guard 只读打开只读库不能直接跑 datapatchSQL 补丁通过主库的 redo 传到备库主备二进制补丁版本要一致。4.1 RAC 里 DB-PSU 和 GI-PSU 分开打节点顺序别混先确认数据库配置、节点列表和每个节点的 home。srvctl config database -d ORCL看实例和节点olsnodes -n看节点编号opatch lspatches在每个节点确认当前补丁。滚动步骤节点 1 停实例→节点 1opatch apply→节点 1 启动实例节点 2 重复所有节点二进制一致后选一个节点跑datapatch -verbose然后utlrp.sql最后每个节点验证。不要在节点 1 打完就立刻跑 datapatch等所有节点二进制都完成。# RAC 节点上确认数据库配置和 home srvctl config database -d ORCL olsnodes -n $ORACLE_HOME/OPatch/opatch lspatches # 节点1停实例、打补丁、启动实例 srvctl stop instance -d ORCL -i ORCL1 cd /soft/p33477185 $ORACLE_HOME/OPatch/opatch apply srvctl start instance -d ORCL -i ORCL1srvctl stop instance只停一个实例不影响其他节点opatch apply在节点 1 的 DB home 执行节点 2 重复同样步骤。GI home 的opatch lspatches和 DB home 分开看不要混。滚动期间确认其他节点能正常服务监听和 SCAN 没有异常。所有节点二进制打完后选一个节点跑 datapatch不要并发跑。4.2 Data Guard 先备后主还是先主后备看切换窗口和补丁内容常见做法是先备后主先停备库的 MRP打备库 DB home 二进制再打主库二进制并跑 datapatch最后备库通过归档日志应用 SQL 补丁。但 11.2.0.4 的备库如果是只读打开datapatch不能在备库跑SQL 补丁通过主库的 redo 传播。需要确认log_archive_dest_2、v$dataguard_status变更前做一次 switchover 演练。补丁包含时区或数据字典变更时主备顺序更要按 README 来不要凭经验套。# 备库停 MRP打二进制再启动 MRP sqlplus -s / as sysdba SQL alter database recover managed standby database cancel; SQL cd /soft/p33477185 $ORACLE_HOME/OPatch/opatch apply # 主库打二进制后启动到 open跑 datapatch $ORACLE_HOME/OPatch/datapatch -verbose # 备库重新开启日志应用 sqlplus -s / as sysdba SQL alter database recover managed standby database using current logfile disconnect; SQLrecover managed standby database cancel停 MRPusing current logfile是常见实时应用写法。主库 datapatch 后确认备库v$dataguard_status没有严重错误v$archive_gap没有 gap。主备二进制补丁版本要一致SQL 补丁通过日志应用顺序按 README 和当前 Data Guard 模式定不要在主库 datapatch 前把备库二进制打得太超前也不要反过来。4.3 打完后在 RAC 和备库上分别验证什么RAC 每个节点都要看opatch lspatches确认 33477185 都在dba_registry_sqlpatch在一个实例查即可因为数据字典共享gv$instance确认所有实例 opendba_registry核心组件 VALID。备库看opatch lspatches是否一致v$dataguard_status是否有 errordba_registry_sqlpatch通过日志应用后是否有记录v$archive_gap是否有 gap。验证不是只看一个视图二进制和 SQL 补丁要分开确认。环境检查命令期望RAC 每个节点opatch lspatches都能看到 33477185RAC 任一实例dba_registry_sqlpatch33477185 状态 SUCCESSRAC 全局gv$instance所有实例 OPEN备库v$dataguard_status无 errorMRP 正常应用备库v$archive_gap无 gap5. 避坑排查opatch 报错、datapatch 失败与无效对象补丁包本身不复杂翻车多数发生在版本、顺序、日志三件事上。下面几条是 11.2.0.4 DB-PSU 场景里最常见的按现象→原因→解决写不按教科书顺序。某开发者在测试库上没看 READMEOPatch 版本低opatch apply失败后直接替换 OPatch 再打结果lsinventory显示两个 OPatch 版本最后从快照恢复。这种翻车不是补丁的问题是前置检查没做。5.1 安装前的高频翻车OPatch、冲突、空间现象opatch apply一开始就报OPatch failed with error code 73日志里提示 OPatch 版本不支持。原因11.2.0.4 的 home 里 OPatch 还是早期 11.2.0.3.x低于 README 要求。解决备份旧 OPatch按 README 要求替换opatch version确认再opatch lsinventory确认 home 正常。不要用 root 解压后直接跑属主不对会引发第二层错误。现象冲突检查报CheckConflictAgainstOHWithDetail失败提示某个补丁已存在或冲突。原因之前打过更高版本 PSU 或重叠补丁。解决记录冲突补丁号回 README 看是否要求先回退不要用跳过参数硬打除非 README 明确允许。冲突没解决就停库后面大概率会在 apply 阶段再失败一次。现象opatch apply到 80% 报No space left on device。原因$ORACLE_HOME或/tmp空间不足.patch_storage占满。解决扩容或清理旧日志不要直接删.patch_storage里的当前补丁备份确认回退需求后再清理。打补丁前df -h和du -sh先看比停库后再处理省时间。5.2 datapatch 阶段的报错定位先看日志再决定回退现象datapatch -verbose卡住或报 ORA 错误dba_registry_sqlpatch状态不是 SUCCESS。原因数据库没在 open 可读写状态、之前 datapatch 中断、SQL 补丁与当前字典不匹配。解决看$ORACLE_BASE/cfgtoollogs/sqlpatch最新目录的日志确认失败补丁号不要直接重跑先看dba_registry_sqlpatch的 action 和 status必要时按 README 回退 SQL 补丁再重打。现象utlrp.sql跑完还有大量 invalid 对象。原因依赖对象编译失败、之前就有 invalid、补丁后需要多次编译。解决再跑一次utlrp.sql查dba_errors看具体错误核心组件本文还有配套的精品资源点击获取
简介Oracle 数据库 11.2.0.4 版本的 2022 年 1 月 PSU 补丁包p33477185面向需要为 Linux x86-64 平台数据库补齐安全修复与性能改进的 DBA 和运维人员。压缩包约 436.52MB共 3658 个文件涵盖大量 so 动态库与 o 对象文件、xml 元数据与说明文件、sql 脚本以及 plb、class、jar、a 等组件整体呈现典型 Oracle 补丁目录结构便于按补丁 ID 和元数据核对适用条件。已有 861 人学习或下载。读者可借助其中的 PatchSearch.xml 了解补丁内容、适用条件与安装指导结合补丁程序用于 OPatch 补丁管理、兼容性确认和问题排查适合数据库版本维护、补丁管理与稳定性保障等学习场景。1. 先别急着解压DB-PSU-11.2.0.4.220118 在 11gR2 末期的真实定位某公司的业务库还停在 Oracle 11.2.0.42022 年初合规扫描把基线卡到 DB-PSU-11.2.0.4.220118 (Jan 2022)-p33477185Linux-x86-64。很多人以为这就是解压、opatch apply、重启库三件事真正动手才会发现 11gR2 末期的 DB-PSU 不是孤立的二进制补丁它要跟 OPatch 版本、中央清单、datapatch、无效对象编译、RAC 节点顺序一起看。这个包适合仍在维护 11.2.0.4 单机、RAC 或 Data Guard 环境、需要把数据库补丁基线推到 2022 年 1 月的从业者如果库已经升级到 12c 以上或者只是 GI 补丁需求不要拿它硬套。下面按拆包、前置检查、单机落地、RAC 与主备、避坑、验证回退的顺序拆一遍。2. 拆包与前置检查p33477185 的 README、OPatch 和空间账拿到 zip 不要直接解压到$ORACLE_HOME。先在/soft下建一个独立目录用 oracle 用户解压避免 root 解压后属主不对后面opatch apply报权限错误。DB-PSU 包通常包含 README、补丁元数据、二进制文件和 SQL 补丁文件真正决定能不能打进去的往往不是补丁本身而是 README 里的前置条件、OPatch 最低版本和 datapatch 说明。11.2.0.4 的 home 很多是几年前建的OPatch 版本停留在早期 11.2.0.3.x直接打 2022 年 1 月的 PSU 大概率会被拦下来。2.1 先读 README 的四个段落前置补丁、OPatch 最低版本、datapatch、回退补丁包解压后先找 README不要急着看opatch apply的输出。README 里我一般只盯四段Prerequisites、OPatch Minimum Version、Post-installation、Rollback。Prerequisites 决定有没有前置补丁、要不要先打 GI 补丁、当前 home 是否在支持列表OPatch Minimum Version 决定要不要先换 OPatchPost-installation 决定打完二进制后要不要跑 datapatch、utlrp、重启监听Rollback 决定出问题时能不能干净退回去。把这四项抄进变更单比凭记忆靠谱。README 段落要确认什么不确认的后果Prerequisites是否有前置补丁、是否要求 GI 先打、home 是否匹配打到一半被前置检查拒绝或打进去但组件不兼容OPatch Minimum Version当前 OPatch 是否达标opatch apply直接报错甚至留下半应用状态Post-installation是否要跑 datapatch、utlrp、重启监听二进制补丁进了 homeSQL 补丁没进数据字典Rollback回退命令、回退顺序、备份要求出问题时不敢退或者退不干净提示README 里的补丁号、平台、OPatch 最低版本、回退命令建议直接复制到变更单不要手打。p33477185 对应 Linux x86-64平台不对时不要试图“兼容”。2.2 OPatch 与中央清单版本不够时先换 OPatch不要硬打先确认当前 OPatch 版本和中央清单。opatch version看版本opatch lsinventory -detail看当前 home 已安装的补丁和 home 类型中央清单看目标 home 是否注册正常。换 OPatch 时先备份旧目录不要直接覆盖解压新 OPatch 后保持 oracle:oinstall 属主root 解压后记得 chown。换之前停掉所有使用该 home 的进程避免lsinventory读到一半被占用。# 确认当前 OPatch 版本和已安装补丁 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$PATH opatch version opatch lsinventory -detail | sed -n 1,60p # 看中央清单里目标 home 是否注册正常 grep -E HOME|LOC /u01/app/oraInventory/ContentsXML/inventory.xmlopatch version的输出必须不低于 README 要求lsinventory -detail里重点看 Oracle Home 路径、OPatch 版本、已打补丁列表确认没有历史遗留的半应用补丁。中央清单里HOME NAME和LOC要指向当前 homeRAC 环境还要确认每个节点的 DB home 都注册在同一个中央清单下。换 OPatch 的常见做法是mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_bak_$(date %Y%m%d)再把新 OPatch 解压到$ORACLE_HOME最后用opatch version和opatch lsinventory各跑一遍确认。2.3 空间、权限和补丁冲突检查三个命令把低级错误挡在停库之前空间和权限是典型的“停库之后才发现”的问题。$ORACLE_HOME要放二进制备份/tmp要放解压和临时文件补丁解压目录也要有空间.patch_storage里可能存着历史补丁的回退备份空间紧张时不要直接删先确认没有回退需求。权限方面补丁目录属主必须是 oracle:oinstallroot 解压后没有 chown 是常见翻车点。冲突检查用CheckConflictAgainstOHWithDetail输出 passed 才算过。# 空间ORACLE_HOME、/tmp、补丁解压目录都要看 df -h $ORACLE_HOME /tmp /soft du -sh $ORACLE_HOME/.patch_storage 2/dev/null # 权限补丁目录属主必须是 oracle:oinstall ls -ld /soft/p33477185 find /soft/p33477185 -maxdepth 1 -user root -print # 补丁冲突检查-phBaseDir 指向解压后的补丁目录 cd /soft $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /soft/33477185df -h看 avail 而不是只看 sizedu -sh .patch_storage看历史补丁占用的空间空间不够时优先扩容或清理旧日志不要动当前补丁的备份。find输出为空说明补丁目录没有 root 属主文件有输出就先 chown。冲突检查的-phBaseDir指向解压后的补丁目录不是 zip 文件也不是$ORACLE_HOME。报冲突时记录冲突补丁号回到 README 看是否要求先回退或改用合并补丁不要用跳过参数硬打。3. 单机落地从 opatch apply 到 datapatch 的完整命令链单机环境最容易出问题的不是opatch apply而是“打完二进制不跑 datapatch”和“跑完 datapatch 不编译无效对象”。11.2.0.4 的 DB-PSU 包含 SQL 补丁opatch apply只把二进制和 SQL 文件放进 home真正把 SQL 补丁注册到数据字典的是datapatch。顺序我一般按停业务→停监听→备份→opatch apply→启动到 open→datapatch -verbose→utlrp.sql→验证→开监听。中间任何一步报错都停下来看日志不要带着半应用状态开业务。3.1 停库前把备份和回退路径做实停库前先确认库状态、归档模式、运行中的 job 和活跃用户会话。dba_jobs_running有记录时先确认能不能停v$session里 typeUSER 且 statusACTIVE 的会话要通知业务方退出。停监听不是必须但能避免打补丁期间业务连进来。备份至少是 RMAN 全备加归档备份或者冷备$ORACLE_HOME和数据文件回退路径要写清楚opatch rollback -id 33477185和datapatch -rollback的顺序按 README 来不要临场猜。# 单机环境确认库状态、归档模式、运行中的 job sqlplus -s / as sysdba SQL set lines 200 select status, log_mode, open_mode from v$database; select count(*) as running_jobs from dba_jobs_running; select count(*) as active_sessions from v$session where statusACTIVE and typeUSER; SQL # 停监听和数据库单机 lsnrctl stop sqlplus -s / as sysdba SQL shutdown immediate SQLshutdown immediate之前确认没有长事务必要时先alter system checkpoint。RAC 环境不要用这套单机命令后面第 4 章单独说。备份完成后在变更单里记下备份集号或快照名回退时不用翻聊天记录。没有备份的库不要直接试补丁这是血泪经验不是流程口号。3.2 opatch apply 的命令与日志判读进入解压后的补丁目录执行opatch apply如果目录不在当前路径显式传补丁目录。执行过程中会做前置检查、备份、应用二进制看到ApplySession failed、OPatch failed with error code就停不要继续启动数据库。日志在$ORACLE_HOME/cfgtoollogs/opatch/下按时间排序找最新一份重点看 Prerequisite check 和错误码。成功后opatch lspatches应该能看到 33477185。cd /soft/p33477185 $ORACLE_HOME/OPatch/opatch apply # 如果补丁目录不在当前目录显式指定 # $ORACLE_HOME/OPatch/opatch apply /soft/p33477185 # 看最近一次 opatch 日志 ls -lt $ORACLE_HOME/cfgtoollogs/opatch/ | head tail -80 $ORACLE_HOME/cfgtoollogs/opatch/opatch*.logopatch apply的退出码不是 0 就不要往下走。前置检查失败常见原因是 OPatch 版本、补丁冲突、空间、权限应用阶段失败要看到具体文件或命令。日志里Prerequisite check和ApplySession是两块重点。成功后用opatch lspatches确认补丁号再启动数据库。注意ORACLE_HOME和PATH要指向目标 DB home不要打到 GI homeRAC 里每个节点的 DB home 都要单独打。3.3 datapatch 与 utlrpSQL 补丁落地和无效对象编译opatch apply完成后启动数据库到 open确认open_mode是 READWRITE再跑datapatch -verbose。datapatch会读取 home 里的 SQL 补丁按顺序应用到数据字典并在dba_registry_sqlpatch里登记。失败时看$ORACLE_BASE/cfgtoollogs/sqlpatch下最新时间戳目录的日志不要直接重跑。datapatch成功后跑utlrp.sql编译无效对象再看dba_objects里 invalid 数量。# 启动数据库到 open确认可读写 sqlplus -s / as sysdba SQL startup select open_mode from v$database; SQL # 执行 datapatch先 verbose 看每个 SQL 补丁 $ORACLE_HOME/OPatch/datapatch -verbose # 编译无效对象 sqlplus -s / as sysdba SQL ?/rdbms/admin/utlrp.sql select count(*) as invalid_objects from dba_objects where statusINVALID; SQLdatapatch -verbose会输出每个 SQL 补丁的应用状态成功时dba_registry_sqlpatch有 33477185 的记录。失败时先看日志里的 ORA 错误和失败补丁号再决定回退还是重跑不要在数据库没 open 可读写时跑 datapatch。utlrp.sql跑完再看 invalid 数量11.2.0.4 里少量 invalid 可能是已知对象但dba_registry里的核心组件必须是 VALID。RAC 里 datapatch 只在一个节点跑一次不要每个节点都跑。4. RAC 与 Data GuardDB-PSU 的节点顺序和主备取舍单机按上面走一遍基本能落地RAC 和 Data Guard 的坑在顺序。DB-PSU 只打 DB homeGI home 的补丁是另一个包不要把 DB-PSU 打到 GI home。RAC 中每个节点的 DB home 都要opatch apply但datapatch只在一个节点跑一次因为数据字典共享。Data Guard 要先确认备库是否处于 Active Data Guard 只读打开只读库不能直接跑 datapatchSQL 补丁通过主库的 redo 传到备库主备二进制补丁版本要一致。4.1 RAC 里 DB-PSU 和 GI-PSU 分开打节点顺序别混先确认数据库配置、节点列表和每个节点的 home。srvctl config database -d ORCL看实例和节点olsnodes -n看节点编号opatch lspatches在每个节点确认当前补丁。滚动步骤节点 1 停实例→节点 1opatch apply→节点 1 启动实例节点 2 重复所有节点二进制一致后选一个节点跑datapatch -verbose然后utlrp.sql最后每个节点验证。不要在节点 1 打完就立刻跑 datapatch等所有节点二进制都完成。# RAC 节点上确认数据库配置和 home srvctl config database -d ORCL olsnodes -n $ORACLE_HOME/OPatch/opatch lspatches # 节点1停实例、打补丁、启动实例 srvctl stop instance -d ORCL -i ORCL1 cd /soft/p33477185 $ORACLE_HOME/OPatch/opatch apply srvctl start instance -d ORCL -i ORCL1srvctl stop instance只停一个实例不影响其他节点opatch apply在节点 1 的 DB home 执行节点 2 重复同样步骤。GI home 的opatch lspatches和 DB home 分开看不要混。滚动期间确认其他节点能正常服务监听和 SCAN 没有异常。所有节点二进制打完后选一个节点跑 datapatch不要并发跑。4.2 Data Guard 先备后主还是先主后备看切换窗口和补丁内容常见做法是先备后主先停备库的 MRP打备库 DB home 二进制再打主库二进制并跑 datapatch最后备库通过归档日志应用 SQL 补丁。但 11.2.0.4 的备库如果是只读打开datapatch不能在备库跑SQL 补丁通过主库的 redo 传播。需要确认log_archive_dest_2、v$dataguard_status变更前做一次 switchover 演练。补丁包含时区或数据字典变更时主备顺序更要按 README 来不要凭经验套。# 备库停 MRP打二进制再启动 MRP sqlplus -s / as sysdba SQL alter database recover managed standby database cancel; SQL cd /soft/p33477185 $ORACLE_HOME/OPatch/opatch apply # 主库打二进制后启动到 open跑 datapatch $ORACLE_HOME/OPatch/datapatch -verbose # 备库重新开启日志应用 sqlplus -s / as sysdba SQL alter database recover managed standby database using current logfile disconnect; SQLrecover managed standby database cancel停 MRPusing current logfile是常见实时应用写法。主库 datapatch 后确认备库v$dataguard_status没有严重错误v$archive_gap没有 gap。主备二进制补丁版本要一致SQL 补丁通过日志应用顺序按 README 和当前 Data Guard 模式定不要在主库 datapatch 前把备库二进制打得太超前也不要反过来。4.3 打完后在 RAC 和备库上分别验证什么RAC 每个节点都要看opatch lspatches确认 33477185 都在dba_registry_sqlpatch在一个实例查即可因为数据字典共享gv$instance确认所有实例 opendba_registry核心组件 VALID。备库看opatch lspatches是否一致v$dataguard_status是否有 errordba_registry_sqlpatch通过日志应用后是否有记录v$archive_gap是否有 gap。验证不是只看一个视图二进制和 SQL 补丁要分开确认。环境检查命令期望RAC 每个节点opatch lspatches都能看到 33477185RAC 任一实例dba_registry_sqlpatch33477185 状态 SUCCESSRAC 全局gv$instance所有实例 OPEN备库v$dataguard_status无 errorMRP 正常应用备库v$archive_gap无 gap5. 避坑排查opatch 报错、datapatch 失败与无效对象补丁包本身不复杂翻车多数发生在版本、顺序、日志三件事上。下面几条是 11.2.0.4 DB-PSU 场景里最常见的按现象→原因→解决写不按教科书顺序。某开发者在测试库上没看 READMEOPatch 版本低opatch apply失败后直接替换 OPatch 再打结果lsinventory显示两个 OPatch 版本最后从快照恢复。这种翻车不是补丁的问题是前置检查没做。5.1 安装前的高频翻车OPatch、冲突、空间现象opatch apply一开始就报OPatch failed with error code 73日志里提示 OPatch 版本不支持。原因11.2.0.4 的 home 里 OPatch 还是早期 11.2.0.3.x低于 README 要求。解决备份旧 OPatch按 README 要求替换opatch version确认再opatch lsinventory确认 home 正常。不要用 root 解压后直接跑属主不对会引发第二层错误。现象冲突检查报CheckConflictAgainstOHWithDetail失败提示某个补丁已存在或冲突。原因之前打过更高版本 PSU 或重叠补丁。解决记录冲突补丁号回 README 看是否要求先回退不要用跳过参数硬打除非 README 明确允许。冲突没解决就停库后面大概率会在 apply 阶段再失败一次。现象opatch apply到 80% 报No space left on device。原因$ORACLE_HOME或/tmp空间不足.patch_storage占满。解决扩容或清理旧日志不要直接删.patch_storage里的当前补丁备份确认回退需求后再清理。打补丁前df -h和du -sh先看比停库后再处理省时间。5.2 datapatch 阶段的报错定位先看日志再决定回退现象datapatch -verbose卡住或报 ORA 错误dba_registry_sqlpatch状态不是 SUCCESS。原因数据库没在 open 可读写状态、之前 datapatch 中断、SQL 补丁与当前字典不匹配。解决看$ORACLE_BASE/cfgtoollogs/sqlpatch最新目录的日志确认失败补丁号不要直接重跑先看dba_registry_sqlpatch的 action 和 status必要时按 README 回退 SQL 补丁再重打。现象utlrp.sql跑完还有大量 invalid 对象。原因依赖对象编译失败、之前就有 invalid、补丁后需要多次编译。解决再跑一次utlrp.sql查dba_errors看具体错误核心组件本文还有配套的精品资源点击获取
