CS-Xmind-Note 数据库恢复技术全解：事务、ACID 与基于冗余的故障恢复机制-育师

文档
教程
知识库

【免费下载链接】CS-Xmind-Note

计算机专业课（408）思维导图和笔记：计算机组成原理（第五版王爱英），数据结构（王道），计算机网络（第七版谢希仁），操作系统（第四版汤小丹）

项目地址：https://gitcode.com/gh_mirrors/cs/CS-Xmind-Note

本篇技术指南以数据库恢复技术为核心骨架，系统梳理数据库恢复技术的完整知识体系：从事务的定义、COMMIT/ROLLBACK 两种结束方式，到 ACID 四特性、四类故障的成因与影响，再到"冗余"这一恢复基本原理与数据转储、日志文件两大实现技术。文中结合本仓库（408 专业课笔记，数据库部分对应《数据库系统概论》第五版王珊、萨师煊）中并发控制、完整性约束等关联章节，帮助你建立"事务 → 故障 → 恢复"的完整认知链条，可直接用于备考复习与数据库故障排查实战。

什么是事务

事务（Transaction）是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。这是数据库恢复技术乃至整个数据库理论中最重要的基础概念之一，本仓库将其列为"恢复和并发控制的基本单位"。

事务与程序是两个概念

在关系数据库中，一个事务可以是一条 SQL 语句、一组 SQL 语句，或整个程序；
一个应用程序通常包含多个事务；
事务是恢复和并发控制的基本单位。

也就是说，"程序"是静态的代码集合，"事务"是动态执行时被系统视为一个逻辑单元的若干操作。同一程序在多次运行中可能产生多个事务；一次转账操作（A 账户扣款 + B 账户入账）如果跨多条 SQL 语句，通常会被设计成一个事务，保证中间任意一步失败时整体回滚。

事务结束：COMMIT 与 ROLLBACK

事务的结束只有两种途径：

COMMIT（提交，事务正常结束）

提交事务的所有操作（读 + 更新）；
事务中所有对数据库的更新永久生效；
只有执行 COMMIT 后，事务的结果才对外可见且不可撤销（对应下文 ACID 中的"持续性"）。

ROLLBACK（回滚，事务异常终止）

事务运行过程中发生了故障，不能继续执行；
回滚事务的所有更新操作；
事务滚回到开始时的状态。

COMMIT 与 ROLLBACK 在 SQL 中的典型用法（以标准 SQL / SQL Server 语法为例）：

BEGIN TRANSACTION; UPDATE 账户 SET 余额 = 余额 - 100 WHERE 账号 = 'A'; UPDATE 账户 SET 余额 = 余额 + 100 WHERE 账号 = 'B'; -- 两条语句都成功 COMMIT; -- 任一步失败则 ROLLBACK;

事务的特性（ACID 特性）

原子性（Atomicity）

事务是数据库的逻辑工作单位；
事务中包括的诸操作要么都做，要么都不做。

原子性保证一个事务不可能执行到一半就结束，要么全部生效，要么像从未发生过一样。原子性由 DBMS 的恢复机制（日志 + 回滚）来保障。

一致性（Consistency）

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态；
一致性状态：数据库中只包含成功事务提交的结果；
不一致状态：数据库中包含失败事务的结果。

一致性与完整性约束（参见仓库完整性约束）密切相关：事务执行前后，数据库都必须满足所有完整性约束（实体完整性、参照完整性、用户定义完整性）。

隔离性（Isolation）

对并发执行而言，一个事务的执行不能被其他事务干扰；
一个事务内部的操作及使用的数据对其他并发事务是隔离的；
并发执行的各个事务之间不能互相干扰。

隔离性是并发控制要解决的问题，仓库并发控制一章专门讨论了多事务并发执行带来的丢失修改、不可重复读、读"脏"数据三类不一致问题及其封锁机制（X 锁、S 锁、三级封锁协议），正是隔离性的具体保障手段。

持续性（Durability）

持续性也称永久性（Permanence）；
一个事务一旦提交，它对数据库中数据的改变就应该是永久性的；
接下来的其他操作或故障不应该对其执行结果有任何影响。

持续性意味着即使系统随后崩溃，已提交事务的结果也必须能够恢复出来，这正是日志文件（REDO）要解决的问题。

故障

故障原因

计算机硬件故障；
系统软件和应用软件的错误；
操作员的失误；
恶意的破坏。

故障的影响

运行事务非正常中断；
破坏数据库。

故障直接影响事务的正常执行，并可能造成数据库中数据的错误或丢失。数据库恢复技术存在的意义，就是把这些故障造成的影响降到最低。

故障的种类

按破坏范围和恢复方式，故障通常分为四类：

故障种类	特点	典型场景
事务故障	单个事务非正常中断，只影响该事务	运算溢出、死锁被选中撤销、违反完整性约束被中止
系统故障	整个系统突然停止运行，内存中数据丢失，但外存数据未遭物理破坏	断电、操作系统崩溃、DBMS 代码缺陷导致停机
介质故障	外存（磁盘）上的数据库部分或全部被破坏	磁盘损坏、磁头碰撞、强磁场干扰
计算机病毒	恶意程序篡改或删除数据	病毒破坏数据文件

从仓库数据库绪论的表述可知：硬件故障、软件故障、操作员失误以及故意破坏都会影响数据库中数据的正确性，甚至造成数据库部分或全部数据的丢失，因此DBMS 必须具有将数据库从错误状态恢复到某一已知的正确状态（亦称为完整状态或一致状态）的功能。

恢复操作的基本原理：冗余

恢复操作的基本原理是冗余。

具体而言：利用存储在系统其它地方的冗余数据，来重建数据库中已被破坏或不正确的那部分数据。数据库中任何一个部分被破坏或不正确后，都可以利用存储在别处的冗余副本来重建。冗余是恢复技术能够成立的前提——没有冗余，损坏的数据就无从还原。

恢复的实现技术

恢复的实现依靠两大核心技术：数据转储（backup）和登录日志文件（logging）。

数据转储（backup）

数据转储是数据库恢复中采用的基本技术，指DBA 定期地将整个数据库复制到磁带或其他存储介质上保存起来的过程。这些保存下来的数据副本称为后备副本（backup copy）。

当数据库遭到破坏后，可将后备副本重新装入，将数据库恢复到转储时的状态。但注意：只靠后备副本只能恢复到转储时刻的状态，转储之后到故障发生之间对数据库的更新会丢失。因此转储通常要配合日志文件一起使用，才能恢复到故障发生前的最新一致状态。

转储按时机与方式可组合出四种策略：

静态转储：系统中无运行事务时进行的转储操作，转储期间不允许对数据库进行任何存取、修改活动，得到的一定是一个一致副本，但降低了可用性；
动态转储：转储期间允许对数据库存取或修改，后备副本可能不是一致副本，需配合日志记录重做（REDO）才能得到一致副本；
海量转储：每次转储全部数据库；
增量转储：只转储上次转储后更新过的数据。

实际使用中通常组合运用，例如"定期海量静态转储 + 频繁增量动态转储"，在恢复代价与数据丢失风险之间取得平衡。

登录日志文件（logging）

日志文件是用来记录事务对数据库的更新操作的文件，是恢复时确定哪些事务需要撤销（UNDO）、哪些事务需要重做（REDO）的依据。为保证可恢复性，日志记录必须遵守两条原则：

登记的次序严格按并发事务执行的时间次序；
必须先写日志文件，后写数据库（即先写日志原则），否则如果先写了数据库而后在写日志时发生故障，就无法利用日志来恢复，导致恢复错误。

日志文件中每条日志记录通常包含：事务标识（标明是哪个事务）、操作的类型（插入/删除/修改）、操作对象、更新前数据的旧值（用于 UNDO）、更新后数据的新值（用于 REDO）。

结合日志与后备副本，各类故障的恢复策略可概括为：

故障类型	恢复策略
事务故障	反向扫描日志，对未完成事务执行UNDO（撤销），回滚到事务开始状态
系统故障	对未提交事务UNDO，对已提交但未写入数据库的事务REDO（重做），使数据库恢复到一致状态
介质故障	装入最近的后备副本，再利用日志REDO所有已提交事务，恢复到故障前最新状态

小结

数据库恢复技术围绕一条主线展开：事务是恢复的基本单位（数据库恢复技术），事务以 COMMIT / ROLLBACK 结束并具有 ACID 特性；运行过程中可能遭遇事务故障、系统故障、介质故障与计算机病毒；恢复的本质是利用冗余数据重建被破坏的数据，具体通过数据转储（提供后备副本）与登录日志文件（提供 UNDO / REDO 依据）两大技术实现。恢复技术与并发控制共同构成了 DBMS 保证数据库正确性的两大支柱，也是数据库系统概论课程与 408 联考的高频考点。