DBPA · 11.1

事务、故障与恢复策略

让数据库从错误状态回到一致状态

VER. 2608.2 Built with impress.js

学习目标

事务边界、ACID 和故障范围共同决定恢复方向

01说明事务边界和提交回滚语义
02解释 ACID 四个特性
03区分三类故障的影响范围
04说明恢复为什么依赖冗余数据
05根据故障影响范围、事务状态和介质可信性选择 UNDO、REDO 或副本恢复
06区分恢复和并发控制的职责

2/11

LEARNING OBJECTIVES

事务把相关操作绑定为不可分割的单位

一个程序可以包含多个事务；一个事务要么全部提交，要么全部撤销

BEGIN TRANSACTION→数据库操作序列→COMMIT 或 ROLLBACK

Takeaway

不等于。COMMIT 接受事务结果并承诺持久保存，日志、缓冲和存储实现共同兑现这一承诺

3/11

TRANSACTION

ACID 把可靠事务拆成四个相互支撑的目标

转账案例能同时展示原子性和一致性

原子性

全做或全不做，防止半套更新

一致性

遵守约束并从一致状态到一致状态

隔离性

并发控制可见性和交错影响

持续性

提交结果在故障后仍应保留

Takeaway

恢复直接支撑原子性、一致性和持续性；隔离性主要由并发控制保证

4/11

ACID

转账不能提交“只扣款未入账”

事务边界把两个更新绑定在一起，未提交暂态不应对外可见

时刻	余额示意	事务语义	对外状态
开始	A=100，B=50	事务已开始	一致状态
中间	A=90，B=50	未提交事务内部暂态	对外不可见
提交	A=90，B=60	结果被接受并承诺持久	新的一致状态
故障	可能停在中间	未完成事务	按故障状态恢复

Takeaway

不能。未提交的半套更新必须撤销，转账事务只能整体提交或整体回滚

5/11

TRANSFER EXAMPLE

恢复：回到已知可信的一致状态

恢复子系统利用系统中保存的冗余信息

故障状态→后备副本、日志或镜像→已知可信的一致状态

Takeaway

恢复目标不一定是故障发生前的最新时刻，而是可以验证的一致状态；日志、检查点和镜像把恢复方向落实为具体实现

Takeaway

恢复的基本原理是用别处保存的数据重建被破坏或不正确的部分

6/11

RECOVERY GOAL

按范围、事务状态和介质可信性分类故障

故障范围不同，恢复动作也不同

故障	影响	典型来源
事务故障（事务内部故障）	一个事务未正常结束	溢出、死锁、约束违约
系统故障	主存、缓冲区和运行事务丢失，磁盘通常仍可信	断电、操作系统或 DBMS 崩溃
介质故障	磁盘或日志被破坏，原介质不再可信	磁盘损坏、恶意加密

7/11

FAILURE TYPES

故障范围决定 UNDO、REDO 或副本恢复

恢复方向来自事务是否完成、更新是否写入，以及哪一份介质仍然可信

情况	动作	目标
事务未完成且更新已写入	UNDO	撤销未完成更新
系统故障后未完成／已提交事务	未完成 UNDO；已提交 REDO	处理缓冲区丢失造成的两类缺口
介质数据损坏	重装可信副本并结合相关日志按状态 UNDO／REDO	从可信状态重建

Takeaway

未完成事务可能已有写入，需要 UNDO；已提交事务的数据页可能尚未落盘，需要 REDO。介质恢复还要根据副本状态结合日志判断恢复动作

8/11

RECOVERY ACTIONS

用事务状态和故障范围选择恢复动作

事务定义一致性边界，恢复把故障后的数据库带回一致状态

事务

用边界、提交与回滚定义逻辑工作单位

目标

ACID 职责边界：恢复支撑原子性、一致性和持续性，并发控制支撑隔离性

恢复

按故障范围选择 UNDO、REDO 或副本恢复

Takeaway

日志、检查点和镜像把冗余数据落实为可执行的恢复证据

9/11

RECAP

本节知识地图

10/11

KNOWLEDGE MAP

本节问题

01转账中 A 已扣款、B 未入账时，为什么这是未提交事务内部暂态？
02ACID 四个特性分别防范什么风险？恢复和并发控制各负责什么？
03事务 T1 未完成、T2 已提交时发生系统故障，分别选择什么恢复方向？
04为什么系统故障通常保留可信磁盘，而介质故障需要可信副本？
05为什么动态转储的介质恢复不能简单记成“只 REDO”？
06为什么恢复技术依赖冗余数据？日志、检查点和镜像如何把冗余数据用于恢复？

11/11

CHECK YOUR UNDERSTANDING