fpp是oracle 19c rac集群超3节点后唯一合规路径，因其基于黄金镜像原子切换、全栈一致性校验及原生gi调度实现真滚动；opatchauto则强制停crs导致业务中断，且无法回滚、易引发crs-2674或ora-29516错误。
fpp不是“简化运维”的可选工具，而是19c rac集群超过3个节点后唯一能避免补丁失败和版本漂移的合规路径。 用 opatchauto 在5节点rac上打ru，大概率触发 crs-2674 或 ora-29516，且无法回滚；fpp从设计上就规避了这类问题——它不碰旧home，所有变更都在新gold image里完成，验证通过才切换。
为什么FPP能真正滚动、而opatchauto只是“假装滚动”
关键区别在启动/停止逻辑和一致性校验层级：opatchauto 执行时会强制调用 crsctl stop crs，导致该节点整个GI栈下线，业务必然中断；FPP则由 crsctl 原生调度，只停非关键实例（如非主服务实例），保留ASM和Clusterware在线，并自动校验全栈（GI + DB + ASM + ACFS）哈希一致性。一旦某节点校验失败，整个部署暂停，不会继续滚动到下一节点。
- RU类补丁含字典变更，
v$version和registry$sqlpatch必须全局一致——FPP通过黄金镜像+原子切换保障这点，opatchauto无法做到 - FPP部署时自动运行
datapatch -verbose，且确保在所有PDB OPEN后执行；opatchauto不触发此步骤，需人工补，极易遗漏 - 跨版本升级（如19.18 → 19.22）仅FPP支持；
opatchauto严格限制同版本内RU/MRP
fppcli deploy命令必须带--goldimage而非--patch
这是最常踩的坑：fppcli 不接受补丁包路径作为直接输入。所有补丁必须先注入黄金镜像，再部署该镜像。所谓“打补丁”，实际是“切换到已预装补丁的新Home”。
- 创建镜像：用
fppcli create goldimage --name GI_19c_RU2026Q1 --source /stage/23ai_ru_jan2026（注意--source指向解压后的目录，不是ZIP） - 部署镜像：用
fppcli deploy --target rac_cluster --goldimage GI_19c_RU2026Q1，不能写成--patch - 若漏掉创建步骤直接deploy，报错是
FPP-00217: Gold image not found，而非补丁路径错误
初始化FPP前必须验证的三个硬性条件
FPP服务由GI托管，但90%初始化失败源于环境未达标。以下检查必须在所有节点并行执行，任一不满足即卡住：
-
crsctl check cluster和crsctl check gi必须返回CRS-4537或CRS-4529以外的状态（即不能是“not ready”或“failed”） -
/u01/app/19.0.0.0/grid/crs/install/fpp目录存在且属主为root:oinstall；缺失需运行gridSetup.sh -executeConfigTools -configureFPP -
asmcmd lsdg | grep fpp必须显示ora.fpp.dg在线，且为外部冗余、剩余空间 ≥20GB（用于快照存储）
黄金镜像不是一次性的“备份”，而是持续演进的基线——每次新RU进来都基于前一个镜像构建，所以磁盘组空间和镜像生命周期管理比补丁本身更关键。别等 fppcli deploy 卡在“creating snapshot”才去查 ora.fpp.dg 空间。
