数据库基础体系 · 第 30/139 篇。文章以各产品官方稳定版本的公开语义为准；示例会明确引擎、事务与部署边界。

Oracle RMAN、Data Guard 与 RAC：备份恢复和高可用边界

在 Oracle 生产架构中，RMAN、Data Guard 和 RAC 经常同时出现，但它们解决的不是同一个问题：

  • RMAN 负责备份、还原和恢复，核心目标是“数据损坏或丢失后能否重建数据库”。
  • Data Guard 负责把主数据库产生的 redo 传送并应用到备用数据库，核心目标是“另一套数据库能否接替主库”。
  • RAC 负责让多个实例同时访问同一个数据库，核心目标是“单实例或部分节点故障时，数据库服务是否仍可用”。

三者可以组合，但不能互相替代：

RAC：同一个数据库 + 多个实例，主要解决实例和节点级可用性
Data Guard：多个数据库之间的 redo 复制，主要解决站点和数据库级灾难恢复
RMAN：备份集、映像副本、归档日志与控制文件的恢复工具，主要解决数据恢复

如果数据库文件被误删除，RAC 不会自动生成这些文件；如果整个主站点被摧毁，单独的 RAC 也无法提供另一份数据库；如果备用库上的数据已经被逻辑错误破坏，Data Guard 可能会忠实地复制这个错误，而 RMAN 的历史备份或时间点恢复才可能提供回退路径。

一、先建立恢复问题的边界

1. 备份、还原、恢复不是同一个动作

Oracle 中常见的三个概念容易混淆：

  • Backup（备份）：把数据文件、控制文件、SPFILE、归档日志等保存到备份介质。
  • Restore（还原）：从备份介质取回文件。例如把一个数据文件还原到磁盘。
  • Recover（恢复）：使用 redo 或归档日志，把还原出来的文件推进到一致状态。

例如：

数据文件备份：数据库在 SCN 1000 时的文件副本
归档日志：包含 SCN 1001 到 1300 的 redo
恢复：将数据文件应用这些 redo，使其达到 SCN 1300

仅执行 RESTORE DATABASE，不代表数据库已经恢复到可打开状态。还原出的数据文件之间可能对应不同时间点，文件内部也可能存在尚未落盘的事务修改；RECOVER DATABASE 才是利用 redo 重建一致状态的过程。

2. RPO 和 RTO 的含义

RPO（Recovery Point Objective） 是故障后最多可以丢失多长时间或多少数据。
RTO（Recovery Time Objective） 是从故障发生到业务恢复所允许的最长时间。

它们不是 Oracle 参数，而是恢复目标：

  • 只每天做一次备份，且没有持续归档，RPO 可能接近一天。
  • 主库同步传输 redo 到备用库并确认提交，理论上可以把已提交数据的 RPO 降到接近零，但这不等于任何故障下都绝对零数据丢失。
  • 备用库已经实时应用 redo，通常比从磁带或对象存储恢复整库更快，因此有助于降低 RTO，但切换、DNS、连接池和应用重连仍可能成为总 RTO 的主要部分。

一个恢复方案必须同时回答：

丢多少数据可以接受？
恢复多快必须完成？
恢复后的数据是否需要保留误操作发生前的时间点？
故障是实例故障、存储故障、主机故障，还是整个站点故障？

二、理解 RMAN：它恢复的是 Oracle 数据库状态

1. RMAN 管理哪些对象

RMAN（Recovery Manager）是 Oracle 提供的数据库备份与恢复工具。典型对象包括：

  • 数据文件（datafile）
  • 控制文件（control file）
  • SPFILE
  • 归档重做日志（archived redo log）
  • 备份集（backup set）
  • 映像副本（image copy）
  • 恢复目录（recovery catalog，可选）
  • 快速恢复区（Fast Recovery Area，简称 FRA）

RMAN 通过目标数据库的控制文件记录备份元数据。也可以把元数据存放到独立的恢复目录数据库中。恢复目录不是备份数据本身；如果只有恢复目录而备份片段已经丢失，仍然不能恢复数据库。

FRA 是 Oracle 管理的一块存储区域，常用于保存归档日志、闪回日志、控制文件自动备份和 RMAN 备份。FRA 不是“无限可靠的备份仓库”：空间不足时，Oracle 会依据可删除性管理文件；它也可能与数据库处于同一存储系统，不能自动提供站点级保护。

2. RMAN 备份的两种基本形态

备份集

备份集由一个或多个备份片组成，可以包含压缩、未使用块跳过等处理。恢复时由 RMAN 读取备份片并还原数据库文件。

映像副本

映像副本是数据文件的文件级副本，通常便于快速切换或使用增量合并。它仍然需要 redo 恢复才能保证一致性。

备份集和映像副本都不是“应用层导出”。RMAN 备份保留的是 Oracle 物理结构，恢复时依赖 Oracle 的控制文件、数据文件和 redo 语义。

3. 增量备份的准确含义

RMAN 的增量备份以数据块变化为单位：

  • Level 0：基准增量，作用接近完整备份。
  • Level 1 differential：记录自最近一个父级增量备份以来变化的块。
  • Level 1 cumulative：记录自最近一个 Level 0 以来变化的块。

例如：

周日：Level 0
周一：Level 1 differential，记录周日以来变化的块
周二：Level 1 differential，记录周一以来变化的块

恢复周二状态通常需要 Level 0、周一增量、周二增量以及之后所需的归档日志。

如果使用 cumulative：

周日：Level 0
周一：Level 1 cumulative，记录周日以来变化的块
周二：Level 1 cumulative，仍记录周日以来变化的块

恢复周二时不需要周一的 Level 1，但周二增量通常更大。

Block Change Tracking（块变化跟踪） 可以让 Oracle 记录哪些数据块发生过变化，从而减少 RMAN 增量备份扫描的工作量。它优化的是识别变化块的过程，不会改变恢复所需的 redo，也不会让丢失的归档日志凭空出现。

三、Redo、SCN 与 RMAN 恢复的因果链

理解 RMAN 必须先理解 redo。

1. redo 记录什么

事务修改数据块时，Oracle 会生成描述这些修改的 redo。事务提交时，提交相关的 redo 必须按 Oracle 的持久性规则写入在线 redo log；这就是事务持久性与 redo 的联系。

SCN（System Change Number） 是 Oracle 用来表示数据库逻辑时间和一致性进度的单调递增编号。它不是简单的墙上时钟，但可以用于描述：

某个数据文件备份在什么数据库进度上
某条归档日志覆盖哪个 redo 范围
恢复目标位于哪个逻辑时间点

一个简化算例：

数据文件备份结束时：checkpoint SCN = 1000
归档日志 A：包含 SCN 1001 至 1100
归档日志 B：包含 SCN 1101 至 1250
恢复目标：SCN 1200

恢复过程是：

  1. 从备份还原数据文件；
  2. 应用归档日志 A，推进到至少 SCN 1100；
  3. 应用归档日志 B，但只应用到 SCN 1200；
  4. 根据 Oracle 的事务和一致性规则完成恢复；
  5. 如果这是不完全恢复，通常需要以 RESETLOGS 打开数据库，形成新的 incarnation。

如果缺失覆盖 SCN 1101 至 1200 的 redo，RMAN 无法凭借数据文件备份推导出这些修改。RMAN 报错的本质通常是：恢复链不完整，而不是“命令少执行了一次”。

2. 为什么数据文件备份必须配合归档日志

数据文件可能在不同时间被写入，备份过程中也可能有并发事务。Oracle 允许在线备份，但要想把备份恢复到一致状态，必须保留从备份所需起点到恢复目标之间的 redo。

因此：

在线数据文件备份 + 完整归档日志链

才构成可恢复的组合。

只保留每日数据文件备份而删除中间归档日志，可能仍能恢复到备份完成附近；但不能恢复到任意更近的时间点，也不能保证跨文件恢复链完整。

3. Undo 与恢复的关系

Undo 主要用于：

  • 回滚未提交事务；
  • 提供一致性读；
  • 支持部分闪回能力。

Redo 用于重做已记录的修改，Undo 是被修改前的信息及其管理结构。恢复期间，Oracle 既要应用 redo，也要根据事务状态处理未提交事务。因此“恢复就是把备份文件复制回来”是不完整的描述。

例如，数据块中存在一个尚未提交的修改：

数据块备份时包含该修改
事务尚未提交
恢复时 redo 重建了数据块
事务状态显示未提交
Oracle 使用 undo 将该修改回滚到一致状态

这也是为什么恢复后的数据库不能简单按照操作系统文件复制来判断一致性。

四、RMAN 的基本生命周期与命令示例

下面示例假设：

  • 数据库名为 FINDB
  • 已配置归档日志模式
  • RMAN 连接到目标数据库
  • 备份目录 /backup/findb 已存在且由 Oracle 软件用户可写
  • 生产环境已经规划好备份保留策略

1. 备份数据库、归档日志和控制文件

rman target /

CONFIGURE CONTROLFILE AUTOBACKUP ON;

BACKUP AS COMPRESSED BACKUPSET
  DATABASE
  FORMAT '/backup/findb/db_%d_%T_%U.bkp';

BACKUP ARCHIVELOG ALL
  FORMAT '/backup/findb/arch_%d_%T_%U.bkp'
  DELETE INPUT;

BACKUP CURRENT CONTROLFILE
  FORMAT '/backup/findb/ctl_%d_%T_%U.bkp';

BACKUP SPFILE
  FORMAT '/backup/findb/spfile_%d_%T_%U.bkp';

每一步的含义：

  • CONFIGURE CONTROLFILE AUTOBACKUP ON：让 RMAN 在相关备份操作后自动备份控制文件和 SPFILE。生产上仍应验证备份文件确实产生。
  • BACKUP DATABASE：备份数据库数据文件。
  • BACKUP ARCHIVELOG ALL：保存归档日志。DELETE INPUT 会删除已备份的归档日志，因此只有在确认备份成功且保留策略允许时才可使用。
  • BACKUP CURRENT CONTROLFILE：保存当前控制文件。控制文件丢失时，数据库需要它来识别数据文件和恢复元数据。
  • BACKUP SPFILE：保存实例启动参数。

FORMAT 只是文件命名格式，不代表备份已经复制到异地。若 /backup/findb 与数据库使用同一存储阵列，阵列级故障可能同时摧毁数据和备份。

2. 验证备份是否可读

LIST BACKUP SUMMARY;
CROSSCHECK BACKUP;
RESTORE DATABASE VALIDATE;
VALIDATE ARCHIVELOG ALL;

区别如下：

  • LIST BACKUP SUMMARY：查看 RMAN 元数据中的备份。
  • CROSSCHECK BACKUP：检查 RMAN 记录的备份是否仍存在于介质上；找不到的备份会被标记为 EXPIRED。
  • RESTORE DATABASE VALIDATE：验证 RMAN 是否能从现有备份读取并还原数据库所需的数据块，但不会真正覆盖数据文件。
  • VALIDATE ARCHIVELOG ALL：检查归档日志是否可读取、是否存在损坏。

这些命令不能证明“完整灾难恢复一定能成功”。真正可靠的验证还需要在隔离环境执行恢复演练，包括控制文件恢复、归档日志恢复、数据库启动和应用连接测试。

3. 完整恢复与不完全恢复

在数据库文件损坏但希望恢复到最新可用状态时，典型流程是：

STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;

这里要求：

  • 数据库处于 MOUNT，因为恢复需要访问控制文件但通常不能让数据库以正常方式打开；
  • RESTORE DATABASE 找到可用的数据文件备份；
  • RECOVER DATABASE 找到所需的归档日志或在线 redo；
  • 恢复链覆盖数据文件备份到目标恢复点。

如果要恢复到特定时间点，必须明确这是不完全恢复：

STARTUP MOUNT;

SET UNTIL TIME "TO_DATE('2025-03-08 14:30:00',
                         'YYYY-MM-DD HH24:MI:SS')";

RESTORE DATABASE;
RECOVER DATABASE;

ALTER DATABASE OPEN RESETLOGS;

SET UNTIL TIME 的目标时间必须与数据库时区、业务事件时间和日志记录方式一致。更精确的操作可以按 SCN 或日志序列指定，但不能把“应用提交时间”直接等同于“某个归档日志文件名”。

执行不完全恢复并以 RESETLOGS 打开后，Oracle 会建立新的 redo 日志历史分支，即新的 incarnation。之前的备份并没有自动失效，但后续 RMAN 操作必须正确识别当前 incarnation；否则可能出现备份属于旧分支、恢复目标不匹配等问题。

五、Data Guard：把 redo 复制成另一套数据库

1. Data Guard 的组件和数据流

一个典型 Data Guard 配置包括：

  • Primary database：主数据库，接受业务读写。
  • Standby database：备用数据库，接收并应用主库 redo。
  • Redo transport：主库将 redo 传送到备用库。
  • Standby redo log（SRL）：备用库接收实时 redo 的日志组。
  • Log apply services：备用库将 redo 应用到数据文件。
  • Broker：可选的管理框架，通过 DGMGRL 管理配置、切换和状态。
  • Observer：在某些自动故障切换场景中观察主库和备用库可达性。

数据流可以简化为：

事务修改
  ↓
Primary instance 生成 redo
  ↓
在线 redo log
  ↓
Redo transport
  ↓
Standby redo log
  ↓
Log Apply
  ↓
Standby datafiles

Data Guard 的物理备用库通常接收与主库相同的物理 redo，并通过介质恢复机制应用；逻辑备用库则将 redo 转换为逻辑 SQL 等形式，支持的对象和语义边界不同。实际选择必须依据版本、数据类型、应用特征和官方支持矩阵，不能把逻辑备用库简单当作物理副本。

2. 传输模式与提交语义

Redo 传输至少涉及两个维度：

  • 同步（SYNC）或异步（ASYNC）
  • 传输确认是否影响主库提交

同步传输时，主库会等待远端对 redo 接收或写入的相应确认；异步传输时，主库不必等待备用库完成接收，因此通常对主库提交延迟影响较小，但主库故障时可能存在尚未传到备用库的 redo。

保护模式通常包括：

  • Maximum Performance：通常使用异步传输，优先主库性能，允许一定数据丢失。
  • Maximum Availability：目标是同步保护；在备用库暂时不可用时，系统可根据配置退化为异步，以保持主库可用。
  • Maximum Protection：要求事务 redo 得到同步保护；若无法满足保护条件，主库可能停止处理事务，以避免违反零数据丢失目标。

这里的“零数据丢失”必须限定在满足同步确认、故障类型和部署条件的范围内。网络分区、双重故障、备用库不可恢复、存储确认语义异常等情况都会改变结论。同步传输也不等于应用已经执行完这些事务；“已接收”“已写入 SRL”“已应用到数据文件”是不同进度。

3. 备用库的多个进度点

诊断 Data Guard 时不能只看“备用库连接正常”。至少应区分：

Primary generated：主库已经生成的 redo
Transported：已经传到备用库的 redo
Received：备用库已经接收的 redo
Applied：备用库已经应用的 redo

例如：

主库最新 SCN：500000
备用库接收 SCN：499900
备用库应用 SCN：499700

这表示存在两类差距：

  • 传输延迟：500000 - 499900
  • 应用延迟：499900 - 499700

备用库可能已经接收了日志，但应用进程因数据文件 I/O、坏块、缺少日志或冲突而停止。此时仅检查传输状态会误判高可用状态。

常用检查入口包括：

SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE,
       PROTECTION_LEVEL, SWITCHOVER_STATUS
FROM V$DATABASE;

SELECT PROCESS, STATUS, THREAD#, SEQUENCE#
FROM V$MANAGED_STANDBY;

不同版本中进程名称和视图列可能存在差异，生产诊断应以当前版本文档为准。更完整的 Data Guard 状态通常通过 Broker 查看：

dgmgrl /

SHOW CONFIGURATION;
SHOW DATABASE VERBOSE 'FINDB_STBY';

SHOW CONFIGURATION 关注配置整体是否为 SUCCESS；若显示警告，应继续查看具体数据库、传输错误、应用错误和延迟，而不是把 SUCCESS 当作“已经通过恢复演练”。

4. 切换、故障切换与重新加入

Switchover（切换） 是计划内角色转换。原主库通常仍然可用，并在协议完成后成为备用库。这适合维护、机房演练和计划迁移。

Failover（故障切换） 是原主库不可用或不应继续承担主角色时，将备用库提升为主库。原主库可能仍含有未传输的 redo，因此故障切换可能产生数据丢失；是否能做到零数据丢失取决于保护模式和故障状态。

故障切换后，原主库不能直接当作“自动变回备用库”。通常需要：

  1. 确认原主库不再对外提供写入，避免双主；
  2. 判断是否能通过闪回数据库回到共同时间线；
  3. 将原主库转换或重新创建为备用库；
  4. 重新建立 redo transport 和 apply；
  5. 验证新的主备关系。

若两个站点都以为自己是主库，就形成 split-brain（脑裂）。Data Guard 的高可用机制不能替代网络隔离、仲裁和故障处理流程。

5. Data Guard 不是备份

Data Guard 实时复制主库的变化，因此它不能天然防止：

  • 误删除表；
  • 错误批量更新；
  • 恶意操作；
  • 应用程序写入错误数据。

这些操作会以合法 redo 的形式被复制并应用到备用库。备用库可以降低硬件、主机和站点故障的恢复时间，但不能替代具有历史保留周期的 RMAN 备份。

备用库可以作为 RMAN 备份来源，以减少主库备份 I/O。这样做时必须确保：

  • 备用库具有完成备份所需的文件和日志；
  • 备份元数据与恢复目录或控制文件一致；
  • 备份片被复制到独立、可访问的存储；
  • 主库故障时仍知道这些备份的位置和保留期限。

“从备用库做过备份”不等于“备份安全地存放在备用库所在的同一故障域之外”。

六、RAC：一个数据库中的多个实例

1. RAC 的组件和一致性模型

RAC（Real Application Clusters）允许多个实例访问同一组数据库文件：

Instance 1 ─┐
Instance 2 ─┼── Shared Storage ── Database files
Instance 3 ─┘

每个实例通常拥有自己的：

  • SGA 和后台进程；
  • 在线 redo 线程；
  • undo 表空间；
  • 实例状态。

数据库文件、控制文件等是共享的。多个实例通过集群互联协调缓存块访问，这个机制通常称为 Cache Fusion。一个实例需要访问另一个实例内存中持有的修改块时，可以通过集群互联获取，而不必先把块写回磁盘。

因此 RAC 不是简单的“多个 Oracle 进程同时打开同一批文件”。它需要集群管理、实例注册、互联通信、共享存储以及全局缓存一致性协议。

2. RAC 如何处理事务、锁和 redo

RAC 中每个实例有自己的 redo thread。假设：

Instance 1 使用 thread 1
Instance 2 使用 thread 2

两个实例可以并发执行事务。全局锁和缓存一致性机制负责协调对同一数据块或同一行的访问；事务仍然遵守 Oracle 的锁、SCN、Undo 和读一致性语义。

RAC 下的 RMAN 恢复必须考虑多个 redo thread：

thread 1：sequence 101、102、103
thread 2：sequence 201、202、203

数据库恢复不能只收集 thread 1 的归档日志。只要 thread 2 中存在恢复目标所需的 redo，缺少它就可能导致恢复失败或无法推进到目标 SCN。

这也是 RAC 与单实例备份的重要边界：备份计划必须覆盖所有实例产生的归档日志，而不是只在某个节点检查“本地归档目录”。

3. RAC 能处理什么故障

RAC 主要改善以下故障路径：

  • 一个实例崩溃，但其他实例仍运行；
  • 一个节点不可用，但服务可以在其他节点上重新提供；
  • 通过服务、连接池和客户端故障转移，把新连接导向可用实例。

但 RAC 仍依赖共享资源：

  • 共享存储整体故障可能影响所有实例；
  • 集群互联故障可能导致节点驱逐；
  • 数据库级逻辑错误会被所有实例看到；
  • 误删除或错误更新不会因为有多个实例而自动回滚；
  • 整个机房断电或网络隔离时，RAC 无法提供异地数据库。

RAC 的“高可用”是实例、节点和服务层面的能力，不等价于备份，也不等价于灾难恢复。

七、RAC 与 Data Guard 的组合边界

常见架构是：

站点 A：RAC Primary
  Instance 1
  Instance 2
        │ redo transport
        ▼
站点 B：RAC Standby
  Instance 3
  Instance 4

这个组合分别处理不同故障：

故障 RAC 主要作用 Data Guard 主要作用 RMAN 主要作用
单实例崩溃 其他实例继续提供服务 通常不需要介入 通常不需要介入
单节点故障 服务迁移或重连 通常不需要介入 不负责
主站点存储损坏 可能整体受影响 备用站点可接替 可从备份重建
主库逻辑误操作 无法自动隔离 可能复制错误 可做时间点恢复
控制文件丢失 RAC 其他实例不等于备份 备用库可能提供另一份结构 从控制文件备份恢复
归档日志缺失 不能自动补齐历史日志 备用库可能仍有副本 从备份或备用库补齐
数据文件物理损坏 其他实例可能继续运行，但故障文件仍是数据库共享资源 备用库可提供替代路径 Restore + Recover
整站点灾难 无法解决 主要解决 提供重建和回退能力

1. RAC Primary 到 RAC Standby 的 redo thread

在 RAC 主库上，每个实例可能生成不同 thread 的 redo。备用库必须能够接收并应用这些 thread 的日志。配置、日志组大小、SRL 数量和线程覆盖关系必须经过验证。

一个典型检查思路：

SELECT THREAD#, GROUP#, BYTES, STATUS
FROM V$LOG
ORDER BY THREAD#, GROUP#;

SELECT THREAD#, GROUP#, BYTES, STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

这里不能只比较总组数。应按 thread 检查备用 redo log 是否足以承接主库的并发日志切换，并确认大小满足要求。具体数量规则受 Oracle 版本和部署配置影响，不能用一个脱离版本的固定数字代替验证。

2. RAC 中 RMAN 通道与备份归属

RMAN 可以使用多个通道并行备份。RAC 环境下通道可能在不同实例执行，前提是备份目标对相关实例可访问，或者已经正确配置本地与共享路径。

风险包括：

  • 归档日志只写在某个节点本地磁盘；
  • RMAN 通道运行在另一个节点，无法读取该日志；
  • 备份片写入本地路径，节点损坏后备份不可用；
  • 只备份了一个实例对应的 redo thread；
  • 服务或实例故障时，备份作业没有重试并留下缺口。

因此，RAC 备份验证必须从“所有 thread、所有数据文件、所有控制文件副本、所有备份片位置”出发，而不是只验证某个节点上的 RMAN 命令返回成功。

八、一个完整恢复算例：备份恢复、Data Guard 与 PITR 的区别

设有如下事件：

10:00  RMAN Level 0 完成，数据文件 checkpoint SCN = 100000
10:10  归档日志覆盖 SCN 100001–110000
10:20  归档日志覆盖 SCN 110001–120000
10:25  应用误执行 DELETE，相关 redo 覆盖 SCN 120001–120500
10:30  发现错误

方案 A：只依赖 Data Guard

如果备用库实时应用到 SCN 120500，那么误删除也很可能已经出现在备用库。将其切换为主库只能恢复“数据库服务”，不能恢复误删除前的数据。

方案 B：使用 RMAN 做时间点恢复

如果希望恢复到 10:24:59：

  1. 选择一个隔离环境，或停止原数据库写入；
  2. 还原 Level 0；
  3. 应用 10:10 和 10:20 的归档日志；
  4. 应用到 10:24:59 对应的目标时间或 SCN；
  5. 以 RESETLOGS 打开恢复出的数据库；
  6. 导出所需表或数据，经过验证后再合并回生产。

关键是不能误把“10:24:59”直接写成任意 SCN。应根据数据库日志、事务时间和 RMAN 可识别的恢复目标确定准确目标。恢复到错误时间点可能导致仍然包含误操作，或丢失更多合法事务。

方案 C：使用闪回能力

如果数据库配置了足够的闪回日志，并且目标时间仍在可用的闪回窗口内，可以考虑 Flashback Database 或表级闪回等机制。它们与 RMAN 备份不同：

  • 闪回依赖闪回日志和当前数据库环境；
  • 闪回窗口受存储空间和工作负载影响；
  • RMAN 历史备份适合更长期的保留；
  • 闪回并不能替代异地备份和恢复演练。

九、失败表现与诊断方法

1. RMAN 找不到归档日志

常见表现类似：

RMAN-06054: media recovery requesting unknown archived log

诊断顺序应是：

  1. 确认恢复目标；
  2. 找出缺失的 thread、sequence 或 SCN 范围；
  3. 检查 RMAN 目录记录：
LIST ARCHIVELOG ALL;
CROSSCHECK ARCHIVELOG ALL;
  1. 确认归档日志是否存在于备份介质；
  2. 检查是否有备用库副本；
  3. 如果确实缺失，重新定义可达到的恢复点，而不是盲目反复执行 RECOVER DATABASE。

在 RAC 中必须同时检查多个 thread。一个 thread 连续、另一个 thread 缺失，同样会阻断全局恢复。

2. Data Guard 显示传输正常但备用库不一致

需要分别检查：

  • 主库是否产生 redo；
  • 传输目的地是否有效；
  • 备用库是否接收 SRL；
  • apply 进程是否运行；
  • 是否存在 gap；
  • 是否存在数据文件离线、坏块或应用错误；
  • 保护模式和当前保护级别是否符合预期。

V$DATABASE 中的 PROTECTION_MODE 是配置模式，PROTECTION_LEVEL 更接近当前实际达到的保护级别。两者不应混为一谈。

3. RAC 节点存活但业务仍不可用

RAC 的实例存活不等于应用连接成功。还需要检查：

  • 数据库服务是否运行在预期实例；
  • 客户端是否配置了故障转移；
  • 连接池是否缓存了失效连接；
  • 业务是否依赖某个特定实例；
  • 节点间互联是否正常；
  • 全局缓存等待和共享存储是否成为瓶颈。

如果应用只连接固定节点，RAC 可能已经具备故障能力，但应用连接配置没有使用它。

十、恢复演练应验证“故障路径”，而不只是验证命令

一套有意义的恢复演练至少应覆盖以下路径中的实际目标：

1. RMAN 全库恢复

在隔离主机或隔离数据库环境：

CATALOG START WITH '/backup/findb/' NOPROMPT;
RESTORE DATABASE VALIDATE;
RESTORE DATABASE;
RECOVER DATABASE;

然后验证：

  • 数据库能否启动；
  • 控制文件是否匹配；
  • 归档日志是否完整；
  • 关键表的行数、约束和业务校验是否正确；
  • 应用是否能建立连接。

CATALOG START WITH 会把指定路径下的备份文件加入 RMAN 元数据。使用前应确认目录中确实只包含该数据库的备份，避免误登记其他数据库的备份文件。

2. Data Guard 计划切换

切换前应确认：

  • 主备状态正常；
  • 传输和应用延迟在目标范围；
  • 应用连接可以重新指向新主库；
  • 旧主库能否重新作为备用库加入；
  • 角色切换后备份、监控和归档策略仍然生效。

3. RAC 实例和节点故障

演练不应只杀掉一个进程后观察“数据库还在线”，还应验证：

  • 服务是否迁移；
  • 新连接是否进入其他实例；
  • 已有连接如何处理；
  • 事务重试是否符合应用语义；
  • 连接池是否会快速淘汰失效连接。

4. 误操作恢复

必须单独演练：

  • 误删除表；
  • 错误批量更新；
  • 恢复到时间点；
  • 从恢复副本提取正确数据；
  • 不覆盖现有生产数据地完成校验。

这是 Data Guard 最容易被高估而 RMAN 最容易被低估的场景。

十一、常见误解与正确边界

误解一：有 RAC 就不需要备份

错误。RAC 共享数据库文件和存储，不能提供历史版本，也不能从逻辑错误中恢复。

误解二：有 Data Guard 就不需要 RMAN

错误。Data Guard 主要提供另一套可接管的数据库；RMAN 提供长期备份、文件恢复和时间点恢复。备用库也常常依赖 RMAN 完成重建、补档和恢复。

误解三：备用库实时应用，所以能撤销主库误操作

错误。redo 复制的是数据库变化，错误变化同样会被复制。需要闪回窗口、延迟应用策略或 RMAN 时间点恢复等额外机制。

误解四：RMAN 备份成功，就一定能恢复

错误。备份任务成功只说明当次操作完成。还必须确认：

  • 备份片可读；
  • 控制文件和 SPFILE 可用；
  • 归档日志链完整；
  • 多个 RAC thread 均覆盖；
  • 备份介质在目标故障后仍可访问；
  • 恢复主机、密码文件、网络和存储条件已经准备好；
  • 恢复演练曾经成功。

误解五：同步 Data Guard 等于绝对零 RPO

错误。同步确认减少的是已提交 redo 未到达备用库的窗口，但保护效果取决于传输配置、保护模式、故障类型、备用库状态和切换流程。应用层已经返回成功、备用库已经接收、备用库已经应用，是不同概念。

误解六：RAC 与 Data Guard 是二选一

通常不是。RAC 适合处理主站点内的实例和节点故障，Data Guard 适合处理站点级故障；二者叠加后仍需要 RMAN 作为备份和恢复基础。

十二、如何按故障类型选择机制

可以用下面的判断顺序：

故障是否只是一个实例或节点？
  是：优先检查 RAC 服务、连接转移和事务重试。

故障是否涉及整套主数据库或主站点？
  是：检查 Data Guard 备用库状态，评估切换或故障切换。

是否发生误操作、逻辑损坏或需要回到历史时间点？
  是：使用 RMAN、Flashback 或恢复副本，不能只做 Data Guard 切换。

数据文件、控制文件或归档日志是否丢失？
  是：执行 RMAN restore + recover，并检查完整 redo 链。

主备库是否已经失去共同时间线？
  是：先阻断双写，评估闪回重建、重新实例化或完整恢复。

最终架构的核心不是“部署了多少 Oracle 特性”，而是让每类故障都有与之匹配的机制：

实例可用性：RAC
数据库和站点接管：Data Guard
历史数据、文件和时间点恢复：RMAN
逻辑错误的回退：RMAN / Flashback / 恢复副本

当这三个产品边界被准确区分，并且恢复目标、redo 链、RAC thread、备用库状态和实际演练结果能够互相印证时，Oracle 的备份恢复与高可用体系才真正成立。

系列导航与关联阅读

官方资料

本文依据数据库官方文档重新梳理；正文、示例与生产检查清单由 WR BLOG 编写。