数据库期末复习第7章

第7章   事务管理

数据库恢复

保证事务始终满足ACID准则的一系列技术措施称事务管理(Transaction Management)，包括两个方面
当系统发生故障时的技术措施，称数据库恢复(Database Recovery)。
当多个事务并发执行时的技术措施，称并发控制(Concurrency Control)。

恢复的基本技术

三类故障
事务失效(Transaction Failure)
特证：发生在事务提交完成前。 
系统失效(System Failure)
特征：内存数据全部丢失，但外存上的数据库未遭破坏。
介质失效(Media Failure)
特征：外存上的数据库已遭破坏，一切已提交的事务对数据库的影响全部丢失。 
介质故障比前两类故障的可能性小得多，但破坏性大得多。

常用技术
数据后备复本 (backup)
周期性地把（磁盘上的）数据库物理文件复制（称转储Dumping）到磁带上，建立副本。
做后备时，数据库须保持一致状态。通常需暂停系统的运行。
运行记录/日志 (logging)
从数据库建立并开始运行起，记录全部提交事务对数据库的所有更新操作的文件，包括以下内容：
事务及其状态：
事务标识（TID）
提交了(commit) / 回滚了(rollback)?
前像 & 后像
前像(Before Image, BI)：每次更新时，数据块的旧值。(插入时，BI为空)。
后像(After Image, AI)：每次更新时，数据块的新值。(删除时，AI为空)。
方法：
有了BI，如果需要，可使DB恢复到更新前的状态（可撤销更新）—— 称撤销(Undo)；
有了AI，如果需要，可使DB恢复到更新后的状态（可重做更新）—— 称重做(Redo)。
因此，有了日志，当发生故障时，可通过以下方法完全恢复DB：
若数据库未遭破坏，则从最近一致状态开始，对未提交事务进行Undo—向后恢复(Backward Recovery)；对已提交事务进行Redo—向前恢复(forward Recovery)。
若数据库遭破坏，则先重装最近的Backup，再对Backup以来的所有已提交事务进行Redo。

Backup+Log是最典型/常用的技术，绝大多数商品化DBMS均采用这种技术。 

多复本
独立失效模式(Independent failure Mode)：不致因同一故障而一起失效（因为支持环境是独立的）。
方法：系统中保持多个具有独立失效模式的数据库复本，互为备份、互为恢复的依据。
例如：镜像（Mirroring）技术，Mirrored Disks / Mirrored Files

日志结构与机制

日志存储的基本内容
活动事务表(ATL)：记录还在执行但尚未提交的事务标识(TID)。
提交事务表(CTL)：记录已提交事务的标识。
当一个事务被提交结束时，做：①TID→CTL；②Remove TID from ATL
前像文件：记录所有被更新的数据块之旧值BI，用于进行Undo操作。

后像文件：记录所有被更新的数据块之新值AI，用于进行Redo操作。

更新事务的执行与恢复

为保证数据库是可恢复的，更新事务在系统具有日志机制后，其执行应遵守下列两条规则:
提交规则(Commit Rule) 
后像AI必须在事务提交前写入非易失存储器(即数据库或日志文件)。
通常是立即写入DB Buffer Cache和Log文件，以便当发生故障时，能通过Redo而恢复。 
先记后写规则(Log Ahead Rule)
如果AI在事务提交前写入数据库，则必须首先把BI记入日志。
写日志文件操作：把表示这个修改的日志记录写到日志文件
写数据库操作：把对数据的修改写到数据库中
以便一旦事务在提交前瞬间失败时，能通过Undo而恢复。

后像在事务提交前完全写入数据库，步骤如下 
<1> TID→ATL
<2> BI→Log          /* 先记后写规则  */
<3> AI→DB          /* 提交规则      */   /* AI直接写入数据库 */
<4> TID→CTL
<5> 从ATL删除TID 
当事务执行中发生故障时，根据ATL和CTL中是否有该事务的TID，采取不同的恢复措施

ATL	CTL	事务所处状态	恢复措施
有	－	(1)已完成,但(4)尚未完成	(1) 若 BI已写入日志，则UNDO,否则无需UNDO    (2) 从ATL删除TID