必须先升级OPatch至≥12.2.0.1.28、执行opatch prereq检查冲突、停监听和实例，否则90%失败源于这三步；OPatch版本不足会直接报错OPatch failed with error code 254，且RU/PSU补丁如19.21、19.24强制要求该版本。
必须先确认当前 OPatch 版本是否满足 PSU 补丁的最低要求，不达标直接打补丁会失败；补丁必须按 GI → DB 顺序应用，RAC 环境下不能跳过节点滚动操作。
检查并升级 OPatch 版本是否达标
PSU 补丁（如 p27107360_112040_Linux-x86-64.zip）的 README.html 明确要求 OPatch ≥ 11.2.0.3.6（常见要求是 11.2.0.3.23 或更高）。直接运行 opatch version 很可能发现当前版本偏低（比如 11.2.0.3.4）：
- 用
su - oracle进入数据库用户，执行$ORACLE_HOME/OPatch/opatch version - 用
su - grid进入集群用户，执行$GRID_HOME/OPatch/opatch version - 若任一环境版本不足，必须先升级：下载
p6880880_112000_Linux-x86-64.zip，解压覆盖原OPatch目录，并用chown -R oracle:oinstall $ORACLE_HOME/OPatch或chown -R grid:oinstall $GRID_HOME/OPatch修正权限
RAC 环境必须按 GI → DB 顺序滚动打补丁
在 11g RAC 中，opatch auto 是推荐方式，但前提是已生成 ocm.rsp。关键约束是：GI 补丁（含 OCW、ACFS）必须先于 DB 补丁完成，且每个节点要单独停启：
- 先用 root 执行
/u01/app/11.2.0/grid/OPatch/opatch auto /soft/27107360 -oh /u01/app/11.2.0/grid -ocmrf /soft/ocm.rsp（GI 补丁路径需匹配实际解压位置） - 再对 DB Home 执行
/u01/app/oracle/product/11.2.0/db_1/OPatch/opatch auto /soft/27107360 -oh /u01/app/oracle/product/11.2.0/db_1 -ocmrf /soft/ocm.rsp - 两个命令都必须在每个节点上分别执行，不能并行；执行前确保该节点 CRS 已 stop（
crsctl stop cluster -n nodename），执行后需crsctl start cluster -n nodename - 若未建库或
opatch auto报错，退回手工模式：opatch napply用于 GI 组件（如26609929），opatch apply用于 DB 主补丁（如26925576）
打完补丁后必须运行 catbundle.sql
PSU 不仅修改二进制文件，还包含数据字典变更。不执行 SQL 脚本会导致后续升级失败或视图查询异常（例如 v$session 字段缺失、DBA_REGISTRY_SQLPATCH 记录不全）：
- 以
sysdba登录，进入$ORACLE_HOME/rdbms/admin - 执行
@catbundle.sql psu apply（注意不是psu patch或psu install） - 该脚本会自动调用
catbundle_PSU_，耗时取决于数据库大小，期间不可中断_apply.sql - 执行完成后检查
dba_registry_sqlpatch视图，确认STATUS = 'SUCCESS'且BUNDLE_SERIES = 'PSU'
容易被忽略的三个硬性前置动作
跳过任何一项都可能导致补丁中止、实例无法启动或 CRS 异常：
-
crontab中所有涉及sqlplus、rman或srvctl的定时任务必须临时注释（root 和 oracle 用户都要查） - 用
sqlplus "/as sysdba"检查失效对象：select owner, object_name, object_type from dba_objects where status != 'VALID';—— 若存在大量失效对象，先utlrp.sql编译，否则catbundle.sql可能卡住 - 必须备份
$ORACLE_HOME和$GRID_HOME（用tar -cf全量打包），不能只依赖快照或 LVM —— PSU 回滚失败时，只有完整 tar 包能快速恢复
