opatch apply是核心命令，但90%失败源于跳过opatch prereq检查、忽略OPatch版本升级（须≥12.2.0.1.28）、未停监听和实例；补丁后还需执行catbundle.sql、utlrp.sql及tnsping验证。
直接上结论：opatch apply 是核心命令，但跳过 opatch prereq 检查、忽略 OPatch 版本升级、不关监听和实例就硬跑，90% 的失败都出在这三步。
OPatch 版本必须 ≥12.2.0.1.28（Oracle 19c）
Oracle 19c 官方明确要求 RU/PSU 补丁（如 19.21、19.24）需搭配 OPatch ≥ 12.2.0.1.28。低于此版本执行 opatch apply 会直接报错：OPatch failed with error code 254。
- 下载对应平台的
p6880880_190000_Linux-x86-64.zip（Linux）或p6880880_190000_Windows.zip（Windows） - 以
oracle用户（单实例）或分别以grid和oracle用户（RAC）解压覆盖$ORACLE_HOME/OPatch - 执行
$ORACLE_HOME/OPatch/opatch version确认输出为OPatch Version: 12.2.0.1.28或更新 - 权限必须正确：
chown -R oracle:oinstall $ORACLE_HOME/OPatch（Linux）；Windows 下需管理员身份运行命令提示符
补丁前必做：prereq 检查 + 服务停用
opatch prereq CheckConflictAgainstOHWithDetail -ph <patch_dir></patch_dir> 不是可选项，是防止补丁覆盖冲突文件的唯一前置防线。跳过它，可能把 libclntsh.so 或 libnnz19.so 覆盖成不兼容版本，导致后续 sqlplus 连不上、ORA-28547 直接炸开。
- 先停监听：
lsnrctl stop（单实例）或srvctl stop listener -l <listener_name></listener_name>（RAC） - 再停数据库实例：
srvctl stop database -d <db_name></db_name>（RAC）或sqlplus / as sysdba → shutdown immediate（单实例） - RAC 环境中，GI Home 必须先于 RDBMS Home 打补丁；顺序反了，
crsctl start crs会卡在ora.cssd启动失败 - 检查磁盘空间：
$ORACLE_HOME所在文件系统剩余空间建议 ≥ 5GB，否则opatch apply中途报错73（空间不足）
opatch apply 执行时的关键细节
命令本身简单，但路径、用户、上下文稍错就失败。常见错误不是语法错，而是环境错。
- 进入
$ORACLE_HOME/OPatch目录后执行，不要用绝对路径调用opatch，否则 inventory 注册可能错位 - 补丁目录必须指向包含
etc/config/inventory.xml的子目录（通常是解压后的一级数字目录，如/tmp/patch/32545013），不是 ZIP 文件所在路径 - Windows 下注意路径分隔符：
opatch apply C:\temp\patch\32545013，别写成斜杠 - 遇到交互提示
Do you want to proceed? [y|n]，输y回车
验证与回滚：别只信 opatch lsinventory
opatch lsinventory 只显示 OPatch 层面注册的补丁，不代表数据库字典已更新、无效对象已编译、监听已恢复可用——这些才是业务真正依赖的部分。
- 启动数据库后必须执行：
@?/rdbms/admin/catbundle.sql psu apply（RU 类补丁用ru apply） - 立即运行：
@?/rdbms/admin/utlrp.sql编译无效对象，再查SELECT COUNT(*) FROM dba_objects WHERE status 'VALID' - 监听启动后，用
tnsping <service_name></service_name>和sqlplus user/pass@tns_alias实测连通性 - 回滚不能只靠
opatch rollback -id <patch_id></patch_id>：若已执行catbundle.sql，需配合datapatch -rollback和utlrp.sql清理字典变更
最易被忽略的是补丁包类型混淆——把 p6880880（OPatch 工具包）当成数据库补丁去 apply，或者把 RU 补丁当 PSU 处理。补丁名里的数字和后缀（如 _190000 vs _112040）不是随便写的，它们绑定着版本兼容边界和执行逻辑。
