恢复控制文件后，RESTORE DATABASE 不还原新数据文件，因为控制文件仅包含备份时刻的结构快照，新增数据文件未被记录在 v$datafile 中，RMAN 无法识别其存在，故跳过恢复。
因为控制文件恢复后，它只包含备份时刻的数据库结构快照，不自动感知之后新增的数据文件；RMAN 依赖控制文件记录的 datafile 列表来决定恢复哪些文件，新增文件若未被写入该快照，就“不存在”于恢复上下文中。
恢复控制文件后，为什么 RESTORE DATABASE 不还原新数据文件
控制文件是 RMAN 的唯一元数据源。用 RESTORE CONTROLFILE 或 RESTORE CONTROLFILE FROM AUTOBACKUP 恢复后，该控制文件内容定格在备份生成时间点——哪怕你刚在源库执行过 ALTER TABLESPACE users ADD DATAFILE，只要没做 BACKUP CURRENT CONTROLFILE，新文件就不会出现在恢复后的控制文件中。
-
RESTORE DATABASE只会处理控制文件里v$datafile视图中列出的file#，新增文件的file#根本不在列表里 - 即使磁盘上已有新数据文件（比如手动拷贝或 OMF 自动创建），RMAN 也不会主动扫描或注册它们
- 如果强行
RECOVER DATABASE，RMAN 在应用归档日志时会遇到新文件的重做记录，但找不到对应的数据文件实体，从而报ORA-01115或ORA-01157
如何让 RMAN “看到”并恢复新增的数据文件
必须把新增文件显式纳入当前控制文件的管理范围，不能靠 RMAN 自动发现。
- 确认新增文件是否已在控制文件中：查
SELECT file#, name, status FROM v$datafile WHERE status = 'RECOVER' OR name LIKE '%MUST_RENAME%'；若没出现，说明控制文件还不知道它 - 如果新增文件已物理存在（如 ASM 中可 ls 到），用
CATALOG DATAFILECOPY '+DATA/.../newfile.256.123456789'手动注册其副本（路径必须和asmcmd ls输出完全一致） - 如果新增文件尚未创建，需先用
ALTER DATABASE CREATE DATAFILE '/path/to/new.dbf' AS '/path/to/new.dbf'建空壳（仅限非系统表空间），再RESTORE DATAFILE <file></file> - 执行
SWITCH DATAFILE <file> TO COPY</file>或SWITCH DATAFILE ALL，让控制文件指向刚注册的副本路径
REPORT SCHEMA 显示新文件但 RESTORE 仍跳过？检查这三点
REPORT SCHEMA 能显示新增文件，不代表 RMAN 就能用它恢复——关键看该文件是否处于“可恢复状态”。
- 检查
v$datafile_header.name是否为空或为MUST_RENAME_THIS_DATAFILE：若是，说明文件头损坏或路径未解析，RESTORE会跳过 - 确认该文件在
LIST BACKUP OF DATAFILE <file></file>中有有效备份集；若无，RMAN 默认不尝试恢复（除非加FORCE） - 验证归档日志是否覆盖该文件的创建 SCN：用
SELECT creation_change# FROM v$datafile WHERE file# = <n></n>，再查V$ARCHIVED_LOG确保有从该 SCN 开始的日志
最易被忽略的是：控制文件恢复后，你得把它当做一个“旧版本快照”，所有后续变更都得手工补全——RMAN 不会帮你自动同步结构演进。
