OPatch版本过低、解压目录结构错误、未停库停监听、catbundle.sql执行失败是RU补丁应用失败的四大主因；须严格按版本要求升级OPatch、命令行解压至单层目录、停库停监听并清理进程、用正确sqlplus执行catbundle.sql。
OPatch 版本不匹配导致 opatch apply 直接失败
oracle 补丁升级最常卡在第一步：opatch 本身版本太低，压根不识别 ru（release update）补丁包结构。19c 的 ru 补丁（比如 36150482）要求 opatch 至少是 12.2.0.1.30，而很多单机环境还停留在 12.2.0.1.17 或更早。
实操建议：
- 先用
$ORACLE_HOME/OPatch/opatch version确认当前版本 - 去 MOS 文档
2118136.2下载对应数据库版本的最新 OPatch（不是通用版，要选 “For Oracle Database”） - 停库后替换：解压新
OPatch覆盖$ORACLE_HOME/OPatch，注意保留原目录权限（尤其opatch可执行位） - 别跳过验证：运行
$ORACLE_HOME/OPatch/opatch lsinventory -detail，确保能正常读取已安装补丁
RU 补丁解压后目录结构不对，opatch apply 报错 OPatch failed with error code 73
RU 补丁 ZIP 包解压后必须是一层目录（如 36150482），里面直接含 etc/、files/、README.txt。有人习惯双击解压或用图形工具，结果多套了一层父文件夹（比如解出 36150482_19c/36150482/），opatch 就找不到元数据。
实操建议：
- 一律用命令行解压：
unzip p36150482_190000_Linux-x86-64.zip -d /tmp/patch - 检查解压结果：
ls -1 /tmp/patch应只输出一个数字目录名，且该目录下有etc/config.xml - 应用时路径必须指向这个数字目录，不是 ZIP 文件，也不是它的父目录：
$ORACLE_HOME/OPatch/opatch apply /tmp/patch/36150482 - 别用
-silent模式起步——首次应用 RU 务必带-oh $ORACLE_HOME显式指定，避免误读环境变量
打 RU 前没停监听和数据库实例，opatch 卡住或报 Prerequisite check "CheckActiveFilesAndExecutables" failed
RU 是滚动补丁（Rolling Update），但单机环境下它**不支持在线打**。只要 lsnrctl 或任何 ora_* 进程在跑，opatch 就会检测到活跃二进制文件并中止，不是警告，是硬性拒绝。
实操建议：
- 停库顺序严格：先
lsnrctl stop，再sqlplus / as sysdba执行shutdown immediate - 确认无残留进程：
ps -ef | grep -E "(ora_|tnslsnr|oracle.*$ORACLE_SID)"，全 kill 干净（尤其注意后台ora_q00*或ora_cjq0进程） - 检查
$ORACLE_HOME/rdbms/lib/config.o和$ORACLE_HOME/lib/libserver19.a是否被占用（lsof -p $(pgrep -f "ora_pmon")可查） - 临时关闭 systemd 服务（如果用了）：
systemctl stop oracle-database.target，避免 systemctl 自动拉起实例
打完 RU 后启动库报 ORA-00704: bootstrap process failure 或 ORA-00604: error occurred at recursive SQL level 1
这是 RU 补丁里包含的 SQL 部分（catbundle.sql）没成功执行。常见原因是：打补丁时没用 sqlplus /nolog 连接，或者 catbundle.sql 路径写错、权限不足、SQL*Plus 版本不匹配（比如用 12c 的 sqlplus 运行 19c 的 bundle 脚本）。
实操建议：
- RUN
catbundle.sql必须在补丁应用完成后立即执行，且必须用当前$ORACLE_HOME/bin/sqlplus - 命令格式固定：
sqlplus /nolog @?/rdbms/admin/catbundle.sql psu apply（注意是psu，不是ru；RU 在内部仍沿用 PSU 的脚本名） - 检查
$ORACLE_HOME/cfgtoollogs/catbundle/下日志，重点看catbundle_PSU_<sid>_APPLY_<date>.log</date></sid>末尾是否有 “PL/SQL procedure successfully completed” - 若失败，不要重跑
catbundle.sql—— 先查 MOS 文档对应 RU 的已知问题（比如某些 RU 要求先打特定 One-Off 补丁）
RU 补丁真正麻烦的从来不是操作步骤，而是每个环节都依赖前序状态精确匹配：OPatch 版本、目录结构、进程状态、SQL*Plus 版本、甚至 catbundle 的调用参数大小写。漏掉任意一个，都会在某个环节静默失败或报错晦涩。
