数据库系统概念：CH16 恢复系统 Recovery System

CH16 Recovery System

文章目录

CH16 Recovery System
- 16.1 Failure Classification
- - 1.Classification
  - 2.Recovery Algorithm
- 16.2 Storage Structure
- - 16.2.1 Stable-Storage Implementation
  - 16.2.2 Data Access
- 16.3 Recovery and Atomicity
- - 16.3.1 Log-Based Recovery
  - - 1.日志概念和日志中的项
  - 16.3.2 Modification of DataBase
  - 16.3.3 Concurrency Control and Recovery
  - 16.3.4 Transaction commit
  - 16.3.5 Undo and Redo Operations
  - - 1.对于数据项的undo和redo
    - 2.对于事务的undo和redo
  - 16.3.6 Checkpoints
  - - 1.增加checkpoints的原因
    - 2.检查点的执行
- 16.4 Recovery Algorithm
- - 16.4.1 Logging
  - 16.4.2 rollback
  - 16.4.3 Recovery from failure：Two phase
  - - 1.Redo Phase
    - 2.undo Phase
- 16.5 Buffering Managment
- - 16.5.1 Log Record Buffering
  - - 1.概念
    - 2.Write-Ahead Logging WAL规则
  - 16.5.2 Database Buffering
  - - 1.缓存策略
    - 2.保证
    - 3.输出的过程
    - 4.数据库缓存的实现

16.1 Failure Classification

1.Classification

系统故障的分类：
{transaction failure{logicalerrorsystemerrorsystemcrash{硬件故障软件漏洞diskfailure\begin{cases}\text{transaction failure}\begin{cases}logical\ error\\system\ error\end{cases}\\system \ crash\begin{cases}硬件故障\\软件漏洞\end{cases}\\disk\ failure\end{cases} ⎩⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎧transaction failure{logical errorsystem errorsystem crash{硬件故障软件漏洞disk failure

2.Recovery Algorithm

恢复算法有两部分：

正常事务处理过程中保证有足够的的信息去从失败中恢复
在事务失败后恢复数据库到保证原子性，一致性和持久性的状态

16.2 Storage Structure

易失性 Volatile storage：主存等，在系统崩溃后失效
非易失性 Nonvolatile storage：磁盘，闪存等，可能失效，丢失数据
稳定存储介质 Stable storage：RAID等，有备份算法

16.2.1 Stable-Storage Implementation

保持每个块的多个备份在分离的磁盘块上：

备份需要转移到其他的地方，防止火灾，洪水等灾难。

在数据转移期间的失败仍可能造成不一致的拷贝，数据转移的结果有：

successful completion：传送的信息安全到达目的地
partial failure：传输过程中发生故障，目标块中有不正确信息
total failure：故障发生的足够早，目标块仍完好无损

Protecting storage media from failure during data transfer (one solution):

Write the information onto the first physical block.
When the first write successfully completes, write the same information onto the second physical block.
The output is completed only after the second write successfully completes.

由于输出操作的故障，一个块的副本可能会不同。从失败中恢复:

首先找到不一致的块:
- 昂贵的解决方案:比较每个磁盘块的两个副本。
- 更好的解决方案:在非易失性存储器(非易失性RAM或磁盘的特殊区域)上记录正在进行的磁盘写操作。
  
  在恢复期间使用这些信息来查找可能不一致的块，并且只比较这些块的副本。用于硬件RAID系统
如果一个不一致的块的任何一个副本被检测到有错误(坏的校验和)，则用另一个副本覆盖它。

如果两者都没有错误，但不同，则用第一个块覆盖第二个块

16.2.2 Data Access

pyhsical blocks：在磁盘上的块
buffer blocks：在主存中的块

磁盘和主存间的块移动时由下面两个操作引发的：

input(B)传送物理块B至主存
output(B)传输缓冲块B值磁盘

read()和write()都没有指明需要将块从主存中传送到磁盘。

output(B)：数据库系统对缓冲块B进行强制输出force-output

16.3 Recovery and Atomicity

为达到原子性的目标，必修在修改数据库本身前，向稳定存储器输出信息，描述要做的修改。

16.3.1 Log-Based Recovery

1.日志概念和日志中的项

使用最广泛的记录数据库修改的是日志（log）：是日志记录log record的序列，记录了数据库中所有的更新活动

事务标识transaction identifier：执行write操作的唯一标识
数据项标识data-item identifier：是所写数据项的唯一标识，通常是数据项在磁盘中的位置，包括数据项所驻留的块的块标识和块内偏移量
旧值old value：数据项的写前值
新值new value：数据项写后的值

一个日志记录表示为<Ti, Xj, V1, V2>：事务Ti对数据项Xj执行了一个写操作，写操作前是V1，写操作后是V2

<Ti start>：事务Ti开始

<Ti commit>：事务Ti提交

<Ti abort>：事务Ti终止

16.3.2 Modification of DataBase

使用日志的两种方式：

延迟修改 deferred-modification：事务到提交时都没有修改数据库
立即修改 immediate-modification：数据库修改在事务仍然活跃时发生，则采用了立即修改

16.3.3 Concurrency Control and Recovery

对于并发事务：所有的事务共享单个磁盘缓冲区和单个日志。

假设，如果一个事务Ti修改了一个项目，那么在事务T提交或者终止之前，其他事务不能修改这个项目。——未提交的事务更新不应该对其他事务课件。

可以通过获取更新项目上的排它锁并保持该锁直到事务结束（严格的两相锁strict two-phase lock保证）

不同的事务可能穿插在日志中。

16.3.4 Transaction commit

当一个事务的commit日志记录输出到稳定存储器后，我们说事务已经提交commit。

事务提交时，事务执行的写操作可能还存在于缓冲区中。

16.3.5 Undo and Redo Operations

1.对于数据项的undo和redo

undo of a log record <Ti, X, V1, V2> writes the old value V1 to X 数据项恢复成它原来的旧值
redo of a log record**<Ti, X,V1,V2>** writes the new value V2 to X 数据项写成他的新值

2.对于事务的undo和redo

对事务的undo和redo：

undo(Ti)：恢复由Ti更新的所有数据项的值从，TiT_iTi的最后一个日志记录向前回溯going backwards from the last log record for Ti;

每当数据项X恢复到原来的值V时，就会写入一个特殊的日志记录<T_i,X, V>

当事务的撤销操作完成时，将产生一条日志记录<Ti abort>。
redo(T)设置由TiT_iTi更新的所有数据项的值到新的值，从TiT_iTi的第一个日志记录开始执行;

在这种情况下，没有进行日志记录

系统崩溃时，查阅日志，对一些事务进行重做，对另一些事务进行撤销：

transaction Ti needs to be undone if log:

包含记录<Ti strat>
不包含记录<Ti committed>或者<Ti abort>

transaction Ti needs to be redone if log:

包含记录<Ti strat>
包含记录<Ti committed>或者<Ti abort>：如果记录中undo操作，那么undo的过程也会被重复——历史重复repeating history

16.3.6 Checkpoints

1.增加checkpoints的原因

Redoing/undoing all transactions recorded in the log can be very slow

processing the entire log is time-consuming if the system has run for a long time
we might unnecessarily redo transactions which have already output their updates to the database.

2.检查点的执行

将当前位于主存的所有的日志记录输出到稳定存储器
将所有修改过的缓冲块输出到磁盘
讲一个日志记录<checkpony L>输出到稳定存储器，L是执行检查点时活跃的事务列表

在恢复期间，我们需要考虑的仅仅是在检查点开始前的最近的事务Ti，以及在检查点后开始的事务。

扫描日志，找到最近的一次<checkponit L>记录：从尾向前反向搜索日志，直到遇到第一条<check point>
对于L中的事务，以及<checkpoint L>之后的事务进行undo或者redo操作，这个集合记作T
- 对T中的事务，若日志中既没有<Tk commit>记录，也没有<Tk abort>记录，那么执行undo(Tk)
- 对T中的事务，若日志中有<Tk commit>或者<Tk abort>，那么执行redo<Tk>

16.4 Recovery Algorithm

16.4.1 Logging

Logging (during normal operation):

<Ti start> at transaction start
<Ti,Xj,V1,V2>for each update
<Ti commit>at transaction end

16.4.2 rollback

正常操作中的事务回滚：

Let Ti be the transaction to be rolled back.

Scan log backwards from the end, and for each log record of Ti of the form <Ti Xj V1 V2>
- perform the undo by writing V1 to Xj
- write a log record <Ti, Xj, V1> ——such log records are called compensation log records
Once the record <Ti start> is found stop the scan and write the log record <Ti abort>

16.4.3 Recovery from failure：Two phase

{Redo phase：replay updates of all transactions, whether they committed, aborted, or are incompleteUndo phase： undo all incomplete transactions\begin{cases}\text{Redo phase：replay updates of all transactions, whether they committed, aborted, or are incomplete}\\\text{Undo phase： undo all incomplete transactions}\end{cases} {Redo phase：replay updates of all transactions, whether they committed, aborted, or are incompleteUndo phase： undo all incomplete transactions

1.Redo Phase

Find last <checkpoint L>record, and set undo-list to L.
Scan forward from above <checkpoint L> record 从记录开始，向时间轴后扫描
- Whenever a record <Ti,Xj,V1,V2>or <Ti,Xj,V1> is found, redo it by writing V2 to Xj
- Whenever a log record <Ti start> is found, add Ti to undo-list
- Whenever a log record <Ti commit> or <Ti abort> is found remove Ti from undo-list

2.undo Phase

Scan the backforwards from the end
- Whenever a log record <Ti,Xj,V1,V2> is found where Ti is in undo-list perform same actions as for transaction rollback:
  - perform undo by writing V1 to Xj
  - write a log record <Ti,Xj,V1>
- Whenever a log record <Ti start> is found where Ti is in undo-list,
  - Write a log record <Ti abort>
  - Remove Ti from undo-list
- Stop when undo-list is empty
After undo phase completes, normal transaction processing can commence

16.5 Buffering Managment

16.5.1 Log Record Buffering

1.概念

日志记录缓冲：日志记录被缓冲在主存中，而不是直接输出到稳定存储器中。

当缓冲区中的日志记录块满或执行日志强制log force操作时，日志记录将输出到稳定存储中。

日志强制是通过强制事务的所有日志记录(包括提交记录commit record)到稳定的存储中来执行的。因此，可以使用一个输出操作输出多个日志记录，从而降低了I/O成本。

2.Write-Ahead Logging WAL规则

如果要对日志记录进行缓冲，必须遵循以下规则:

日志记录按照创建的顺序输出到稳定存储中。
事务Ti只有在日志记录<Ti commit>已输出到稳定存储时才进入commit状态。
在主存中的数据块输出到数据库之前，与该块中的数据相关的所有日志记录都必须输出到稳定存储中。

该规则称为预写日志记录或WAL规则

16.5.2 Database Buffering

1.缓存策略

数据库在内存中维护数据块的缓冲区

当需要一个新的块时，如果缓冲区已满，则需要从缓冲区中删除现有的块——老块移出
如果被选择删除的块已经更新，它必须被输出到磁盘——写入磁盘

恢复算法支持无强制no-force policy策略：即事务提交时不需要将更新的块写入磁盘

强制策略force policy：要求在提交时写入更新的块

更昂贵的承诺恢复算法支持窃取策略steal policy：包含未提交事务更新的块可以被写入磁盘，甚至在事务提交之前

2.保证

当一个块被输出到磁盘时，它不应该正在进行更新。可以保证如下：

在写入数据项之前，事务在包含该数据项的块上获得排他锁
一旦写操作完成，锁就会被释放。
这种短时间持有的锁称为锁存latches

3.输出的过程

To output a block to disk

First acquire an exclusive latch on the block 获取块上的排它锁
- Ensures no update can be in progress on the block
Then perform a log flush
Then output the block to disk
Finally release the latch on the block

4.数据库缓存的实现

数据库缓冲区可以在为数据库保留的实际主存区域中实现，也可以在虚拟内存中实现

在预留主存中实现缓冲区有缺点:
- 在数据库缓冲区和应用程序之间预先对内存进行分区，限制了灵活性。
- 需求可能会改变，尽管操作系统在任何时候都知道应该如何划分内存，但它不能改变内存的分区。
数据库缓冲区通常在虚拟内存中实现，尽管有一些缺点
- 当操作系统需要删除已被修改的页面时，该页面将被写入磁盘上的交换空间当数据库决定将缓冲区页写入磁盘时，缓冲区页可能位于交换空间中，并且可能必须从磁盘上的交换空间读取并输出到磁盘上的数据库，从而导致额外的I/O称为双分页问题。
- 理想情况下，当OS需要从缓冲区中删除页面时，它应该对数据库进行控制，而数据库也应该这样做如果页面被修改，则将其输出到数据库而不是交换空间(确保首先输出日志记录)
- 从缓冲区释放页面，供操作系统使用这样可以避免双分页，但是普通操作系统不支持这种功能。

16.6

到目前为止，我们假设非易失性存储没有损失。
类似于用于处理非易失性存储丢失的检查点的技术，定期将数据库的全部内容转储dump到稳定存储中在转储过程中，

转储过程中没有事务是活动的，类似于检查点的过程将发生。

将当前驻留在主存中的所有日志记录输出到稳定存储器中
输出所有的缓冲块到磁盘上将数据库的内容复制到稳定存储中。
输出<dump>记录登录稳定存储。

转储也有模糊转储(在线转储)的计算，相当于应用了快照。