第10章 数据恢复技术.ppt

1、数 据 库 概 论 与 技 术数据恢复技术,汤 娜 中山大学计算机科学系 ,1 数据库恢复概述 2 故障的种类 3 数据存储结构 4 恢复的实现技术 5 恢复策略 6 具有检查点的恢复技术 7 数据库镜像 8 小结,数据库恢复技术,数据库恢复概述,事务,事务(Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位 事务的ACID特性： 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持续性（Durability ）,数据库恢复概述,故障是不可避免的 计算机硬件故障 系统软件和应用软件的错误 操

2、作员的失误 恶意的破坏 故障的影响 运行事务非正常中断，但不会破坏数据库 破坏数据库,数据库恢复概述（续）,数据库管理系统对故障的对策 保证故障发生后，能把数据库中的数据从错误状态恢复到某种逻辑一致的状态 保证事务ACID DBMS提供恢复子系统 恢复技术是衡量系统优劣的重要指标 恢复算法 正常事务处理时，采取措施保证有足够的数据用于故障恢复 故障发生后，将数据库内容恢复到某个保证数据库一致性、原子性及持久性的状态,故障的种类,3 故障的种类,事务故障 系统故障 介质故障,一、事务故障,什么是事务故障 某个事务在运行过程中由于种种原因未运行至正常终止点就夭折了 事务故障的常见原因 输入数据有误

3、 运算溢出 违反了某些完整性限制 某些应用程序出错 并行事务发生死锁 。,事务故障的恢复,发生事务故障时，夭折的事务可能已把对数据库的部分修改写回磁盘 处理方法 预期故障： 通过在程序中加判断条件来实现。执行回滚（ROLLBACK）语句来撤销事务。 非预期的故障： 如由于死锁、运算溢出而被迫撤销的事务等，由系统来撤销事务 事务故障的恢复的本质：撤消事务（UNDO）,3 故障的种类,事务故障 系统故障 介质故障,二、系统故障,什么是系统故障 整个系统的正常运行突然被破坏 所有正在运行的事务都非正常终止 内存中数据库缓冲区的信息全部丢失 外部存储设备上的数据未受影响,系统故障的常见原因,操作系统或

4、DBMS代码错误 操作员操作失误 特定类型的硬件错误（如CPU故障） 突然停电,系统故障的恢复,清除尚未完成的事务对数据库的所有修改 系统重新启动时，恢复程序要强行撤消（UNDO）所有未完成事务 将缓冲区中已完成事务提交的结果写入数据库 系统重新启动时，恢复程序需要重做（REDO）所有已提交的事务,3 故障的种类,事务故障 系统故障 介质故障,三、介质故障,硬件故障使存储在外存中的数据部分丢失或全部丢失 介质故障比前两类故障的可能性小得多，但破坏性大得多,介质故障的常见原因,硬件故障 磁盘损坏 磁头碰撞 操作系统的某种潜在错误 瞬时强磁场干扰,介质故障的恢复,装入数据库发生介质故障前某个时刻的

5、数据副本 重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库,数据存储结构,Storage Structure,Volatile storage: does not survive system crashes examples: main memory, cache memory Nonvolatile storage: survives system crashes examples: disk, tape, flash memory, non-volatile (battery backed up) RAM Stable storage: a mythical form o

6、f storage that survives all failures approximated by maintaining multiple copies on distinct nonvolatile media,Stable-Storage Implementation,Maintain multiple copies of each block on separate disks raid 远程灾备copies can be at remote sites to protect against disasters such as fire or flooding. Failure

7、during data transfer can still result in inconsistent copies: Block transfer can result in Successful completion Partial failure: destination block has incorrect information Total failure: destination block was never updated,Stable-Storage Implementation,Protecting storage media from failure during

8、data transfer (one solution): Execute output operation as follows (assuming two copies of each block): 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 s

9、econd write successfully completes.,Stable-Storage Implementation (Cont.),Protecting storage media from failure during data transfer (cont.): Copies of a block may differ due to failure during output operation. To recover from failure: First find inconsistent blocks: Expensive solution: Compare the

10、two copies of every disk block. Better solution: Record in-progress disk writes on non-volatile storage (Non-volatile RAM or special area of disk). Use this information during recovery to find blocks that may be inconsistent, and only compare copies of these. Used in hardware RAID systems If either

11、copy of an inconsistent block is detected to have an error (bad checksum), overwrite it by the other copy. If both have no error, but are different, overwrite the second block by the first block.,Data Access,Physical blocks are those blocks residing on the disk. Buffer blocks are the blocks residing

12、 temporarily in main memory. Block movements between disk and main memory are initiated through the following two operations: input(B) transfers the physical block B to main memory. output(B) transfers the buffer block B to the disk, and replaces the appropriate physical block there.,Data Access,Eac

13、h transaction Ti has its private work-area in which local copies of all data items accessed and updated by it are kept. Tis local copy of a data item X is called xi. We assume, for simplicity, that each data item fits in, and is stored inside, a single block.,Data Access (Cont.),Transaction transfer

14、s data items between system buffer blocks and its private work-area using the following operations : read(X) assigns the value of data item X to the local variable xi. write(X) assigns the value of local variable xi to data item X in the buffer block. both these commands may necessitate the issue of

15、 an input(BX) instruction before the assignment, if the block BX in which X resides is not already in memory. 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(BX) need not immedi

16、ately follow write(X). System can perform the output operation when it deems fit.,Example of Data Access,x,Y,A,B,x1,y1,buffer,Buffer Block A,Buffer Block B,input(A),output(B),read(X),write(Y),disk,work area of T1,work area of T2,memory,x2,恢复的实现技术,恢复操作的基本原理,恢复操作的基本原理：冗余 利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正

17、确的那部分数据 恢复的实现技术：复杂 一个大型数据库产品，恢复子系统的代码要占全部代码的10%以上,4 恢复的实现技术,恢复机制涉及的关键问题 1. 如何建立冗余数据 数据转储（backup） 登录日志文件（logging） 2. 如何利用这些冗余数据实施数据库恢复,4.1 数据转储（备份）,一、什么是转储 二、转储的用途 三、转储方法,一、什么是转储,转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程。 这些备用的数据文本称为后备副本或后援副本。,二、转储方法,1静态转储与动态转储 2海量转储与增量转储 3转储方法小结,1静态转储,在系统中无运行事务时进行转储 转储开始时数据库

18、处于一致性状态。转储期间不允许对数据库的任何存取、修改活动 优点：实现简单 缺点：降低了数据库的可用性 转储必须等用户事务结束 新的事务必须等转储结束,动态转储,转储操作与用户事务并发进行 转储期间允许对数据库进行存取或修改 优点 不用等待正在运行的用户事务结束 不会影响新事务的运行 动态转储的缺点 不能保证副本中的数据正确有效,动态转储,利用动态转储得到的副本进行故障恢复 需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件 后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态,2海量转储与增量转储,海量转储: 每次转储全部数据库 增量转储: 只转储上次转储后更新过的数据 海

19、量转储与增量转储比较,3转储方法小结,转储方法分类,3 恢复的实现技术,3.1 数据转储 3.2 登记日志文件,3.2 登记日志文件,一、日志文件的内容 三、登记日志文件的原则,一、日志文件的内容,1. 什么是日志文件 日志文件(log)是用来记录事务对数据库的 更新操作的文件 2. 日志文件的格式 以记录为单位的日志文件 以数据块为单位的日志文件,日志文件的内容（续）,3. 日志文件内容 各个事务的开始标记(BEGIN TRANSACTION) 各个事务的结束标记(COMMIT或ROLLBACK) 各个事务的所有更新操作 日志文件中的一个日志记录 (log record),4. 基于记录的日

20、志文件,更新操作日志记录的内容 事务标识 操作类型（插入、删除或修改） 操作对象（记录ID、Block NO.） 更新前数据的旧值（对插入操作而言，此项为空值） 更新后数据的新值（对删除操作而言, 此项为空值）,二、登记日志文件的原则（WAL）,为保证数据库是可恢复的，登记日志文件时必须遵循两条原则 登记的次序严格按并行事务执行的时间次序 必须先写日志文件，后写数据库 写日志文件操作：把表示这个修改的日志记录 写到日志文件（在磁盘上） 写数据库操作：把对数据的修改写到数据库中,登记日志文件的原则（续）,为什么要先写日志文件 写数据库和写日志文件是两个不同的操作 在这两个操作之间可能发生故障 如

21、果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了 如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性,先写日志的原则（WAL）,日志缓冲区,数据库缓冲区,日志,数据库,WAL,调入B2 输出B1,输出所有与B1有关的日志记录 (flush log) 输出B1 调入B2,同步(synchronous)写日志：只有事务的相关日志已经完全在磁盘上了，才会向进程发送该事务已提交的确认消息 异步(asynchronous)写缓冲区：只需要将数据页的写入操作投递给操作系统即可，不需要等待其完成,利用静态转储副本进

22、行恢复,恢复策略,5 恢复策略,5.1 事务故障的恢复 5.2 系统故障的恢复 5.3 介质故障的恢复,5.1 事务故障的恢复,事务故障：事务在运行至正常终止点前被中止 恢复方法 由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改 事务故障的恢复由系统自动完成，不需要用户干预,事务故障的恢复步骤,1. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。 2. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”（Befor Image, BI）写入数据库。 插入操作， “更新前的值”为空，则相当于做删除操作 删除操作，“更新后的值”为空，则相当于做插入

23、操作 若是修改操作，则用BI 代替 AI（After Image） 3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。 4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。,事务故障恢复,反向撤销事务操作,正向撤销事务操作,5.2 系统故障的恢复,系统故障造成数据库不一致状态的原因 一些未完成事务对数据库的更新已写入数据库 一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库 恢复方法 1. Undo 故障发生时未完成的事务 2. Redo 已完成的事务 系统故障的恢复由系统在重新启动时自动完成，不需要用户干预,系统故障的恢复步骤,1.正向扫描日志文件（

24、即从头扫描日志文件） Redo队列: 在故障发生前已经提交的事务 T1, T3, T8. Undo队列:故障发生时尚未完成的事务 T2, T4, T5, T6, T7, T9 .,系统故障的恢复步骤,2. 对Undo队列事务进行UNDO处理 反向扫描日志文件，对每个UNDO事务的更 新操作执行逆操作 T2, T4, T5, T6, T7, T9 3. 对Redo队列事务进行REDO处理 正向扫描日志文件，对每个REDO事务重新 执行登记的操作 T1, T3, T8.,系统故障恢复, ,T0圆满事务，T1夭折事务,undo,A=950,B=2050,C=700,redo redo,A=950,B

25、=2000,C=700,5.3 介质故障的恢复,1. 重装数据库， 使数据库恢复到一致性状态 2. 重做已完成的事务,5.3 介质故障的恢复,恢复步骤 1. 装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。 对于静态转储的数据库副本，装入后数据库即处于一致性状态 对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，才能将数据库恢复到一致性状态。,介质故障的恢复（续）,2. 装入有关的日志文件副本，重做已完成的事务。 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新

26、后的值”写入数据库。,介质故障的恢复（续）,介质故障的恢复需要DBA介入 DBA的工作 重装最近转储的数据库副本和有关的各日志文件副本 执行系统提供的恢复命令 具体的恢复操作仍由DBMS完成,具有检查点的恢复技术,6 具有检查点的恢复技术,一、问题的提出 二、检查点技术 三、利用检查点的恢复策略,一、问题的提出,两个问题 搜索整个日志将耗费大量的时间 REDO处理：重新执行，浪费了大量时间,解决方案,具有检查点（checkpoint）的恢复技术 在日志文件中增加检查点记录（checkpoint） 增加重新开始文件 恢复子系统在登录日志文件期间动态地维护日志,二、检查点技术,检查点记录的内容 1

27、. 建立检查点时刻所有正在执行的事务清单 2. 这些事务最近一个日志记录的地址 重新开始文件的内容 记录各个检查点记录在日志文件中的地址,在检查点 维护日志文件,1.将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上。 2.在日志文件中写入一个检查点记录。 3. 将当前数据缓冲区的所有数据记录写入磁盘的数据库中。 4. 把检查点记录在日志文件中的地址写入一个重新开始文件。,建立检查点,定期 按照预定的一个时间间隔 不定期 按照某种规则，如日志文件已写满一半建立一个检查点,三、利用检查点的恢复策略,当事务T在一个检查点之前提交 T对数据库所做的修改已写入数据库 在进行恢复处理时，没有必要对事务

28、T执行REDO操作,利用检查点的恢复策略（续）,利用检查点的恢复步骤,1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址 2 由该地址在日志文件中找到最后一个检查点记录,利用检查点的恢复策略（续）,2.由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST 建立两个事务队列 UNDO-LIST REDO-LIST 把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。,利用检查点的恢复策略（续）,3.从检查点开始正向扫描日志文件，直到日志文件结束 如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列 如有提交的事务Tj，把Tj从UN

29、DO-LIST队列移到REDO-LIST队列 4.对UNDO-LIST中的每个事务执行UNDO操作, 对REDO-LIST中的每个事务执行REDO操作,思考题,一条update语句只修改一条记录，如果在前图第3步完成后down机系统重启后，是如何处理？ 一条update语句修改一万条记录，如果在修改了5000条记录后down机系统重启后，是如何处理？,数据库镜像,7 数据库镜像,介质故障是对系统影响最为严重的一种故障，严重影响数据库的可用性 介质故障恢复比较费时 为预防介质故障，DBA必须周期性地转储数据库 提高数据库可用性的解决方案 数据库镜像（Mirror）,数据库镜像（续）,数据库镜像

30、DBMS自动把整个数据库或其中的关键数据复制到另一个磁盘上 DBMS自动保证镜像数据与主数据的一致性(图5a),数据库镜像的用途,出现介质故障时 DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本(图5b) 没有出现故障时 可用于并发操作(图5a) 一个用户对数据加排他锁修改数据 其他用户可以读镜像数据库上的数据,数据库镜像（续）,数据库镜像（续）,由于采用复制数据实现镜像，而频繁复制会导致较低系统运行效率。因此实际应用只针对关键数据和日志文件进行镜像，而不是整个数据库,Advanced Recovery Algorithm,逻辑Undo日志,一般恢复技术要求一旦事务

31、更新了一个数据项，其它事务都不能更新该数据项，直至第一个事务提交或回滚 严格两阶段封锁协议实施到某些特殊结构如B+树索引页时，并发性极度下降。为提高并发性，可以使用非两段方式使锁较早释放 如果事务T向B+树插入了一项，在插入操作结束后但在事务提交前释放了某些锁。在锁释放后，其它事务可执行插入或删除操作，于是造成对B+树结点的进一步改变 如果使用物理undo执行事务回滚，即事务回滚时我们将B+树内部结点（执行插入操作前）的旧值写回，那么其它事务在其后执行的插入或删除操作所做的某些更新可能会丢失 插入操作必须通过一个逻辑undo来完成，即通过执行一次删除操作撤消,For such operatio

32、ns, undo log records should contain the undo operation to be executed called logical undo logging, in contrast to physical undo logging. Redo information is logged physically (that is, new value for each write) even for such operations Logical redo is very complicated since database state on disk ma

33、y not be “operation consistent”,Advanced Recovery Techniques (Cont.),Operation logging is done as follows: When operation starts, log . Here Oj is a unique identifier of the operation instance. While operation is executing, normal log records with physical redo and physical undo information are logg

34、ed. When operation completes, is logged, where U contains information needed to perform a logical undo information.,Advanced Recovery Techniques (Cont.),If crash/rollback occurs before operation completes: the operation-end log record is not found, and the physical undo information is used to undo o

35、peration. If crash/rollback occurs after the operation completes: the operation-end log record is found, and in this case logical undo is performed using U; the physical undo information for the operation is ignored.,Advanced Recovery Techniques (Cont.),Rollback of transaction Ti is done as follows:

36、 Scan the log backwards If a log record is found, perform the undo and log a special redo-only log record . If a record is found Rollback the operation logically using the undo information U. Log Updates performed during roll back are logged just like during normal operation execution. At the end of

37、 the operation rollback, instead of logging an operation-end record, generate a record . Skip all preceding log records for Ti until the record is found,日志类型的对比,物理日志 Ti,Xi,V1,V2 回滚时登记的日志 Ti,Xi,V1,undonextLSN,逻辑日志 Ti,Qi,operation-begin （物理日志） Ti,Qi, operation-end,U 回滚时登记的日志 （物理日志） Ti,Qi,operation-abo

38、rt,Advanced Recovery Techniques (Cont.),Scan the log backwards (cont.): If a redo-only record is found ignore it If a record is found: skip all preceding log records for Ti until the record is found. Stop the scan when the record is found Add a record to the log Some points to note: Cases 3 and 4 ab

39、ove can occur only if the database crashes while a transaction is being rolled back. Skipping of log records as in case 4 is important to prevent multiple rollback of the same operation.,Advanced Recovery Techniques(Cont,),The following actions are taken when recovering from system crash Scan log fo

40、rward from last record Repeat history by physically redoing all updates of all transactions, Create an undo-list during the scan as follows undo-list is set to L initially Whenever is found Ti is added to undo-list Whenever or is found, Ti is deleted from undo-list This brings database to state as o

41、f crash, with committed as well as uncommitted transactions having been redone. Now undo-list contains transactions that are incomplete, that is, have neither committed nor been fully rolled back.,Advanced Recovery Techniques (Cont.),Recovery from system crash (cont.) Scan log backwards, performing

42、undo on log records of transactions found in undo-list. Transactions are rolled back as described earlier. When is found for a transaction Ti in undo-list, write a log record. Stop scan when records have been found for all Ti in undo-list This undoes the effects of incomplete transactions (those wit

43、h neither commit nor abort log records). Recovery is now complete.,Advanced Recovery Techniques (Cont.),Fuzzy checkpointing allows transactions to progress while the most time consuming parts of checkpointing are in progress 正在输出到磁盘的缓冲块也不能更新，虽然其他缓冲块可以并发更新，但必须遵守先写日志协议。,ARIES算法,ARIES算法：数据结构,日志记录的基本格式

44、LSN 在增长的日志记录空间中的日志记录的第一个字节的地址。这是一个单调递增的数值，记录越晚产生，lsn值越大 Type 表示一个记录是补偿日志（compensation），正常更新记录(update)，一个提交协议相关记录（例如prepare） TransID 事务的标记，如有，则写入到日志记录中 PrevLSN 本事务的前一条日志记录的LSN。对该事务的第一条日志记录而言是0，因此，不需要用一条日志记录显式地表示一条事务的开始 PageID 只在Update和compensation类型的记录中出现，它记录本记录所所做更新的页面的标记,ARIES算法：数据结构,Data 这是描述欲更新的r

45、edo和/或undo数据。CLR只包含redo信息，因为它们不能undo UndoNxtLSN 只在CLR中出现，它指的是回滚阶段要处理的下一个本事务的日志记录，也即UndoNxtLSN是当前日志正在弥补的日志记录的PrevLSN的数值。如果已经没有日志记录需要undo，该数据域就会是0 页面结构 数据库的每个页都有page_LSN域。它包含描述对该页面所做的最近更新日志记录的LSN。在恢复的Redo阶段，LSN值小于等于page_LSN值的记录将不在这页上redo,ARIES算法：数据结构,事务表 事务表记录事务的状态 TransID：事务的ID State：事务的提交状态 LastLSN：

46、事务所写的最后一条LSN UndoNxtLSN：在回滚阶段下一个记录的LSN。如果本事务的最近日志记录是一个可undo的非CLR记录，这个字段的值就会被设为LastLSN。如果最近日志记录是CLR，此字段的值就设为此CLR的UndoNxtLSN的值,ARIES算法：数据结构,脏页表 包含一个在数据库缓冲区中已更新的列表， PageID+pageLSN+ RecLSN RecLSN用于标识日志记录，这些日志记录的磁盘页版本没有实施更新 当一页被插入到脏页表时(当他首次在缓冲池中被修改时)，RecLSN的值被设置成日志的当前末尾 只要页被写入磁盘，该页就被从脏页表中移除。 检查点日志记录 包含检查

47、点发生时脏页和活动事务的列表，同时记录每个事务的LastLSN,ARIES算法：三个原理,先写日志 在将更新的数据库对象的修改写入磁盘之前，先将对应的日志记录写入稳存 恢复修改的记录数据 在回滚某些事务时，如果出现对数据库的改变，则需要在日志中记录这些改变，保证在重复进行重新启动时不需要重复这些操作 重做时重复历史 在崩溃后进行重新启动时，重做崩溃前的所有操作，使系统恢复到崩溃时的状态，然后回滚崩溃时还在执行的事务已完成的操作,ARIES算法：三个过程,分析过程 决定哪些事务要undo，哪些页在崩溃时是脏的，以及redo应从哪个LSN开始 Redo过程 从分析过程决定的位置开始，执行一个red

48、o，重复历史，将数据库恢复到发生崩溃前的状态 Undo过程 回滚在发生崩溃时那些不完整的事务,ARIES算法：系统故障恢复,ARIES算法：分析过程,找到最后完整检查点日志记录，并从该记录开始读入脏页表 将RedoLSN设置为脏页表中页的RecLSN的最小值，如果没有脏页，就将其设置为检查点日志记录的LSN 将要被undo的事务列表undo-list设置为检查点日志记录中的事务列表及这些事务的LastLSN 从检查点继续向前扫描，每找到一个不在undo-list中的事务日志记录，就将其添加到undo-list，每找到一个事务的end日志记录，就将其从undo-list中删除,ARIES算法：R

49、edo过程,Redo过程通过重演所有没有在磁盘页上反映的动作来重复历史 Redo过程从RedoLSN开始向前扫描日志，该点之前的日志记录已经反映在磁盘数据库页上 只要Redo过程找到一个update日志记录，它就执行如下动作： 如果该页不在脏页表中(更新已经实施)，或者该update日志记录的LSN小于脏页表中该页的RecLSN（没有实施，但之后还有更新），Redo过程就跳过该日志记录 否则Redo过程就从磁盘调出该页，如果其PageLSN小于该日志记录的LSN，重做该日志记录,ARIES算法：Undo过程,Undo过程反向扫描日志，取消所有undo-list中的事务 如果找到一个CLR，它用

50、UndoNextLSN字段跳过一个已经回滚了的事务日志。否则，它用事务日志的PrevLSN字段查找下一个要被撤消的事务日志 每当一个update日志记录被用于撤消，Undo过程产生一个包含undo执行动作（必须是物理逻辑的）的CLR，并将CLR的UndoNextLSN设置为update日志记录的PreLSN值,SQL SERVER恢复技术,SQL Server：最小恢复LSN,MinLSN是下面这些LSN中的最小LSN： 检查点起点的 LSN 最旧的活动事务起点的 LSN,SQL Server：生成检查点,将标记检查点起点的记录写入日志文件 将为检查点记录的信息存储在检查点日志记录链内。将这条

51、链起点的LSN写入数据库根页 将最小恢复LSN(MinLSN)保存在检查点记录中 将所有未完成的活动事务列表保存在检查点记录中 如果数据库使用的是简单恢复模式，则删除新的MinLSN之前的所有日志记录 将所有脏日志和数据页写入磁盘 将标记检查点末端的记录写入日志文件,SQL Server：生成检查点,检查点线程遍历缓冲区池，按照缓冲区编号顺序扫描页面，当它发现脏页时，它将查看与该页面物理(磁盘上)连续的其他页面是否也是脏的，这样它可以进行大块写操作 如果它看到页面5是脏的时，它可能会写入页面10、25、380、500等，这些页面在磁盘上是连续的，尽管它们在缓冲区内相去甚远。这样，缓冲区中非连续

52、的页面可以被一次聚集写入(gather-write)磁盘(它是借助于Windows NT的Win32函数WriteFileGather实现的) 以后检查点会到达页面500，为避免将该页面重复写入磁盘，检查点算法会为每个页面设置标志位，开始时所有的位都相同(都为0或1)。当检查点检查到某个页面时，它将其标志位翻转。如果检查点碰到具有相反位的页面，它就跳过该页面 对于在检查点期间新近引入的页面，或者已经被检查点输出到磁盘但又重新变脏的页面，都不会被该次检查点操作写入,SQL Server：生成检查点,recovery interval选项设置SQL Server恢复数据库所需的最大分钟数，默认值为

53、0，表示每个数据库的恢复时间不超过1分钟 据此SQL Server将估计在恢复时间间隔期间可以处理多少更新的数据，从而决定在每一个数据库中SQL Server何时生成一次检查点。实际中，SQL Server根据10MB的日志可以在1分钟内得到恢复这样一个估计来确定它的恢复间隔 一个数据库中，当最近一个检查点之后数据更新操作达到了SQL Server认为可以在恢复时间间隔更新的数量时，SQL Server将进行一个检查点操作,SQL Server：生成检查点,SQL Server自动生成检查点的时间间隔基于日志内的记录数而非时间。如果数据库只做了很少的修改，自动检查点的时间间隔就长。如果修改了大量数据，自动检查点将经常发生 检查点间隔取决于recovery interval配置以及数据库使用的恢复模式 每当日志记录数达到SQL Server估计在recovery interval选项所指定的时间内能处理的记录数时，就生成自动检查点 如果数据库使用的是简单恢复模式，则当日志的70%已满，就生成自动检查点，以截断日志并释放空间。但如果没有空间可以被释放，则不生成检查点,SQL Server：事务日志物理构架,每个物理日志文件分成许多虚拟日志文件 事务日志是回绕的日志文件。当创建数据库时，逻辑日志从物理日志文件的始端开始。在逻辑日志的末端添加新的日志记录，逻辑日志就向物理日志末