Appearance

Oracle 备份与高可用 ​

Oracle 生产环境高可用和恢复能力非常成熟，常见关键词是 RMAN、归档日志、Data Guard、RAC。

RMAN ​

RMAN 是 Oracle 官方备份恢复工具。

text
rman target /
backup database plus archivelog;

RMAN 能做：

  1. 全库备份。
  2. 增量备份。
  3. 归档日志备份。
  4. 块级恢复。
  5. 校验备份可用性。

归档日志 ​

归档日志保存 redo log 切换后的历史日志，用于介质恢复和时间点恢复。

mermaid
flowchart TD
    A["Redo Log"] --> B["日志切换"]
    B --> C["Archived Log"]
    C --> D["恢复到指定时间点"]

如果不开归档模式，恢复能力会弱很多。

Data Guard ​

Data Guard 用于主备复制和容灾。

mermaid
sequenceDiagram
    participant P as Primary
    participant R as Redo
    participant S as Standby
    P->>R: 生成 redo
    R->>S: 传输 redo
    S->>S: 应用 redo

Standby 可以用于容灾切换，某些模式下也可做只读查询。

RAC ​

RAC 是 Real Application Clusters，多实例访问同一个数据库存储，用于提升可用性和横向能力。但 RAC 复杂度高，对存储、网络和应用设计都有要求。

零基础先理解：备份不是复制一份文件 ​

Oracle 是持续写入的数据库。业务提交时会修改数据块、产生 redo、推进 SCN。如果你直接在操作系统层复制数据文件，复制过程中不同文件可能处于不同时间点，恢复时就可能不一致。

Oracle 备份恢复真正要解决的是：

  1. 数据文件丢了能恢复。
  2. 磁盘坏了能恢复。
  3. 人误删数据能恢复到删除前。
  4. 主库机房故障能切到备库。
  5. 恢复后数据处在一致的 SCN。

所以要理解数据文件、控制文件、redo、归档日志、RMAN 和 SCN 的关系。

恢复为什么离不开 Redo 和归档日志 ​

完整备份只是某个时间点附近的数据文件副本。备份完成后业务还在继续写，如果只恢复完整备份，会丢失备份后的提交。

mermaid
flowchart TD
    A["周日 00:00 全备"] --> B["周一到周三业务持续提交"]
    B --> C["Redo不断生成"]
    C --> D["日志切换生成归档日志"]
    D --> E["周三 10:00 数据文件损坏"]
    E --> F["还原周日全备"]
    F --> G["应用归档日志和在线Redo"]
    G --> H["恢复到故障前或指定时间点"]

如果没有归档日志，数据库通常只能恢复到最后一次一致备份点，备份之后的数据可能丢失。

归档模式怎么理解 ​

模式含义适用
NOARCHIVELOGredo 覆盖前不强制保存历史日志测试库、可丢数据环境
ARCHIVELOGredo 切换后保存成归档日志生产核心库

核心业务库通常必须使用归档模式，因为它支持介质恢复和时间点恢复。

查看：

sql
archive log list;

RMAN 备份类型 ​

备份类型作用什么时候用
全库备份备份所有关键数据文件周期性基线
增量备份只备份变化块大库降低备份窗口
归档日志备份保存恢复所需日志支持时间点恢复
控制文件备份保存数据库结构元信息控制文件损坏恢复
SPFILE 备份保存启动参数参数文件丢失恢复

典型命令：

text
rman target /
backup database plus archivelog;
backup current controlfile;

时间点恢复流程 ​

误删数据是商业系统高频事故。比如凌晨 10:05 误删资产表部分数据，想恢复到 10:04。

mermaid
flowchart TD
    A["确认误操作时间"] --> B["准备最近可用全备或增量备份"]
    B --> C["还原数据文件"]
    C --> D["应用归档日志"]
    D --> E["recover database until time"]
    E --> F["打开数据库或恢复到临时库导出数据"]

生产上更常见的安全做法是恢复到临时库，把误删数据导出后再回灌，而不是直接把主库整体回退。因为整体回退会影响误操作之后的正常业务数据。

Data Guard 原理 ​

Data Guard 的核心不是“定时复制表”，而是主库把 redo 传到备库，备库应用 redo，使备库不断追赶主库。

mermaid
sequenceDiagram
    participant App as 应用
    participant Pri as 主库
    participant Redo as Redo传输
    participant Stb as 备库
    App->>Pri: 提交事务
    Pri->>Pri: 写Redo并提交
    Pri->>Redo: 发送Redo
    Redo->>Stb: 传输Redo
    Stb->>Stb: 应用Redo恢复数据块

关键概念：

概念说明
主库 Primary承接业务写入
备库 Standby接收并应用 redo
同步/异步决定数据丢失风险和提交延迟
Apply Lag备库应用落后时间
Switchover计划内主备切换
Failover主库故障后的故障切换

Data Guard 能解决机房级故障和数据库级容灾，但不能替代备份。因为误删数据也会生成 redo 并同步到备库。

RAC 解决什么，不解决什么 ​

RAC 是多实例访问同一个数据库存储。它主要提升实例层高可用和一定的并发能力。

能力RAC 是否解决说明
单实例宕机能缓解其他实例可继续服务
存储损坏不能单独解决共享存储仍是关键
误删数据不能解决误操作对所有实例可见
SQL 写得慢不能自动解决可能因为跨实例块传输更复杂
横向扩展所有业务不一定热点块、序列、全局缓存会限制扩展

所以 RAC、Data Guard、RMAN 的角色不同：RAC 偏实例可用性，Data Guard 偏容灾，RMAN 偏备份恢复。

商业备份策略示例 ​

核心资产库可以这样设计：

项目策略
恢复目标 RPO核心交易 0 到数分钟，普通报表可更长
恢复时间 RTO核心系统分钟级到小时级
全备每周一次
增量备份每天一次
归档日志备份每 15 到 30 分钟
备份保存本地快速恢复 + 异地对象存储
恢复演练每月至少抽样恢复
监控归档空间、备份成功率、备库延迟

备份策略必须由 RPO/RTO 倒推，而不是“每天备份一下就行”。

常见坑 ​

坑后果正确做法
只备份不演练恢复真故障时发现备份不可用定期恢复演练
归档目录满数据库可能挂起或无法继续归档监控空间并备份清理
Data Guard 当备份误删会同步到备库RMAN 备份和容灾都要有
不备控制文件恢复时缺少数据库结构信息开启控制文件自动备份
直接主库回退丢失误操作后的正常业务优先恢复到临时库再回灌

面试标准回答 ​

text
Oracle 备份恢复常用 RMAN，可以做全库备份、增量备份、归档日志备份和恢复。归档日志用于保存 redo 历史，是时间点恢复和介质恢复的重要基础。Data Guard 通过传输和应用 redo 实现主备容灾，RAC 是多个实例访问同一个数据库存储，提高可用性但复杂度更高。生产环境必须定期做恢复演练，而不是只配置备份任务。