数据库原理与安全笔记：数据库恢复

该部分为本科期间数据库原理与安全笔记备份。

Failure Classification

Transaction failure(事务故障）

System crash（系统崩溃）

Disk failure（磁盘故障）

Transaction failure :

1. Logical errors: transaction cannot complete due to some internal error condition (e.g., invalid input)
2. System errors: the database system must terminate an active transaction due to an error condition (e.g., deadlock)

Logical errors:有些是可以预期的,绝大多是非预期的。

System errors：并发事务发生死锁而被选中撤销该事务

故障如何恢复：undo操作

System crash

a power failure or other hardware or software failure causes the system to crash.

是指造成系统停止运转的任何事件，使得系统要重新启动，称为软故障。

特点：

• 整个系统的正常运行突然被破坏
• 所有正在运行的事务都非正常终止
• 不破坏数据库
• 内存中数据库缓冲区的信息全部丢失

Fail-stop assumption: non-volatile storage contents are assumed to not be corrupted by system crash

解决：

1. Database systems have numerous integrity checks to prevent corruption of disk data
2. 非正常终止的事务: 系统重新启动后需undo
3. 正常终止的事务(持久性): 系统重新启动后需redo

Disk failure

最严重的。但是发生的几率很小。

a head crash or similar disk failure destroys all or part of disk storage

解决：

1. Destruction is assumed to be detectable. disk drives use checksums to detect failures.
2. 装入数据库发生介质故障前某个时刻的数据副本,重做自此时始的所有成功事务,，将这些事务已提交的结果重新记入数据库。

Recovery Algorithms

Recovery algorithms are techniques to ensure database consistency and transaction atomicity and durability despite failures

two parts:

• Actions taken during normal transaction processing to ensure enough information exists to recover from failures
• Actions taken after a failure to recover the database contents to a state that ensures atomicity, consistency and durability

恢复操作的基本原理：冗余。利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据。

如何建立冗余数据:数据转储（backup）、登录日志文件（logging）

Data Access

Physical blocks: blocks residing on the disk

Buffer blocks: blocks residing temporarily in main memory

Block movements following two operations:

• input(B)： physical block B -> main memory
• output(B): buffer block B -> disk, replaces the appropriate physical block there

Each transaction \(T_i\) has its private work-area in which local copies of all data items accessed and updated by it are kept. data items在系统buffer之间传输。

its private work-area using the following operations:

• read(X): assign value of data item X -> local variable \(x_i\)
• write(X): assign value of local variable \(x_i\) -> item {x} buffer block
• if the block \(B_X\) in which X resides is not already in memory,excute input(\(B_X\))

Transactions:

• Perform read(X) while accessing X for the first time
• All subsequent accesses are to the local copy
• After last access, transaction executes write(X)

output(\(B_X\)) need not immediately follow write(X). System can perform the output operation when it deems fit.

Recovery method

dump转储

log-based recovery(日志）

数据转储

什么是转储

转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程。

这些备用的数据文本称为后备副本或后援副本

转储方法

1. 静态转储与动态转储
2. 海量转储与增量转储

静态转储

在系统中无运行事务时进行转储，转储开始时数据库处于一致性状态，转储期间不允许对数据库的任何存取、修改活动。

优点：实现简单

缺点：降低了数据库的可用性(转储必须等用户事务结束，新的事务必须等转储结束)

动态转储

转储操作与用户事务并发进行，转储期间允许对数据库进行存取或修改。

优点：

• 不用等待正在运行的用户事务结束
• 不会影响新事务的运行

缺点：不能保证副本中的数据正确有效

利用动态转储得到的副本进行故障恢复：

• 需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件
• 后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态

海量转储与增量转储

海量转储: 每次转储全部数据库

增量转储: 只转储上次转储后更新过的数据

比较:

1. 从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
2. 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

Log-Based Recovery

日志文件(log)是用来记录事务对数据库的更新操作的文件

A log is kept on stable storage

日志内容

1. 各个事务的开始标记(BEGIN TRANSACTION)
2. 各个事务的结束标记(COMMIT或ROLLBACK)
3. 各个事务的所有更新操作
4. 以上均作为日志文件中的一个日志记录(log record)

每条日志记录内容：事务标识、操作类型（write）、操作对象（记录ID、Block NO.）、更新前数据的旧值（对插入操作而言，此项为空值）、更新后数据的新值（对删除操作而言, 此项为空值）

日志用途

进行事务故障恢复

进行系统故障恢复

协助后备副本进行介质故障恢复

登记日志文件的原则

遵循两条原则：

1. 登记的次序严格按并行事务执行的时间次序
2. 必须先写日志文件，后写数据库
   • 写日志文件操作：把表示这个修改的日志记录写到日志文件
   • 写数据库操作：把对数据的修改写到数据库中

FAQ:为什么必须先写日志文件，后写数据库

写数据库和写日志文件是两个不同的操作，在这两个操作之间可能发生故障。

如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了

如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性。

恢复策略

事务故障

事务在运行至正常终止点前被中止(这里面仅涉及到一个事务)

恢复方法:由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。

事务故障的恢复由系统自动完成，不需要用户干预

事务故障的恢复步骤:

1. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”（Befor Image, BI）写入数据库。
   • 插入操作，“更新前的值”为空，则相当于做删除操作
   • 删除操作，“更新后的值”为空，则相当于做插入操作
   • 若是修改操作，则用BI 代替 AI（After Image）
3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

系统故障

系统故障造成数据库不一致状态的原因:

• 一些未完成事务对数据库的更新已写入数据库
• 一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库

恢复方法:

1. Undo 故障发生时未完成的事务
2. Redo 已完成的事务

系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

系统故障的恢复步骤:

1. 正向扫描日志文件（即从头扫描日志文件）
   • Redo队列: 在故障发生前已经提交的事务
   • Undo队列:故障发生时尚未完成的事务
2. 对Undo队列事务进行UNDO处理:反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作
3. 对Redo队列事务进行REDO处理正向扫描日志文件，对每个REDO事务重新执行登记的操作

介质故障的恢复

需要DBA介入, 实际恢复由系统完成, 具体步骤:

• 装入后援副本
• 装入相应的日志文件副本
• 启动恢复程序按日志恢复

恢复步骤:

1. 装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。
   • 对于静态转储的数据库副本，装入后数据库即处于一致性状态
   • 对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障相同的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。
2. 装入有关的日志文件副本（转储结束时刻的日志副本），重做已完成的事务。
   • 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
   • 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。

注意：

日志文件也要转储

日志和数据库不再同一磁盘

介质故障的恢复需要DBA介入:重装最近转储的数据库副本和有关的各日志文件副本、执行系统提供的恢复命令，恢复操作仍由DBMS完成。

具有检查点的恢复技术

两个问题:

1. 搜索整个日志将耗费大量的时间
2. REDO处理：重新执行，浪费了大量时间

check points:是使物理数据文件与数据库高速缓存当前状态同步的一种操作

功能：

• Output all log records currently residing in main memory onto stable storage.
• Output all modified buffer blocks to the disk.
• Write a log record < checkpoint> onto stable storage.

解决方案

在日志文件中增加检查点记录（checkpoint）

增加重新开始文件

恢复子系统在登录日志文件期间动态地维护日志

在检查点执行的过程中，不允许事物执行任何的操作，如写缓冲区或写日志记录

检查点记录的内容：

1. 建立检查点时刻所有正在执行的事务清单
2. 这些事务最近一个日志记录的地址

重新开始文件的内容：记录各个检查点记录在日志文件中的地址

在检查点维护日志文件

1. 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上。
2. 在日志文件中写入一个检查点记录。
3. 将当前数据缓冲区的所有数据记录写入磁盘的数据库中。
4. 把检查点记录在日志文件中的地址写入一个重新开始文件。

建立检查点：定期、不定期

利用检查点的恢复策略

当事务T在一个检查点之前提交，T对数据库所做的修改已写入数据库，在进行恢复处理时，没有必要对事务T执行REDO操作。

利用检查点的恢复步骤：

1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
2. 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
   • 建立两个事务队列:UNDO-LIST、REDO-LIST
   • 把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
3. 从检查点开始正向扫描日志文件，直到日志文件结束
   • 如有新开始的事务\(T_i\)，把Ti暂时放入UNDO-LIST队列
   • 如有提交的事务\(T_j\)，把Tj从UNDO-LIST队列移到REDO-LIST队列
4. 对UNDO-LIST中的每个事务执行UNDO操作, 对REDO-LIST中的每个事务执行REDO操作