必须用fpp而非opatchauto，因fpp是gi原生组件，支持原子回滚、跨版本升级及全栈一致性校验，而opatchauto属传统in-place方式，易致ora-29516或crs-2674错误。
oracle 19c rac集群规模一旦超过5个节点，手动用opatch或opatchauto逐台打补丁已不可持续——fpp不是“可选项”，而是oracle官方在2026年明确推荐的唯一合规路径。
为什么必须用FPP而不是继续用opatchauto
FPP是Grid Infrastructure原生组件，直接集成在crsctl和srvctl生命周期中；而opatchauto仍属传统in-place patching逻辑，不支持跨版本升级、无法原子回滚、且在RAC多实例场景下容易因节点patch顺序不一致导致ORA-29516或CRS-2674错误。
- FPP所有操作基于“黄金镜像（Gold Image）”，补丁实际写入新Oracle Home，旧Home保留至验证通过后才清理
- 补丁过程由GI自动协调节点顺序：先停非关键实例→应用补丁→启动并校验→再滚动至下一节点，无需人工干预启停
-
opatchauto在Exadata或Flex ASM配置下会跳过ASM补丁校验，FPP则强制校验GI stack全栈一致性
初始化FPP前必须检查的3个硬性前提
FPP服务本身由Grid Infrastructure托管，但初始化失败90%源于环境未达标。以下检查必须在所有RAC节点上执行：
- 确认
crsctl check cluster和crsctl check gi全部返回CRS-4537和CRS-4529以外的状态 - 确保
/u01/app/19.0.0.0/grid/crs/install/fpp目录存在且权限为root:oinstall（若缺失需运行gridSetup.sh -executeConfigTools -configureFPP） - 验证
ora.fpp.dg磁盘组是否在线：asmcmd lsdg | grep fpp，该DG必须为外部冗余且剩余空间≥20GB（用于存储黄金镜像快照）
fppcli命令的关键参数陷阱
fppcli是FPP唯一交互入口，但其参数设计反直觉：多数操作依赖--goldimage而非--patch，因为补丁必须先注入黄金镜像再部署。
- 创建黄金镜像时，
--source必须指向已解压的RU包根目录（如/stage/23ai_ru_jan2026），不能指向ZIP文件 - 执行
fppcli deploy --target rac_cluster --goldimage GI_19c_RU2026Q1时，若报错FPP-00217: Target not registered，说明未运行fppcli register --type cluster --name rac_cluster -
--force参数仅跳过版本兼容性检查，但不会跳过GI stack完整性校验；强行使用可能导致ora.asm资源进入INTERMEDIATE状态
补丁验证阶段最容易被忽略的2个动作
FPP显示DEPLOYMENT SUCCESSFUL只是第一步。真正决定是否可切流的是验证结果，而验证默认不包含业务SQL连通性测试。
- 必须手动运行
fppcli verify --target rac_cluster --check dbstatus，否则可能遗漏某节点srvctl status database显示UNKNOWN的问题 - 对于启用Data Guard的集群，需额外执行
fppcli verify --target rac_cluster --check dg_sync，否则可能发现主库已升级但备库仍卡在旧RU版本
黄金镜像一旦生成，后续所有补丁都复用该基线——这意味着镜像里残留的旧补丁日志、临时patch冲突标记（如$ORACLE_HOME/.patch_storage下的conflict子目录）会污染新部署。每次fppcli create goldimage前，务必清空源Oracle Home的.patch_storage目录，这是FPP文档里没写、但现场踩坑最频繁的一环。
