📚 课程目录第2章恢复模式深度解析

2. 恢复模式深度解析

恢复模式（Recovery Model）是 SQL Server 数据库的一个核心属性，它并不直接决定“能不能恢复”，而是决定事务日志如何被记录、何时可以被截断、以及允许执行哪些类型的备份与恢复。很多生产事故的根源，不是备份命令写错，而是恢复模式选错：日志文件无限增长、日志备份链断裂、误删数据后无法做时间点恢复。理解三种恢复模式的差异，是设计备份与灾备体系的第一步。

三种恢复模式的日志行为差异

SQL Server 提供三种恢复模式：SIMPLE（简单）、FULL（完整）、BULK_LOGGED（大容量日志）。它们的核心区别在于事务日志的记录粒度和日志截断时机。

SIMPLE 模式下，事务日志只用于保证事务的原子性和一致性。每当检查点（CHECKPOINT）发生，且日志记录不再需要用于回滚未提交事务时，日志空间就会被自动截断并重用。这意味着日志文件不会无限增长，但代价是无法进行日志备份，因此只能恢复到最近一次完整备份或差异备份的时间点，无法做时间点恢复（Point-in-Time Recovery）。

FULL 模式下，所有事务操作都被完整记录到日志中，包括数据修改、索引变更、大容量操作等。日志只有在执行日志备份后才会被截断。因此 FULL 模式支持完整备份、差异备份和日志备份，可以实现精确到秒的时间点恢复。但前提是日志备份链必须连续——一旦日志备份中断，后续日志备份将无法建立，恢复能力会退化为最近一次日志备份的时间点。

BULK_LOGGED 模式是 FULL 模式的一种补充。它同样要求日志备份链完整，但对于特定的大容量操作（如 BULK INSERT、SELECT INTO、CREATE INDEX、bcp 等），采用最小日志记录方式，只记录页面分配和元数据变更，而不是逐行记录。这大幅减少了日志写入量，提升了大批量操作的性能。但代价是：如果日志备份中包含这些最小日志记录的操作，则无法做时间点恢复，只能恢复到日志备份结束的时间点。

日志截断与日志链：恢复能力的生命线

理解恢复模式，必须理解日志截断（Log Truncation）和日志链（Log Chain）这两个概念。日志截断是指 SQL Server 将事务日志中不再需要的部分标记为可重用空间。在 SIMPLE 模式下，截断由检查点自动触发；在 FULL 和 BULK_LOGGED 模式下，只有日志备份完成后才会触发截断。

日志链是指从一次完整备份开始，经过一系列日志备份，直到当前时间点的连续记录序列。只要日志链完整，就可以将数据库恢复到链中任意一个日志备份覆盖的时间点。一旦日志链断裂——例如误将恢复模式从 FULL 改为 SIMPLE，或执行了无日志备份的完整备份——后续日志备份将无法与之前的链衔接，时间点恢复能力即告失效。

关键警示：将数据库从 FULL 模式切换为 SIMPLE 模式，会立即截断日志并破坏日志链。即使之后改回 FULL 模式，也必须重新执行一次完整备份才能重建日志链。生产环境中切换恢复模式前，务必确认已做好完整备份。

生产环境选型策略

恢复模式的选择不是“越高级越好”，而是由业务对数据丢失的容忍度（RPO）和恢复时间目标（RTO）共同决定。以下是常见的选型判断依据：

业务场景	推荐恢复模式	理由
开发/测试库、只读报表库	SIMPLE	无需时间点恢复，日志自动管理，运维成本低
核心 OLTP 交易系统	FULL	要求精确到秒的恢复能力，RPO 接近零
夜间批量导入/索引重建频繁的库	BULK_LOGGED（批量期间临时切换）	减少大容量操作日志量，提升性能；批量结束后切回 FULL
数据仓库 ETL 加载窗口	BULK_LOGGED	ETL 期间允许非精确时间点恢复，换取加载速度

对于核心 OLTP 系统，推荐采用 FULL 模式 + 定期完整备份 + 高频日志备份的组合。例如：每天 02:00 执行完整备份，每 15 分钟执行一次日志备份。这样 RPO 约为 15 分钟，RTO 取决于完整备份的恢复速度和日志重放速度。如果业务要求 RPO 小于 5 分钟，则需要缩短日志备份间隔，或引入 AlwaysOn 可用性组等更高可用性方案。

对于有大规模批量操作的数据库，可以在批量操作前将恢复模式切换为 BULK_LOGGED，批量完成后立即切回 FULL，并执行一次日志备份。这样既能享受最小日志记录带来的性能提升，又能在批量窗口之外保持精确时间点恢复能力。但需要注意：BULK_LOGGED 模式下，如果日志备份中包含最小日志记录的操作，则该日志备份只能恢复到结束时间点，无法恢复到中间某个时刻。

实操建议：查询当前数据库恢复模式可使用：
SELECT name, recovery_model_desc FROM sys.databases;
切换恢复模式：
ALTER DATABASE [YourDB] SET RECOVERY FULL;
切换后务必执行一次完整备份以重建日志链。

常见误区与排障要点

误区一：FULL 模式一定不会丢数据。FULL 模式只保证日志完整记录，但如果日志备份未执行或日志链断裂，仍然无法恢复到最新时间点。FULL 模式必须配合日志备份才有意义。

误区二：SIMPLE 模式日志不会增长。SIMPLE 模式下，如果存在长时间运行的事务或未提交事务，日志截断会被阻塞，日志文件仍可能增长。需要关注 log_reuse_wait_desc 列来判断日志无法重用的原因。

误区三：BULK_LOGGED 模式可以随意使用。BULK_LOGGED 模式仅在批量操作期间有优势，日常事务仍按完整日志记录。如果长期停留在 BULK_LOGGED 模式，一旦日志备份包含最小日志记录，时间点恢复能力就会受限。因此建议按需切换，而非长期使用。

排障时，可通过以下查询观察日志空间使用和截断等待原因：

SELECT 
    name,
    recovery_model_desc,
    log_reuse_wait_desc,
    size * 8 / 1024 AS size_mb
FROM sys.databases
WHERE name = 'YourDB';

其中 log_reuse_wait_desc 返回 LOG_BACKUP 表示日志正在等待日志备份才能截断；返回 ACTIVE_TRANSACTION 表示有长时间运行的事务阻塞了日志截断；返回 NOTHING 表示日志可以正常重用。根据返回值可以快速定位日志增长的根本原因。

总结来说，SIMPLE 适合不需要时间点恢复的场景，FULL 是核心生产库的默认选择，BULK_LOGGED 是批量操作期间的性能优化手段。选型的核心不是记住三种模式的定义，而是理解它们对日志截断、日志链和恢复粒度的实际影响，并结合业务的 RPO/RTO 要求做出权衡。