(数据库原理课件)Chapter15-Recovery

事务处理事务处理提纲并发控制基于锁的协议两段锁协议多粒度封锁带来的问题恢复故障日志恢复提纲并发控制Chapter15

RecoveryChapter15

Recovery提纲故障分类数据库恢复备份恢复提纲故障分类1.故障分类事务故障指事务的运行没有到达预期的终点就被终止非预期故障不能由事务程序处理的如运算溢出，发生死锁而被选中撤消该事务可预期故障应用程序可以发现的事务故障，并且应用程序可以让事务回滚如转帐时发现帐面金额不足1.故障分类事务故障故障分类系统故障软故障(softcrash)：在硬件故障、软件错误的影响下，虽引起内存信息丢失，但未破坏外存中数据如CPU故障、突然停电，DBMS,OS,应用程序等异常终止介质故障硬故障(hardcrash)：又称磁盘故障，破坏外存上的数据库，并影响正在存取这部分数据的所有事务如磁盘的磁头碰撞、瞬时的强磁场干扰故障分类系统故障2.数据库恢复恢复的定义恢复是把数据库从错误状态恢复到某一正确状态的功能，从而确保数据库的一致性恢复的基本原理是冗余，即数据库中任一部分的数据可以根据存储在系统别处的冗余数据来重建2.数据库恢复恢复的定义2.1备份转储将数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据称为后备（后援）副本静态转储转储期间不允许对数据库进行任何存取、修改活动动态转储转储期间允许对数据库进行存取或修改海量转储每次转储全部数据库增量转储每次只转储上次转储后更新过的数据2.1备份转储备份策略数据库备份数据库备份创建备份完成时数据库内存在的数据的副本，通常按常规时间间隔调度还原数据库备份将重新创建数据库和备份完成时数据库中存在的所有相关文件。但是，自创建备份后所做的任何数据库修改都将丢失USEmasterEXECsp_addumpdevice'disk',‘MyBKDB', DISK='c:\MyBKDB.dat'BACKUP

DATABASEstuInforTOMyBKDBRESTORE

DATABASEstuInforFROMMyBKDB备份策略数据库备份USEmaster备份策略SQLServer支持的备份策略主要有4种：完全数据库备份差异数据库备份文件与文件组备份事务日志备份备份策略SQLServer支持的备份策略主要有4种：备份策略生成备份设备sp_addumpdevice‘devtype’,‘logical_name’,‘physical_name’生成磁盘备份设备UsemasterExecsp_addumpdevice‘disk’,‘nwbackup’,‘D:\backups\nwbackup.bak’备份策略生成备份设备备份策略备份数据库备份到磁盘备份设备BACKUPDATABASEnorthwindtonwbackup备份到指定路径：BACKUPDATABASEnorthwindtoDISK=‘D:\backups\nwbackup.bak’思考：如何利用存储过程，动态建立

dbname_db_YYMMDDHHMM.bak格式的备份文件名备份策略备份数据库备份策略（1）完全数据库备份usemasterBACKUPDATABASENorthwindtonwbackupWITHNOUNLOA,NAME=‘Northwindfulldatabasebackup’,Description=‘Fullbackupforwednesday’备份策略（1）完全数据库备份备份策略（2）差异数据库备份(DCM)usemasterBACKUPDATABASENorthwindtoDISK=‘D:\backup\nwtemp.bak’WITHDIFFERENTIAL,NAME=‘Northwindfulldatabasebackup’,Description=‘Fullbackupforwednesday’备份策略（2）差异数据库备份(DCM)备份策略（3）事务日志备份事务日志是自上次备份事务日志后对数据库执行的所有事务的一系列记录，它可以将数据库恢复到特定的即时点或恢复到故障点BACKUPDATABASEMyDBTOMyDB_1WITHINITBACKUPLOGMyDBTOMyDB_log1BACKUPLOGMyDBTOMyDB_log2WITHNO_TRUNCATERESTOREDATABASEMyDBFROMMyDB_1WITHNORECOVERYRESTORELOGMyDBFROMMyDB_log1

WITHNORECOVERYRESTORELOGMyDBFROMMyDB_log2

WITHRECOVERY备份策略（3）事务日志备份BACKUPDATABASEM备份策略（3）事务日志备份简单日志备份--Backuptoapermanentbackupdevice.Don’tinitializethedeviceusemasterbackuplognorthwindtonwlogbackwithnoinit,Name=‘northwindlogbackup’noformat备份策略（3）事务日志备份备份策略（3）事务日志备份清除完全事务日志usemasterbackuplognorthwindtonwlogbackwithno_log备份策略（3）事务日志备份备份策略（3）事务日志备份无法访问数据库时备份日志usemasterbackuplognorthwindtonwlogbackwithno_truncate备份策略（3）事务日志备份备份策略如果是对同一数据的反复修改，那么差异备份会快一些，因为它只备份最近的修改，而日志备份则需要记录每一次更新差异备份记录下新的索引的整个B树结构，而日志备份则记录构建索引的每个步骤差异备份是累积的。进行恢复时，只需要恢复最近的差异备份，因为它包含了最近一次完全数据库备份以来所有的修改日志备份使得你可以恢复到任何即时点日志备份可以在数据库发生介质故障时进行，只要日志是可用的。这使得你可以将数据库恢复到故障点备份策略如果是对同一数据的反复修改，那么差异备份会快一些，因备份策略文件备份可以备份和还原数据库中的个别文件。这样可以只还原已损坏的文件，而不用还原数据库的其余部分，从而加快恢复速度BACKUPDATABASEMyDBFILE='MyDB_data_1',FILEGROUP='file_group1',FILE='MyDB_data_2',FILEGROUP='file_group2'TOMyDB_1RESTOREDATABASEMyDBFILE='MyDB_data_1',FILEGROUP='file_group1',FILE='MyDB_data_2',FILEGROUP='file_group2'FROMMyDB_1WITHNORECOVERY备份策略文件备份BACKUPDATABASEMyDBR恢复到即时点可以通过只恢复在事务日志备份内特定即时点之前发生的事务来恢复到即时点，而不用恢复整个备份backupset表在事务日志中插入命名标记以恢复到特定的标记logmarkhistory表RESTOREDATABASEMyDBFROMMyDBWITHNORECOVERYRESTORELOGMyDBFROMMyDB_log1

WITHRECOVERY,STOPAT='Jul1,200310:00AM'恢复到即时点可以通过只恢复在事务日志备份内特定即时点之前发恢复模型简单恢复允许将数据库恢复到最新的备份数据库备份+差异备份（可选）完全恢复允许将数据库恢复到故障点状态数据库备份+差异备份（可选）+事务日志备份大容量日志记录恢复(BCM)允许大容量日志记录操作（SELECTINTO，bcp，BULKINSERT）数据库备份+差异备份（可选）+事务日志备份恢复模型简单恢复恢复模型切换恢复模型可以将数据库从一个恢复模型切换到另一个恢复模型，以满足不断变化的业务要求例如，如果系统需要完全的可恢复性，可以在装载和索引操作的过程中，将数据库的恢复模型更改到批量日志记录模型，然后再返回到完全恢复切换恢复模型：ALTERDATABASE<database_name> SETRECOVERY[FULL|BULK_LOGGED|SIMPLE]查看当前数据库所使用的恢复模型：SELECTDATABASEPROPERTYEX('<database_name>','recovery')

恢复模型切换恢复模型切换恢复模型：2.2数据库恢复日志日志文件是以事务为单位用来记录数据库的每一次更新活动的文件，由系统自动记录日志内容包括：记录名、旧记录值、新记录值、事务标识符、操作标识符等事务Ti开始时，写入日志：<Tistart>事务Ti执行write(X)前，写入日志：<Ti,X,V1,V2>，V1是X更新前的值，V2

是X更新后的值事务Ti结束后，写入日志：<Ti

commit>2.2数据库恢复日志数据库恢复T0: read(A) T1

: read(C) A:=A-50

C:=C-100 Write(A) write(C) read(B) B:=B+50 write(B)<T0

start><T0

A,1000,950><T0,B,2000,2050><T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600><T0start><T0,A,1000,950><T0,B,2000,2050><T0commit><T1start><T1,C,700,600><T1commit>(a)(b)(c)数据库恢复T0: read(A) T1: rea数据库恢复延迟更新技术通过在日志中记录所有数据库修改，而将一个事务的所有write操作拖延到事务部分提交时才执行一旦日志记录都写到了稳定存储器上，就真正执行更新，并且事务进入提交状态延迟更新技术只需要数据项的新值<T0

start><T0

A,950><T0,B,2050><T0start><T0,A,950><T0,

B,2050><T0

commit><T1start><T1,C,600><T0start><T0,A,950><T0,B,2050><T0commit><T1start><T1,C,600><T1commit>(a)(b)(c)数据库恢复延迟更新技术<T0start><T0start数据库恢复延迟更新技术<T0

start><T0

A,950><T0,B,2050><T0start><T0,A,950><T0,

B,2050><T0

commit><T1start><T1,C,600><T0start><T0,A,950><T0,B,2050><T0commit><T1start><T1,C,600><T1commit>(a)(b)(c)不必做任何redo操作删除日志Redo(T0)删除T1日志Redo(T0)Redo(T1)数据库恢复延迟更新技术<T0start><T0start数据库恢复立即更新技术允许数据库修改在事务仍处于活跃状态时就输出到数据库中。活跃事务所作的数据修改称为未提交修改必须遵守先写日志的原则先写日志的原则（WAL）对于尚未提交的事务，在将DB缓冲区写到外存之前，必须先将日志缓冲区内容写到外存去日志记录将要发生何种修改写入DB表示实际发生何种修改如果先写DB，则可能在写的中途发生系统崩溃，导致内存缓冲区内容丢失，而外存DB处于不一致状态，由于日志缓冲区内容已破坏，导致无法对DB恢复数据库恢复立即更新技术数据库恢复先写DB<T0

start><T0

A,1000,950>A=950B=2050故障发生点<T0

start><T0

A,1000,950>

A=1000B=2050故障恢复后先写日志<T0

start><T0

A,1000,950><T0,B,2000,2050>A=950B=2000故障发生点<T0

start><T0

A,1000,950><T0,B,2000,2050>

A=1000B=2000故障恢复后数据库恢复先写DB<T0start>A=950故障发生点<数据库恢复日志缓冲区数据库缓冲区日志数据库WAL调入B2输出B1输出所有与B1有关的日志记录输出B1调入B2同步(synchronous)写日志：只有事务的相关日志已经完全在磁盘上了，才会向进程发送该事务已提交的确认消息异步(asynchronous)写缓冲区：只需要将数据页的写入操作投递给操作系统即可，不需要等待其完成数据库恢复日志缓冲区数据库缓冲区日志数据库WAL调入B2输出数据库恢复事务分类圆满事务日志文件中记录了事务的commit标识夭折事务日志文件中只有事务的Begintransaction标识，无commit<T0

start><T0

A,1000,950><T0,B,2000,2050>T0夭折事务<T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600>T0圆满事务，T1夭折事务<T0start><T0,A,1000,950><T0,B,2000,2050><T0commit><T1start><T1,C,700,600><T1commit>T0圆满事务，T1圆满事务数据库恢复事务分类<T0start>T0夭折事务<T0s数据库恢复基本的恢复操作对圆满事务所做过的修改操作应执行redo操作，即重新执行该操作，修改对象被赋予新记录值

redo=redo2对夭折事务所做过的修改操作应执行undo操作，即撤消该操作，修改对象被赋予旧记录值

undo=undo2undo<T0

A,1000,950>A=1000redo<T0

A,1000,950>A=950数据库恢复基本的恢复操作undo<T0A,1000,数据库恢复事务故障恢复撤消事务已对数据库所做的修改措施反向扫描日志文件，查找该事务的更新操作对该事务的更新操作执行逆操作，即将事务更新前的旧值写入数据库继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理如此处理下去，直至读到此事务的开始标识，事务的故障恢复就完成了数据库恢复事务故障恢复数据库恢复<T0

start><T0

A,1000,950><T0,B,2000,2050>A=950B=2000故障发生点<T0

start><T0

A,1000,950>undo<T0,B,2000,2050>A=950B=2000故障恢复1<T0

start>undo<T0

A,1000,950><T0,B,2000,2050>

A=1000B=2000故障恢复2<T0

start><T0

A,1000,950><T0,B,2000,2050>

A=1000B=2000故障恢复结束数据库恢复<T0start>A=950故障发生点<T0s数据库恢复反向撤销事务操作<T0,A,1000,950><T0,A,950,900>A=950故障发生点<T0,A,1000,950>undo<T0,A,950,900>

A=950正向撤销事务操作undo<T0,A,1000,950><T0,A,950,900>A=1000undo<T0,A,1000,950><T0,A,950,900>A=1000<T0,A,1000,950>undo<T0,A,950,900>A=950数据库恢复反向撤销事务操作<T0,A,1000,950数据库恢复系统故障恢复不一致状态原因未完成事务对数据库的更新已写入数据库已提交事务对数据库的更新未写入数据库措施正向扫描日志文件，找出圆满事务，记入重做队列；找出夭折事务，记入撤消队列反向扫描日志，对撤消队列中事务Ti的每一个日志记录执行undo操作正向扫描日志文件，对重做队列中事务Ti的每一个日志记录执行redo操作数据库恢复系统故障恢复数据库恢复<T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600>T0圆满事务，T1夭折事务<T0start>redo<T0,A,1000,950>redo<T0,

B,2000,2050><T0

commit><T1start>undo<T1,C,700,600>A=950,B=2050,C=700数据库恢复<T0start>T0圆满事务，T1夭折事务<T数据库恢复介质故障恢复磁盘上数据文件和日志文件遭到破坏措施装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态装入相应的日志文件副本，重做已完成的事务TaTbTf正常运行介质故障恢复转储运行事务故障发生点重装后援副本利用日志文件恢复事务继续运行数据库恢复介质故障恢复TaTbTf正常运行介质故障恢复转储运检查点(Checkpoint)问题当系统故障发生时，我们必须搜索整个日志，以决定哪些事务需要redo，哪些需要undo大多数需要被重做的事务其更新已经写入了数据库中（redo2）。尽管对它们重做不会造成不良后果，但会使恢复过程变得更长检查点原理保证在检查点时刻日志与数据库内容是一致的检查点(Checkpoint)问题保证在检查点时刻日志与数据检查点带有检查点记录的日志生成将当前日志缓冲区的所有日志记录写入稳存中在日志文件中写入一个检查点记录将当前数据缓冲区的所有数据记录写入稳存中输出检查点时活跃事务的列表L检查点故障点无须REDOREDOREDOUNDOUNDO检查点带有检查点记录的日志生成检查点故障点无须REDOREDSQLServer：最小恢复LSNMinLSN是下面这些LSN中的最小LSN：检查点起点的LSN最旧的活动事务起点的LSNLSN141LSN142LSN143LSN144LSN145LSN146LSN147LSN148开始Tran1开始Tran2更新Tran2检查点更新Tran1提交Tran1检查点更新Tran2SQLServer：最小恢复LSNMinLSN是下面这些LSQLServer：生成检查点将标记检查点起点的记录写入日志文件将为检查点记录的信息存储在检查点日志记录链内。将这条链起点的LSN写入数据库根页将最小恢复LSN(MinLSN)保存在检查点记录中将所有未完成的活动事务列表保存在检查点记录中如果数据库使用的是简单恢复模式，则删除新的MinLSN之前的所有日志记录将所有脏日志和数据页写入磁盘将标记检查点末端的记录写入日志文件SQLServer：生成检查点将标记检查点起点的记录写入日SQLServer：生成检查点检查点线程遍历缓冲区池，按照缓冲区编号顺序扫描页面，当它发现脏页时，它将查看与该页面物理(磁盘上)连续的其他页面是否也是脏的，这样它可以进行大块写操作如果它看到页面5是脏的时，它可能会写入页面10、25、380、500等，这些页面在磁盘上是连续的，尽管它们在缓冲区内相去甚远。这样，缓冲区中非连续的页面可以被一次聚集写入(gather-write)磁盘(它是借助于WindowsNT的Win32函数WriteFileGather实现的)以后检查点会到达页面500，为避免将该页面重复写入磁盘，检查点算法会为每个页面设置标志位，开始时所有的位都相同(都为0或1)。当检查点检查到某个页面时，它将其标志位翻转。如果检查点碰到具有相反位的页面，它就跳过该页面对于在检查点期间新近引入的页面，或者已经被检查点输出到磁盘但又重新变脏的页面，都不会被该次检查点操作写入SQLServer：生成检查点检查点线程遍历缓冲区池，按照SQLServer：生成检查点recoveryinterval选项设置SQLServer恢复数据库所需的最大分钟数，默认值为0，表示每个数据库的恢复时间不超过1分钟据此SQLServer将估计在恢复时间间隔期间可以处理多少更新的数据，从而决定在每一个数据库中SQLServer何时生成一次检查点。实际中，SQLServer根据10MB的日志可以在1分钟内得到恢复这样一个估计来确定它的恢复间隔一个数据库中，当最近一个检查点之后数据更新操作达到了SQLServer认为可以在恢复时间间隔更新的数量时，SQLServer将进行一个检查点操作SQLServer：生成检查点recoveryinterSQLServer：生成检查点SQLServer自动生成检查点的时间间隔基于日志内的记录数而非时间。如果数据库只做了很少的修改，自动检查点的时间间隔就长。如果修改了大量数据，自动检查点将经常发生检查点间隔取决于recoveryinterval配置以及数据库使用的恢复模式每当日志记录数达到SQLServer估计在recoveryinterval选项所指定的时间内能处理的记录数时，就生成自动检查点如果数据库使用的是简单恢复模式，则当日志的70%已满，就生成自动检查点，以截断日志并释放空间。但如果没有空间可以被释放，则不生成检查点SQLServer：生成检查点SQLServer自动生成SQLServer：事务日志物理构架每个物理日志文件分成许多虚拟日志文件事务日志是回绕的日志文件。当创建数据库时，逻辑日志从物理日志文件的始端开始。在逻辑日志的末端添加新的日志记录，逻辑日志就向物理日志末端增长当逻辑日志的末端到达物理日志文件的末端时，新的日志记录绕回物理日志文件的始端。这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端从MinLSN到日志末端的日志文件部分称为日志的活动部分。这是进行数据库完全恢复所需的日志部分永远不能截断活动日志的任何部分。所有的日志截断都必须从MinLSN之前的日志部分进行。发生截断操作时，删除MinLSN之前的虚拟日志内的记录SQLServer：事务日志物理构架每个物理日志文件分成许SQLServer：事务日志物理构架虚拟日志1虚拟日志2虚拟日志3虚拟日志4虚拟日志5被截断未使用逻辑日志的始端逻辑日志的末端MinLSN最后一个检查点虚拟日志1虚拟日志2虚拟日志3虚拟日志4被截断逻辑日志的始端逻辑日志的末端MinLSN最后一个检查点倒数第二个检查点SQLServer：事务日志物理构架虚拟日志1虚拟日志2虚逻辑Undo日志一般恢复技术要求一旦事务更新了一个数据项，其它事务都不能更新该数据项，直至第一个事务提交或回滚严格两阶段封锁协议实施到某些特殊结构如B+树索引页时，并发性极度下降。为提高并发性，可以使用非两段方式使锁较早释放如果事务T向B+树插入了一项，在插入操作结束后但在事务提交前释放了某些锁。在锁释放后，其它事务可执行插入或删除操作，于是造成对B+树结点的进一步改变如果使用物理undo执行事务回滚，即事务回滚时我们将B+树内部结点（执行插入操作前）的旧值写回，那么其它事务在其后执行的插入或删除操作所做的某些更新可能会丢失插入操作必须通过一个逻辑undo来完成，即通过执行一次删除操作撤消逻辑Undo日志一般恢复技术要求一旦事务更新了一个数据项，模糊检查点(fuzzycheckpoint)

一般检查点技术要求对数据库的所有更新在检查点进行过程中暂时中止。若缓存中页的数量非常大，完成一个检查点的时间会很长，这会导致事务处理中不可接受的中断模糊检查点允许在检查点记录写入日志后但在修改过的缓冲块写到磁盘前做更新只有在写入检查点记录之后页才输出到磁盘，系统可能在所有页写完之前崩溃，这样，磁盘上的检查点就是不完整的一种处理不完整检查点的方法是：将最后一个完整检查点记录在日志中的位置存在磁盘上固定的位置last_checkpoint上，系统在写入checkpoint记录时不更新该信息，而是在写checkpoint记录前，创建所有修改过的缓冲块的列表，只有在所有该列表中的缓冲块都输出到了磁盘上以后，last_checkpoint信息才会更新模糊检查点(fuzzycheckpoint)一般检查点ARIES算法：数据结构LSN在增长的日志记录空间中的日志记录的第一个字节的地址。这是一个单调递增的数值Type表示一个记录是补偿日志（'compensation'），正常更新记录('update')，一个提交协议相关记录（例如'prepare'）TransID事务的标记，如有，则写入到日志记录中ARIES算法：数据结构LSNARIES算法：数据结构PrevLSN本事务的前一条日志记录的LSN。对该事务的第一条日志记录而言是0，因此，不需要用一条日志记录显式地表示一条事务的开始PageID只在Update和compensation类型的记录中出现，它记录本记录所所做更新的页面的标记Data这是描述欲更新的redo和/或undo数据。CLR只包含redo信息，因为它们不能undoARIES算法：数据结构PrevLSNARIES算法：数据结构UndoNxtLSN只在CLR中出现，它指的是回滚阶段要处理的下一个本事务的日志记录，也即UndoNxtLSN是当前日志正在弥补的日志记录的PrevLSN的数值。如果已经没有日志记录需要undo，该数据域就会是0页面结构数据库的每个页都有page_LSN域。它包含描述对该页面所做的最近更新日志记录的LSN。ARIES算法：数据结构UndoNxtLSNARIES算法：数据结构事务表事务表记录活跃事务的状态TransID：事务的IDState：事务的提交状态LastLSN：事务所写的最后一条LSNUndoNxtLSN：在回滚阶段下一个记录的LSN。如果本事务的最近日志记录是一个可undo的非CLR记录，这个字段的值就会被设为LastLSN。如果最近日志记录是CLR，此字段的值就设为此CLR的UndoNxtLSN的值ARIES算法：数据结构事务表ARIES算法：数据结构脏页表包含一个在数据库缓冲区中已更新页的列表，它为每一页保存其PageID和一个称为RecLSN的字段RecLSN用于标识日志记录，这些日志记录的磁盘页版本已实施更新当一页被插入到脏页表时，RecLSN的值被设置成日志的当前末尾只要页被写入磁盘，该页就被从脏页表中移除。检查点日志记录包含脏页和活动事务的列表，同时记录每个事务的LastLSNARIES算法：数据结构脏页表ARIES算法：三个原理先写日志 在将更新的数据库对象的修改写入磁盘之前，先将对应的日志记录写入稳存重做时重复历史 在崩溃后进行重新启动时，重做崩溃前的所有操作，使系统恢复到崩溃时的状态，然后取消崩溃时还在执行的事务已完成的操作恢复修改的记录数据 在取消某些事务时，如果出现对数据库的改变，则需要在日志中记录这些改变，保证在重复进行重新启动时不需要重复这些操作ARIES算法：三个原理先写日志ARIES算法：三个过程分析过程

决定哪些事务要undo，哪些页在崩溃时是脏的，以及redo应从哪个LSN开始Redo过程

从分析过程决定的位置开始，执行一个redo，重复历史，将数据库恢复到发生崩溃前的状态Undo过程

回滚在发生崩溃时那些不完整的事务ARIES算法：三个过程分析过程ARIES算法：系统故障恢复分析重做撤销崩溃时活动事务最早的日志记录分析结束时脏页中最小的recLSN最近的检查点崩溃日志ARIES算法中恢复的三个阶段ARIES算法：系统故障恢复分析重做撤销崩溃时活动事务最早的ARIES算法：分析过程找到最后完整检查点日志记录，并从该记录开始读入脏页表将RedoLSN设置为脏页表中页的RecLSN的最小值，如果没有脏页，就将其设置为检查点日志记录的LSN将要被undo的事务列表undo-list设置为检查点日志记录中的事务列表及其LastLSN从检查点继续向前扫描，每找到一个不在undo-list中的事务日志记录，就将其添加到undo-list，每找到一个事务的end日志记录，就将其从undo-list中删除只要发现一个更新页的日志记录，如果该页不在脏页表上，就将它添加进脏页表，并设置该页的RecLSN为该日志记录的LSN。ARIES算法：分析过程找到最后完整检查点日志记录，并从该记ARIES算法：Redo过程Redo过程通过重演所有没有在磁盘页上反映的动作来重复历史Redo过程从RedoLSN开始向前扫描日志，该点之前的日志记录已经反映在磁盘数据库页上只要Redo过程找到一个update日志记录，它就执行如下动作：如果该页不在脏页表中，或者该update日志记录的LSN小于脏页表中该页的RecLSN，Redo过程就跳过该日志记录否则Redo过程就从磁盘调出该页，如果其PageLSN小于该日志记录的LSN，重做该日志记录ARIES算法：Redo过程Redo过程通过重演所有没有在磁ARIES算法：Undo过程Undo过程反向扫描日志，取消所有undo-list中的事务如果找到一个CLR，它用UndoNextLSN字段跳过一个已经回滚了的事务日志。否则，它用事务日志的PrevLSN字段查找下一个要被撤消的事务日志每当一个update日志记录被用于撤消，Undo过程产生一个包含undo执行动作（必须是物理逻辑的）的CLR，并将CLR的UndoNextLSN设置为update日志记录的PreLSN值ARIES算法：Undo过程Undo过程反向扫描日志，取消所事务处理事务处理提纲并发控制基于锁的协议两段锁协议多粒度封锁带来的问题恢复故障日志恢复提纲并发控制Chapter15

RecoveryChapter15

Recovery提纲故障分类数据库恢复备份恢复提纲故障分类1.故障分类事务故障指事务的运行没有到达预期的终点就被终止非预期故障不能由事务程序处理的如运算溢出，发生死锁而被选中撤消该事务可预期故障应用程序可以发现的事务故障，并且应用程序可以让事务回滚如转帐时发现帐面金额不足1.故障分类事务故障故障分类系统故障软故障(softcrash)：在硬件故障、软件错误的影响下，虽引起内存信息丢失，但未破坏外存中数据如CPU故障、突然停电，DBMS,OS,应用程序等异常终止介质故障硬故障(hardcrash)：又称磁盘故障，破坏外存上的数据库，并影响正在存取这部分数据的所有事务如磁盘的磁头碰撞、瞬时的强磁场干扰故障分类系统故障2.数据库恢复恢复的定义恢复是把数据库从错误状态恢复到某一正确状态的功能，从而确保数据库的一致性恢复的基本原理是冗余，即数据库中任一部分的数据可以根据存储在系统别处的冗余数据来重建2.数据库恢复恢复的定义2.1备份转储将数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据称为后备（后援）副本静态转储转储期间不允许对数据库进行任何存取、修改活动动态转储转储期间允许对数据库进行存取或修改海量转储每次转储全部数据库增量转储每次只转储上次转储后更新过的数据2.1备份转储备份策略数据库备份数据库备份创建备份完成时数据库内存在的数据的副本，通常按常规时间间隔调度还原数据库备份将重新创建数据库和备份完成时数据库中存在的所有相关文件。但是，自创建备份后所做的任何数据库修改都将丢失USEmasterEXECsp_addumpdevice'disk',‘MyBKDB', DISK='c:\MyBKDB.dat'BACKUP

DATABASEstuInforTOMyBKDBRESTORE

DATABASEstuInforFROMMyBKDB备份策略数据库备份USEmaster备份策略SQLServer支持的备份策略主要有4种：完全数据库备份差异数据库备份文件与文件组备份事务日志备份备份策略SQLServer支持的备份策略主要有4种：备份策略生成备份设备sp_addumpdevice‘devtype’,‘logical_name’,‘physical_name’生成磁盘备份设备UsemasterExecsp_addumpdevice‘disk’,‘nwbackup’,‘D:\backups\nwbackup.bak’备份策略生成备份设备备份策略备份数据库备份到磁盘备份设备BACKUPDATABASEnorthwindtonwbackup备份到指定路径：BACKUPDATABASEnorthwindtoDISK=‘D:\backups\nwbackup.bak’思考：如何利用存储过程，动态建立

dbname_db_YYMMDDHHMM.bak格式的备份文件名备份策略备份数据库备份策略（1）完全数据库备份usemasterBACKUPDATABASENorthwindtonwbackupWITHNOUNLOA,NAME=‘Northwindfulldatabasebackup’,Description=‘Fullbackupforwednesday’备份策略（1）完全数据库备份备份策略（2）差异数据库备份(DCM)usemasterBACKUPDATABASENorthwindtoDISK=‘D:\backup\nwtemp.bak’WITHDIFFERENTIAL,NAME=‘Northwindfulldatabasebackup’,Description=‘Fullbackupforwednesday’备份策略（2）差异数据库备份(DCM)备份策略（3）事务日志备份事务日志是自上次备份事务日志后对数据库执行的所有事务的一系列记录，它可以将数据库恢复到特定的即时点或恢复到故障点BACKUPDATABASEMyDBTOMyDB_1WITHINITBACKUPLOGMyDBTOMyDB_log1BACKUPLOGMyDBTOMyDB_log2WITHNO_TRUNCATERESTOREDATABASEMyDBFROMMyDB_1WITHNORECOVERYRESTORELOGMyDBFROMMyDB_log1

WITHNORECOVERYRESTORELOGMyDBFROMMyDB_log2

WITHRECOVERY备份策略（3）事务日志备份BACKUPDATABASEM备份策略（3）事务日志备份简单日志备份--Backuptoapermanentbackupdevice.Don’tinitializethedeviceusemasterbackuplognorthwindtonwlogbackwithnoinit,Name=‘northwindlogbackup’noformat备份策略（3）事务日志备份备份策略（3）事务日志备份清除完全事务日志usemasterbackuplognorthwindtonwlogbackwithno_log备份策略（3）事务日志备份备份策略（3）事务日志备份无法访问数据库时备份日志usemasterbackuplognorthwindtonwlogbackwithno_truncate备份策略（3）事务日志备份备份策略如果是对同一数据的反复修改，那么差异备份会快一些，因为它只备份最近的修改，而日志备份则需要记录每一次更新差异备份记录下新的索引的整个B树结构，而日志备份则记录构建索引的每个步骤差异备份是累积的。进行恢复时，只需要恢复最近的差异备份，因为它包含了最近一次完全数据库备份以来所有的修改日志备份使得你可以恢复到任何即时点日志备份可以在数据库发生介质故障时进行，只要日志是可用的。这使得你可以将数据库恢复到故障点备份策略如果是对同一数据的反复修改，那么差异备份会快一些，因备份策略文件备份可以备份和还原数据库中的个别文件。这样可以只还原已损坏的文件，而不用还原数据库的其余部分，从而加快恢复速度BACKUPDATABASEMyDBFILE='MyDB_data_1',FILEGROUP='file_group1',FILE='MyDB_data_2',FILEGROUP='file_group2'TOMyDB_1RESTOREDATABASEMyDBFILE='MyDB_data_1',FILEGROUP='file_group1',FILE='MyDB_data_2',FILEGROUP='file_group2'FROMMyDB_1WITHNORECOVERY备份策略文件备份BACKUPDATABASEMyDBR恢复到即时点可以通过只恢复在事务日志备份内特定即时点之前发生的事务来恢复到即时点，而不用恢复整个备份backupset表在事务日志中插入命名标记以恢复到特定的标记logmarkhistory表RESTOREDATABASEMyDBFROMMyDBWITHNORECOVERYRESTORELOGMyDBFROMMyDB_log1

WITHRECOVERY,STOPAT='Jul1,200310:00AM'恢复到即时点可以通过只恢复在事务日志备份内特定即时点之前发恢复模型简单恢复允许将数据库恢复到最新的备份数据库备份+差异备份（可选）完全恢复允许将数据库恢复到故障点状态数据库备份+差异备份（可选）+事务日志备份大容量日志记录恢复(BCM)允许大容量日志记录操作（SELECTINTO，bcp，BULKINSERT）数据库备份+差异备份（可选）+事务日志备份恢复模型简单恢复恢复模型切换恢复模型可以将数据库从一个恢复模型切换到另一个恢复模型，以满足不断变化的业务要求例如，如果系统需要完全的可恢复性，可以在装载和索引操作的过程中，将数据库的恢复模型更改到批量日志记录模型，然后再返回到完全恢复切换恢复模型：ALTERDATABASE<database_name> SETRECOVERY[FULL|BULK_LOGGED|SIMPLE]查看当前数据库所使用的恢复模型：SELECTDATABASEPROPERTYEX('<database_name>','recovery')

恢复模型切换恢复模型切换恢复模型：2.2数据库恢复日志日志文件是以事务为单位用来记录数据库的每一次更新活动的文件，由系统自动记录日志内容包括：记录名、旧记录值、新记录值、事务标识符、操作标识符等事务Ti开始时，写入日志：<Tistart>事务Ti执行write(X)前，写入日志：<Ti,X,V1,V2>，V1是X更新前的值，V2

是X更新后的值事务Ti结束后，写入日志：<Ti

commit>2.2数据库恢复日志数据库恢复T0: read(A) T1

: read(C) A:=A-50

C:=C-100 Write(A) write(C) read(B) B:=B+50 write(B)<T0

start><T0

A,1000,950><T0,B,2000,2050><T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600><T0start><T0,A,1000,950><T0,B,2000,2050><T0commit><T1start><T1,C,700,600><T1commit>(a)(b)(c)数据库恢复T0: read(A) T1: rea数据库恢复延迟更新技术通过在日志中记录所有数据库修改，而将一个事务的所有write操作拖延到事务部分提交时才执行一旦日志记录都写到了稳定存储器上，就真正执行更新，并且事务进入提交状态延迟更新技术只需要数据项的新值<T0

start><T0

A,950><T0,B,2050><T0start><T0,A,950><T0,

B,2050><T0

commit><T1start><T1,C,600><T0start><T0,A,950><T0,B,2050><T0commit><T1start><T1,C,600><T1commit>(a)(b)(c)数据库恢复延迟更新技术<T0start><T0start数据库恢复延迟更新技术<T0

start><T0

A,950><T0,B,2050><T0start><T0,A,950><T0,

B,2050><T0

commit><T1start><T1,C,600><T0start><T0,A,950><T0,B,2050><T0commit><T1start><T1,C,600><T1commit>(a)(b)(c)不必做任何redo操作删除日志Redo(T0)删除T1日志Redo(T0)Redo(T1)数据库恢复延迟更新技术<T0start><T0start数据库恢复立即更新技术允许数据库修改在事务仍处于活跃状态时就输出到数据库中。活跃事务所作的数据修改称为未提交修改必须遵守先写日志的原则先写日志的原则（WAL）对于尚未提交的事务，在将DB缓冲区写到外存之前，必须先将日志缓冲区内容写到外存去日志记录将要发生何种修改写入DB表示实际发生何种修改如果先写DB，则可能在写的中途发生系统崩溃，导致内存缓冲区内容丢失，而外存DB处于不一致状态，由于日志缓冲区内容已破坏，导致无法对DB恢复数据库恢复立即更新技术数据库恢复先写DB<T0

start><T0

A,1000,950>A=950B=2050故障发生点<T0

start><T0

A,1000,950>

A=1000B=2050故障恢复后先写日志<T0

start><T0

A,1000,950><T0,B,2000,2050>A=950B=2000故障发生点<T0

start><T0

A,1000,950><T0,B,2000,2050>

A=1000B=2000故障恢复后数据库恢复先写DB<T0start>A=950故障发生点<数据库恢复日志缓冲区数据库缓冲区日志数据库WAL调入B2输出B1输出所有与B1有关的日志记录输出B1调入B2同步(synchronous)写日志：只有事务的相关日志已经完全在磁盘上了，才会向进程发送该事务已提交的确认消息异步(asynchronous)写缓冲区：只需要将数据页的写入操作投递给操作系统即可，不需要等待其完成数据库恢复日志缓冲区数据库缓冲区日志数据库WAL调入B2输出数据库恢复事务分类圆满事务日志文件中记录了事务的commit标识夭折事务日志文件中只有事务的Begintransaction标识，无commit<T0

start><T0

A,1000,950><T0,B,2000,2050>T0夭折事务<T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600>T0圆满事务，T1夭折事务<T0start><T0,A,1000,950><T0,B,2000,2050><T0commit><T1start><T1,C,700,600><T1commit>T0圆满事务，T1圆满事务数据库恢复事务分类<T0start>T0夭折事务<T0s数据库恢复基本的恢复操作对圆满事务所做过的修改操作应执行redo操作，即重新执行该操作，修改对象被赋予新记录值

redo=redo2对夭折事务所做过的修改操作应执行undo操作，即撤消该操作，修改对象被赋予旧记录值

undo=undo2undo<T0

A,1000,950>A=1000redo<T0

A,1000,950>A=950数据库恢复基本的恢复操作undo<T0A,1000,数据库恢复事务故障恢复撤消事务已对数据库所做的修改措施反向扫描日志文件，查找该事务的更新操作对该事务的更新操作执行逆操作，即将事务更新前的旧值写入数据库继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理如此处理下去，直至读到此事务的开始标识，事务的故障恢复就完成了数据库恢复事务故障恢复数据库恢复<T0

start><T0

A,1000,950><T0,B,2000,2050>A=950B=2000故障发生点<T0

start><T0

A,1000,950>undo<T0,B,2000,2050>A=950B=2000故障恢复1<T0

start>undo<T0

A,1000,950><T0,B,2000,2050>

A=1000B=2000故障恢复2<T0

start><T0

A,1000,950><T0,B,2000,2050>

A=1000B=2000故障恢复结束数据库恢复<T0start>A=950故障发生点<T0s数据库恢复反向撤销事务操作<T0,A,1000,950><T0,A,950,900>A=950故障发生点<T0,A,1000,950>undo<T0,A,950,900>

A=950正向撤销事务操作undo<T0,A,1000,950><T0,A,950,900>A=1000undo<T0,A,1000,950><T0,A,950,900>A=1000<T0,A,1000,950>undo<T0,A,950,900>A=950数据库恢复反向撤销事务操作<T0,A,1000,950数据库恢复系统故障恢复不一致状态原因未完成事务对数据库的更新已写入数据库已提交事务对数据库的更新未写入数据库措施正向扫描日志文件，找出圆满事务，记入重做队列；找出夭折事务，记入撤消队列反向扫描日志，对撤消队列中事务Ti的每一个日志记录执行undo操作正向扫描日志文件，对重做队列中事务Ti的每一个日志记录执行redo操作数据库恢复系统故障恢复数据库恢复<T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600>T0圆满事务，T1夭折事务<T0start>redo<T0,A,1000,950>redo<T0,

B,2000,2050><T0

commit><T1start>undo<T1,C,700,600>A=950,B=2050,C=700数据库恢复<T0start>T0圆满事务，T1夭折事务<T数据库恢复介质故障恢复磁盘上数据文件和日志文件遭到破坏措施装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态装入相应的日志文件副本，重做已完成的事务TaTbTf正常运行介质故障恢复转储运行事务故障发生点重装后援副本利用日志文件恢复事务继续运行数据库恢复介质故障恢复TaTbTf正常运行介质故障恢复转储运检查点(Checkpoint)问题当系统故障发生时，我们必须搜索整个日志，以决定哪些事务需要redo，哪些需要undo大多数需要被重做的事务其更新已经写入了数据库中（redo2）。尽管对它们重做不会造成不良后果，但会使恢复过程变得更长检查点原理保证在检查点时刻日志与数据库内容是一致的检查点(Checkpoint)问题保证在检查点时刻日志与数据检查点带有检查点记录的日志生成将当前日志缓冲区的所有日志记录写入稳存中在日志文件中写入一个检查点记录将当前数据缓冲区的所有数据记录写入稳存中输出检查点时活跃事务的列表L检查点故障点无须REDOREDOREDOUNDOUNDO检查点带有检查点记录的日志生成检查点故障点无须REDOREDSQLServer：最小恢复LSNMinLSN是下面这些LSN中的最小LSN：检查点起点的LSN最旧的活动事务起点的LSNLSN141LSN142LSN143LSN144LSN145LSN146LSN147LSN148开始Tran1开始Tran2更新Tran2检查点更新Tran1提交Tran1检查点更新Tran2SQLServer：最小恢复LSNMinLSN是下面这些LSQLServer：生成检查点将标记检查点起点的记录写入日志文件将为检查点记录的信息存储在检查点日志记录链内。将这条链起点的LSN写入数据库根页将最小恢复LSN(MinLSN)保存在检查点记录中将所有未完成的活动事务列表保存在检查点记录中如果数据库使用的是简单恢复模式，则删除新的MinLSN之前的所有日志记录将所有脏日志和数据页写入磁盘将标记检查点末端的记录写入日志文件SQLServer：生成检查点将标记检查点起点的记录写入日SQLServer：生成检查点检查点线程遍历缓冲区池，按照缓冲区编号顺序扫描页面，当它发现脏页时，它将查看与该页面物理(磁盘上)连续的其他页面是否也是脏的，这样它可以进行大块写操作如果它看到页面5是脏的时，它可能会写入页面10、25、380、500等，这些页面在磁盘上是连续的，尽管它们在缓冲区内相去甚远。这样，缓冲区中非连续的页面可以被一次聚集写入(gather-write)磁盘(它是借助于WindowsNT的Win32函数WriteFileGather实现的)以后检查点会到达页面500，为避免将该页面重复写入磁盘，检查点算法会为每个页面设置标志位，开始时所有的位都相同(都为0或1)。当检查点检查到某个页面时，它将其标志位翻转。如果检查点碰到具有相反位的页面，它就跳过该页面对于在检查点期间新近引入的页面，或者已经被检查点输出到磁盘但又重新变脏的页面，都不会被该次检查点操作写入SQLServer：生成检查点检查点线程遍历缓冲区池，按照SQLServer：生成检查点recoveryinterval选项设置SQLServer恢复数据库所需的最大分钟数，默认值为0，表示每个数据库的恢复时间不超过1分钟据此SQLServer将估计在恢复时间间隔期间可以处理多少更新的数据，从而决定在每一个数据库中SQLServer何时生成一次检查点。实际中，SQLServer根据10MB的日志可以在1分钟内得到恢复这样一个估计来确定它的恢复间隔一个数据库中，当最近一个检查点之后数据更新操作达到了SQLServer认为可以在恢复时间间隔更新的数量时，SQLServer将进行一个检查点操作SQLServer：生成检查点recoveryinterSQLServer：生成检查点SQLServer自动生成检查点的时间间隔基于日志内的记录数而非时间。如果数据库只做了很少的修改，自动检查点的时间间隔就长。如果修改了大量数据，自动检查点将经常发生检查点间隔取决于recoveryinterval配置以及数据库使用的恢复模式每当日志记录数达到SQLServer估计在recoveryinterval选项所指定的时间内能处理的记录数时，就生成自动检查点如果数据库使用的是简单恢复模式，则当日志的70%已满，就生成自动检查点，以截断日志并释放空间。但如果没有空间可以被释放，则不生成检查点SQLServer：生成检查点SQLServer自动生成SQLServer：事务日志物理构架每个物理日志文件分成许多虚拟日志文件事务日志是回绕的日志文件。当创建数据库时，逻辑日志从物理日志文件的始端开始。在逻辑日志的末端添加新的日志记录，逻辑日志就向物理日志末端增长当逻辑日志的末端到达物理日志文件的末端时，新的日志记录绕回物理日志文件的始端。这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端从MinLSN到日志末端的日志文件部分称为日志的活动部分。这是进行数据库完全恢复所需的日志部分永远不能截断活动日志的任何部分。所有的日志截断都必须从MinLSN之前的日志部分进行。发生截断操作时，删除MinLSN之前的虚拟日志内的记录SQLServer：事务日志物理构架每个物理日志文件分成许SQLServer：事务日志物理构架虚拟日志1虚拟日志2虚拟日志3虚拟日志4虚拟日志5被截断未使用逻辑日志的始端逻辑日志的末端MinLSN最后一个检查点虚拟日志1虚拟日志2虚拟日志3虚拟日志4被截断逻辑日志的始端逻辑日志的末端MinLSN最后一个检查点倒数第二个检查点SQLServer：事务日志物理构架虚拟日志1虚拟日志2虚逻辑Undo日志一般恢复技术要求一旦事务更新了一个数据项，其它事务都不能更新该数据项，直至第一个事务提交或回滚严格两阶段封锁协议实施到某些特殊结构如B+树索引页时，并发性极度下降。为提高并发性，可以使用非两段方式使锁较早释放如果事务T向B+树插入了一项，在插入操作结束后但在事务提交前释放了某些锁。在锁释放后，其它事务可执行插入或删除操作，于是造成对B+树结点的进一步改变如果使用物理undo执行事务回滚，即事务回滚时我们将B+