控制文件被覆盖后，CATALOG 还能救回来吗？
直接“恢复”那个已经被覆盖的物理控制文件？这条路走不通。但事情并非毫无转机——如果你启用了恢复目录（recovery catalog），并且之前执行过 resync catalog 操作，那么就有可能从目录中提取出旧控制文件的结构快照元数据。当然，这一切有个大前提：这些关键的元数据没有被后续的同步操作冲刷掉。
确认恢复目录里有没有可用的旧控制文件信息
问题的关键，不在于“有没有备份”，而在于“有没有被同步进目录”。要知道，恢复目录里并不存储控制文件本身的二进制副本，它保存的只是一份结构快照，比如数据文件的路径、检查点SCN、归档日志的范围等等。要想利用这份快照，必须满足两个条件：
- 在发生
RECOVER DATABASE USING BACKUP CONTROLFILE这类需要旧控制文件信息的情况之前，数据库曾经通过RESYNC CATALOG命令向目录同步过状态。 - 在那次同步之后，没有再执行过覆盖性的
RESYNC操作。例如，如果数据库打开后又做了一次全量同步，很可能会刷新掉旧的快照记录。
怎么查呢？首先连接到目录数据库：
CONNECT CATALOG rman_user@catdb
RMAN> LIST INCARNATION OF DATABASE;
查看是否存在多个 INCARNATION#（ incarnation 记录）。接着，使用命令：
RMAN> LIST BACKUP OF CONTROLFILE;
确认是否有早于控制文件被覆盖时间点的备份记录。这里需要明确：有记录不等于一定有可用的元数据，但如果连记录都没有，那基本就无计可施了。
RESTORE CONTROLFILE FROM CATALOG 实际上不成立
千万别被这个命令的字面意思误导了：RESTORE CONTROLFILE FROM CATALOG 是无效语法，RMAN 并不支持直接从恢复目录里“拉”出一个二进制的控制文件。真正可行的操作，其实只有两件：
- 使用
RESTORE CONTROLFILE FROM 'backup_piece_path'来恢复一个已经存在的控制文件备份（这要求你事先确实做过备份）。 - 如果没有现成的备份，但恢复目录里存有足够老的元数据，那么可以尝试手动重建控制文件：
CREATE CONTROLFILE REUSE DATABASE ...。这条命令里的DATAFILE列表、LOGFILE路径、RESETLOGS选项等关键信息，都需要依靠LIST BACKUP OF DATABASE和LIST ARCHIVELOG ALL这类命令，从恢复目录里反推出来。
这里有个常见的误区：很多人以为 RESYNC CATALOG 会自动保存控制文件的历史快照。其实不然，它只会更新目录里的当前状态。旧的状态只保留在上次同步到本次同步之间的那个时间窗口内。而且，通常只有在数据库发生重置（RESETLOGS）时，才会生成新的 INCARNATION 记录。
重建控制文件时，哪些元数据能从目录里捞出来？
能从恢复目录里获取的，并非一个“完整的快照”，而是一些离散的字段信息。例如：
DBA_DATA_FILES视图对应的FILE_NAME和FILE_ID—— 这些信息可以从LIST BACKUP OF DATABASE命令输出的datafile行里找到。- 在线日志组的位置和大小 —— 查询
LIST BACKUP OF ARCHIVELOG ALL得到的ARCHIVED LOG记录，再结合V$LOG历史视图（如果目录同步足够及时）进行推测。 - 检查点SCN ——
LIST BACKUP OF DATABASE结果中，每个备份集的checkpoint SCN字段通常是相对最可靠的来源。
需要特别警惕的是：在编写 CREATE CONTROLFILE 语句时，如果漏掉了任何一个当前仍处于活动状态的数据文件路径，或者写错了 RESETLOGS 与 NORESETLOGS 选项，都可能导致 ORA-01507 错误，或者让数据库一直挂起在 MOUNT 阶段。恢复目录不会帮你校验语法是否正确，它仅仅提供原始的线索。
最后，还有一个最容易被忽略的点：恢复目录数据库（例如 catdb）本身可能没有开启归档模式，或者没有配置闪回区。这会导致你执行 LIST 命令时，查到的结果全是空的。遇到这种情况，首先要做的是确认目录数据库自身的健康状态，而不是急于责怪 RMAN 工具不给力。
