主库做了不完全恢复后 OPEN RESETLOGS，备库直接罢工，V$ARCHIVE_GAP 显示序列 45 到 52 断了，RMAN 报 ORA-19906。这种故障我处理过不下五次，但 26ai 的 incarnation 管理跟 19c 有点不一样，多了一层 PDB 级 incarnation，把我绕进去三天。

3.1 RESETLOGS 到底改了什么

OPEN RESETLOGS 做三件事：第一，重置在线日志序列号为 1；第二，在控制文件里生成一个新的 incarnation 记录，带新的 resetlogs_change# 和 resetlogs_time；第三，更新所有数据文件头的 resetlogs SCN。备库的 Recovery 进程启动时，会先比对数据文件头的 resetlogs SCN 和控制文件的 current incarnation，如果对不上，它就认为"这 redo 不是给我准备的"，拒绝应用。

26ai 的新坑在于 PDB 级 incarnation。CDB 有一个 incarnation 链，每个 PDB 还有自己的子链。主库 RESETLOGS 后，CDB 的 incarnation 变了，但某个 PDB 如果没参与不完全恢复，它的 PDB incarnation 可能还是旧的。备库收到 redo 后，CDB 层说"这是新的 incarnation"，PDB 层说"不对，我还在旧 incarnation"，两边打架， Recovery 进程直接躺平。

3.2 实验：手动切换 incarnation 的两种路径

-- 路径 A：RMAN 自动处理（推荐）
RMAN> LIST INCARNATION OF DATABASE;
-- 看到主库已经切到 incarnation 5，备库还在 incarnation 4

RMAN> RESET DATABASE TO INCARNATION 5;
RMAN> RECOVER DATABASE;
-- 26ai 里如果开了 PDB 级 DG，还要额外：
RMAN> RECOVER PLUGGABLE DATABASE pdb_sales;

-- 路径 B：手工改控制文件（应急，不推荐）
-- 从主库 trace 备份控制文件，传到备库
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM '/tmp/cf_backup_trace.ctl';
ALTER DATABASE MOUNT;
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
ALTER DATABASE OPEN RESETLOGS;

-- 路径 B 的风险：如果主库和备库的数据文件路径不一样，
-- 控制文件里的路径映射会乱，需要手动 rename datafile

我那次走了弯路：一开始用路径 B，结果 PDB 的数据文件路径在主备库不一致，恢复时找不到文件，报 ORA-01565。后来老老实实走路径 A，RMAN 的 RESET DATABASE TO INCARNATION 会自动处理 PDB 的路径映射，虽然慢点（因为要重新编目所有归档），但稳。

最后给个忠告：不完全恢复前，先在主库做 ALTER SYSTEM ARCHIVE LOG CURRENT，把当前在线日志归档，这样 RESETLOGS 后备库至少能拿到一个连续的起点。另外，26ai 的 PDB 级 DG 建议把每个 PDB 的 incarnation 历史定期导出到 trace，别等故障发生了再去找 MOS。