下载文档原格式
数据库的并发控制技术数据库是现代信息系统中最关键的数据存储和管理工具之一。
在数据库系统中，同时可能存在多个用户并发地执行事务。
并发是提高数据库系统性能和资源利用率的重要手段，但也会带来数据一致性和并发竞争的问题。
为了解决这些问题，数据库必须采用适当的并发控制技术。
并发控制技术是数据库系统中保证多个并发事务正确执行的机制。
其目标是确保数据库的一致性、完整性和隔离性，同时提高并发事务处理效率。
常见的并发控制技术包括锁定、时间戳和多版本并发控制。
第一种常见的并发控制技术是锁定机制。
锁定在数据库系统中起到保护数据完整性和隔离事务的作用。
当一个事务需要修改或者读取某个数据时，它必须先获得一个锁。
可以使用两种类型的锁：共享锁和排他锁。
共享锁（S锁）允许其他事务读取数据，但不允许修改；排他锁（X锁）则不允许其他事务读取或修改数据。
通过给数据对象加锁，可以避免多个事务对同一数据的冲突修改。
第二种常见的并发控制技术是时间戳。
时间戳是指给每个事务分配一个唯一的时间戳，并使用这个时间戳作为判断读取和修改操作是否可以并发执行的依据。
每个事务执行读取操作时，检查其他事务是否已经修改了它所需要读取的数据。
如果有冲突，可以根据时间戳的先后顺序决定是否执行。
时间戳可以避免死锁和冲突问题，提高并发处理效率。
第三种常见的并发控制技术是多版本并发控制（MVCC）。
多版本并发控制通过维护不同版本的数据来避免读取和写入操作的冲突。
每个事务读取的数据都是当前版本的数据快照，而写操作会创建一个新的版本。
其他事务仍然可以读取旧版本的数据，并且不会受到正在进行的写操作的影响。
多版本并发控制提供了更好的并发性和隔离性，并减少了锁定的粒度和冲突的可能性。
除了以上常见的并发控制技术，还有其他一些特殊的技术。
例如，乐观并发控制（OCC）假设冲突很少发生，并在事务提交时检查冲突。
如果没有冲突，则事务提交成功，否则会进行回滚。
快照隔离级别（Snapshot Isolation）允许事务读取一致性的快照数据，而不会被其他并发事务的修改所影响。
数据库事务的隔离级别与并发控制在数据库管理系统中，事务的隔离级别和并发控制是确保数据完整性和一致性的重要手段。
隔离级别定义了事务之间的可见性，而并发控制则管理并发执行事务的方式。
本文将详细介绍数据库事务的隔离级别和并发控制。
一、事务的隔离级别1. 未提交读（Read Uncommitted）未提交读是最低的隔离级别，事务对其他事务所做的修改可以立即可见。
这会导致脏读（Dirty Read）问题，即读取到了尚未提交的数据，容易造成数据不一致。
2. 提交读（Read Committed）提交读是较低的隔离级别，事务只能读取已经提交的数据。
这避免了脏读，但可能会导致不可重复读（Non-Repeatable Read）问题，即在同一个事务中，两次读取同一个数据的结果不一致。
3. 可重复读（Repeatable Read）可重复读是较高的隔离级别，事务在执行期间多次读取同一个数据得到的结果是一致的。
这避免了脏读和不可重复读，但可能会导致幻读（Phantom Read）问题，即在同一个事务中多次执行相同的查询，结果集却发生了变化。
4. 串行化（Serializable）串行化是最高的隔离级别，事务串行执行，保证了数据的完全一致性。
但这会导致并发性能降低，因为每次只有一个事务能够同时执行。
二、并发控制的方法1. 锁机制锁机制是最基本的并发控制方法之一，通过给数据或资源加锁来实现对并发访问的控制。
常见的锁类型有共享锁和排它锁，共享锁允许多个事务并发读取数据，而排它锁则只允许一个事务独占访问数据。
2. 并发控制算法并发控制算法包括多版本并发控制（MVCC）、时间戳排序和两段锁协议等。
这些算法通过在数据中维护版本信息、时间戳或锁状态来实现事务的并发控制。
不同的算法适用于不同的场景，具体的选择需要根据实际需求和性能考虑。
3. 乐观并发控制乐观并发控制是一种无锁的并发控制方法，通过版本号或时间戳等机制来检测并发冲突并解决。
数据库日志的管理与监控数据是当代企业不可或缺的重要资产之一，因此，数据库日志的管理与监控变得至关重要。
数据库日志是记录数据库系统运行情况的重要组成部分，它可以帮助确保数据的完整性、一致性和安全性。
本文将讨论数据库日志的管理与监控的重要性，以及一些常用的管理和监控方法。
首先，让我们先了解一下数据库日志的基本概念。
数据库日志是一种记录数据库系统中所发生的所有事务操作的文件。
它记录了每个事务的开始和结束时间、所执行的SQL语句、所涉及的数据对象以及事务对数据库的影响。
通过分析数据库日志，管理员可以回溯每个事务的执行历史、还原数据的变更过程，并在需要的时候进行恢复或回滚操作。
数据库日志的管理与监控对于保证数据的完整性和安全性至关重要。
通过合理设置数据库日志的管理策略，可以确保数据库系统的正常运行，并对意外故障和数据损坏做出及时响应和恢复。
此外，监控数据库日志的实时性和完整性可以提前发现问题，并及时采取相应的措施进行处理，从而降低系统风险和减少潜在的数据丢失。
基于以上背景，下面将介绍一些常用的数据库日志管理与监控方法。
1. 定期备份和归档日志定期备份和归档数据库日志是数据库管理的基础工作之一。
通过定期备份和归档日志文件，可以确保在系统故障或意外损坏时能够迅速恢复数据。
同时，备份和归档操作还可以释放磁盘空间，保证数据库系统的高效运行。
2. 设置日志文件大小和数量限制在数据库系统中，可以设置日志文件的大小和数量限制，以避免过度增长和占用过多磁盘空间。
当日志文件达到一定大小或数量时，数据库系统将自动创建新的日志文件，并将旧的日志文件进行归档或删除。
通过设置限制，可以有效管理日志文件，提高系统运行效率。
3. 监控日志空间利用率监控日志空间利用率是及时了解数据库日志文件使用情况的重要手段。
通过监控日志空间利用率，管理员可以及时发现日志空间不足的情况，并及时采取措施释放或扩充空间，以避免数据库系统因为日志文件空间不足而停止运行或出现故障。
数据库事务隔离级别与并发控制详解随着数据库的广泛应用，对于数据库事务隔离级别和并发控制的需求也越来越高。
为了保证数据库的数据一致性和可靠性，数据库系统采用了事务隔离级别和并发控制机制。
本文将详细介绍数据库事务隔离级别和并发控制的概念和原理，以及不同隔离级别的特点和应用场景。
首先，我们来了解什么是事务隔离级别。
事务隔离级别指的是多个事务同时运行时彼此之间的影响程度，它提供了一种机制来控制事务的隔离程度，以确保事务在并发环境下执行的可靠性。
数据库管理系统定义了四个标准的事务隔离级别，分别为读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。
读未提交是最低级别的隔离级别，它允许一个事务读取到另一个事务尚未提交的数据。
这个隔离级别最容易导致脏读（Dirty Read）问题，即一个事务读取到了由另一个未提交事务所修改的数据。
读已提交是数据库系统的默认隔离级别，它保证一个事务读取到的数据是已经提交的数据，解决了脏读的问题。
但是读已提交隔离级别可能导致不可重复读（Non-repeatable Read）的问题，即一个事务多次读取同一数据时，得到的结果不一致。
为了解决不可重复读的问题，可重复读隔离级别引入了额外的机制。
在该隔离级别下，一个事务多次读取同一数据时，会得到一致的结果，即使其他事务修改了该数据。
可重复读隔离级别解决了不可重复读的问题，但依然可能导致幻读（Phantom Read）的问题。
幻读指的是在一个事务中的两次查询过程中的数据行的数量发生了不一致的情况。
最高级别的事务隔离级别是串行化，该级别通过对事务进行加锁的方式来实现隔离。
串行化隔离级别确保所有事务按照顺序依次执行，避免了脏读、不可重复读和幻读的问题。
但是串行化的隔离级别会导致系统的并发性能大幅下降，因此在实际应用中很少使用。
除了事务隔离级别，数据库还需要采取并发控制的措施来保证事务的并发执行安全可靠。
数据库系统（下）：管理与技术_哈尔滨工业大学中国大学mooc课后章节答案期末考试题库2023年1.DBMS管理数据库缓冲区有四种策略：No Steal, Steal, No Force, Force。
则效率较低但不会出现问题的策略组合是_________，而效率最高最常用但会出现问题的策略组合是_________。
参考答案:No Steal+ Force，Steal + No Force；2.下列说法正确的是___________。
参考答案:两阶段封锁法是可串行化的并行调度算法；3.T1，T2是两个事务，图(a)(b)给出这两个事务的两种调度S1，S2，关于S1，S2，说法正确的选项是_____________。
【图片】参考答案:S1是不可串行化调度，S2是可串行化调度；4.若事务T对数据M已加S锁，在不改变S锁的情况下，则其它事务对数据M__________。
参考答案:可以读，但不可以写；5.关于稀疏索引和稠密索引，下列说法正确的是_______。
参考答案:如果一个搜索码的值在稠密索引中不存在，则在主文件中对应该搜索码值的记录也不存在6.关于给出的九个关系代数操作：【图片】问任何时候都能够用一趟算法实现的操作的个数是_______。
参考答案:17.主索引通常确定“表”数据的__________。
参考答案:物理顺序8.有效性确认是一种并发控制方法。
如下图(a)(b)中T和U是两个事务，X和Y是数据对象。
T要进行有效性确认，下列说法正确的是__________。
【图片】参考答案:图(a)事务T的有效性可以确认；图(b)事务T的有效性不可以确认；9.关于基于散列的两趟算法，下列说法正确的是_______。
参考答案:第一趟散列的目的是使数据子集具有某一种特性(如具有相同的散列值)，而第二趟散列的目的是提高数据处理的速度。
10.关于逻辑查询优化和物理查询优化，下列说法正确的是________。
参考答案:逻辑查询优化是关系代数操作次序的优化；物理查询优化是关系代数操作实现算法选择的优化11.关于B+树，下列说法不正确的是_________。
数据库事务管理与并发控制数据库事务管理和并发控制是数据库管理系统中两个关键的概念。
数据库事务是指一组数据库操作（例如插入、更新或删除数据）被视为一个不可分割的单元，要么全部执行成功，要么全部回滚至最初状态。
并发控制则是指对于多个并发事务的处理，保证各个事务的执行顺序和结果的一致性。
一、数据库事务管理1. 事务的特性事务具有四个特性，即ACID特性：- 原子性（Atomicity）：事务中的操作要么全部成功，要么全部回滚，不存在部分成功的情况。
- 一致性（Consistency）：事务执行后，数据库的状态应满足预期的一致性约束，不会破坏数据库的完整性。
- 隔离性（Isolation）：多个事务并发执行时，每个事务都应该感知不到其他事务的存在，各事务之间不能互相干扰。
- 持久性（Durability）：事务一旦提交，其结果应该永久保存在数据库中，即使发生系统故障也不会丢失。
2. 事务的操作事务的操作通常包括开始事务（BEGIN）、提交事务（COMMIT）和回滚事务（ROLLBACK）三个关键操作。
开始事务用于标识一个新的事务的开始，提交事务用于将事务中的操作永久保存到数据库中，回滚事务则是将事务中的操作全部撤销。
3. 事务隔离级别事务隔离级别决定了并发事务之间的可见性和互相干扰程度。
常见的隔离级别包括：- 读未提交（Read Uncommitted）：事务中的修改可被其他事务读取。
- 读已提交（Read Committed）：只有事务提交后的修改才能被其他事务读取。
- 可重复读（Repeatable Read）：确保事务执行期间数据的一致性，事务读取的数据不会受其他事务的修改影响。
- 串行化（Serializable）：最高的隔离级别，保证任何两个事务都不会同时执行。
二、并发控制1. 并发带来的问题并发执行多个事务可能导致数据的不一致性问题，例如脏读、不可重复读和幻读。
为了解决这些问题，需要进行并发控制。
分布式数据库系统中的事务管理与并发控制随着云计算和大数据时代的到来，分布式数据库系统已经成为了处理大规模数据的关键技术之一。
在分布式数据库系统中，事务管理和并发控制是至关重要的问题。
本文将探讨分布式数据库系统中的事务管理和并发控制的挑战和解决方案。
1. 事务管理事务是指数据库操作的逻辑单元，具有原子性、一致性、隔离性和持久性（ACID）四个特性。
在分布式数据库系统中，事务管理面临着多个节点间的通信和协调问题。
为了确保分布式数据库中的事务能够正确执行和恢复，需要采取一系列的策略和机制。
首先，分布式数据库系统中的事务管理需要保证所有节点执行的操作是原子的。
为了实现原子性，可以使用两阶段提交（Two-phase Commit，2PC）协议。
在2PC协议中，事务的提交需要经过两个阶段，首先进行准备阶段，所有节点需要决定是否可以提交事务，然后进行提交阶段，所有节点同时提交或回滚事务。
2PC协议可以确保所有节点在提交事务时的一致性。
其次，分布式数据库系统中的事务管理需要保证事务的隔离性。
由于分布式数据库系统中存在多个节点并行执行事务的情况，可能会出现读-写和写-写冲突。
为了解决这些冲突，可以使用并发控制机制。
常见的并发控制方法包括基于锁的机制和基于时间戳的机制。
基于锁的机制通过给予事务锁来确保事务的隔离性，而基于时间戳的机制则通过为每个事务分配时间戳来判断事务的顺序和冲突。
最后，分布式数据库系统中的事务管理需要保证事务的持久性。
持久性是指事务一旦提交，对数据库的修改就会永久保存。
为了实现持久性，可以使用日志恢复机制。
在分布式数据库系统中，每个节点都会维护一个本地日志，用于记录事务的操作。
在事务提交后，可以将这些日志复制到其他节点，以确保数据的持久性。
此外，还可以使用备份机制来保证数据的备份和恢复。
2. 并发控制并发控制是指多个事务并行执行时的冲突和一致性问题。
在分布式数据库系统中，由于节点之间的通信延迟和数据复制，事务并发控制面临更大的挑战。
6、事务管理与并发控制学习笔记——数据库的三种日志详解6.1、概念：acid性质、共享锁、排它锁6.1.1 事务的ACID特性A：表示事务的原子性(Atomicity)，即事务完全执行或完全不执行–事务中包含的所有操作要么全做，要么全不做原子性由恢复机制实现C：表示一致性(Consistency)，所有数据库都有一致性约束，或关于数据之间联系的预期状态–事务的隔离执行必须保证数据库的一致性。
事务开始前，数据库处于一致性的状态；事务结束后，数据库必须仍处于一致性状态。
–数据库的一致性状态由用户来负责，由并发控制机制实现。
如银行转帐，转帐前后两个帐户金额之和应保持不变I：表示隔离(Isolation),即表面看起来，每个事务都是在没有其它事务同时执行的情况下执行的–系统必须保证事务不受其它并发执行事务的影响。
对任何一对事务T1，T2，在T1看来，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行–隔离性通过并发控制机制实现D：表示持久性(Durability)，即一旦事务完成了，事务对数据库的影响就不会丢失–一个事务一旦提交之后，它对数据库的影响必须是永久的–系统发生故障不能改变事务的持久性。
持久性通过恢复机制实现这里大家要知道，事务是我们对数据库操作的执行单位。
我们要注意事务的整体性，即原子性，事务是绝对不能做一半的，否则很难保证数据库的一致性。
而对于数据库来说，必须要保证一致性，因为一个数据库如果没有一致性，那么这个数据库是失败的！隔离性是数据库并发处理性能的体现，当然如果数据库没有很好的并发性那么你还是改用Excel吧，呵呵，开个玩笑而已。
6.2、三种日志例题系统是很可能崩溃的，但是崩溃后我们不能坐以待毙，我们要保证事务的原子性，进而保证数据库的一致性和持久性。
那么我们就应该考虑怎样建立一个合理的运行机制，让系统崩溃后能够通过一系列办法将那些不能确定是否真正写盘的事务回滚或者重做，哪怕数据库回到之前好久的状态。
还好，高手们很有正事，他们研究出来一些针对故障的恢复机制！也就是我们下面要说到的日志系统！6.2.1 日志与故障恢复数据库系统（例如Oracle）一般都有一个日志系统，它由日志管理服务和日志文件组成，这个如果大家有兴趣复习一下Oracle的体系架构，这里就不多说了。
这个日志文件中存储的是一些文本行，当我们对一个数据库中的数据进行操作时，数据库系统首先按照一定的规则将你的操作命令和一些附加参数记录到这些日志文件中，（注意记录的只是命令语句、参数和一些标记等等）。
然后再对数据库中的数据进行操作，最后完成所有操作后，再写一些标志到日志文件中。
根据对日志文件的管理规则的不同（对应的恢复机制也不同。
），我们现在常用的是Undo、Redo还有Undo/Redo三种日志模式。
注意：在故障恢复里我们只对数据库的写操作感兴趣，因为读操作根本不会改变数据库中的任何数据，我们还恢复个什么劲。
Undo日志：这个Undo日志的基本思想是：在日志文件的记录序列中，先记录事务的操作命令、操作对象和对象的原值（旧值），然后再真正的操作（写）数据库，全部操作成功后，再在日志文件中写上事务的提交（commit）记录。
这样，如果一旦系统崩溃了，我们打开日志文件，如果看到了一个事务提交记录，我们就认为这个事务已经对数据库操作完了（已经写入数据库了），我们就完全不用理它了，但是如果日志文件中的一个事务没有提交记录，我们有理由认为这个事务还没来得及写盘或者没有写全，有可能写个半拉咔叽，这个不符合事务的原子性。
那么我们需要将未提交的事务回滚（恢复旧值），最后在日志中写上这个事务的Abort 记录，告诉系统这个事务回滚了。
看下图，画红色横线的操作是写数据库的操作，这个事务比较简单，如果这个事务写库所涉及的记录很多，那么这部分操作可能相当费时，如果这时系统崩溃，那么我们完全可以根据日志判定事务在内存中已经完成，但是因为没有commit标记,说明写库操作很可能没有全部完成！看看吧，日志的作用体现出来了吧！注意：这里就是因为commit标记是在数据库操作完成后才写入日志文件的，所以，我们可以肯定如果有commit标记就说明这个事务对数据库的写操作已经完全完成了！反之则无法确定，所以我们只好回滚，恢复到原来的状态！！大家可以发现Undo日志必须在数据库的写操作全部完成后才能在日志中写commit记录，这可能需要很长的时间，一旦发生故障，恢复工作量可能很大……Redo日志：数据库的武林高手们又搞了一个Redo日志，与Undo的思想相反，这个日志是先记录事务的操作命令、操作对象和对象的新值，然后立即写commit标记，完后才真正的写数据库。
那么我们理所当然的会想到，如果系统崩溃了，在日志中一旦看到commit标记就说明我们准备写盘了，但是我们无法确定是否完全写入成功，所以在恢复时，我们干脆就再写一次新值，把已经commit的事务重新做一遍，而那些没有commit标记的事务我们根本不用理睬，因为崩溃前我们压根还没决定去写盘呢，可以肯定这些事务没有写入任何新的数据。
这个就不上图了！Undo/Redo日志：这个日志根本不用讲了，因为是Undo日志和Redo日志的组合嘛。
两种日志的优点全有了。
而且先写盘还是先打commit标记就无所谓了。
当然操作数据库之前需要在日志中记录对象的原值和新值。
恢复起来也蛮“简单”的，先Undo 后Redo。
至于具体怎么恢复，我们一会再研究。
检查点：（日志系统中非常重要的一个技术，必须要说）首先声明一下检查点在三种日志中都可以用，高手们引入检查点不是为了难为同学们，呵呵。
其实大家也发现了，系统一旦崩溃，在恢复时我们不管用Undo 还是Redo日志都需要追溯到很久以前的日志，这个太可怕了，我们为什么不考虑在数据库运行期间定时的去写写盘，然后在日志中做个标记，告诉数据库在标记前的数据已经完全写盘了，以后恢复时不用查看之前的了。
其实这样做的效果确实非常好。
具体来说就是定时插入检查点的开始标记，在附加参数中记录未完成的事务列表，（当然检查点之后允许新事务的产生），然后根据日志类型的不同，进行不同操作，最后打个检查点结束标记。
当然如果在打检查点结束标记前系统崩溃了，那么这个检查点就没有用了，因为我们还是不知道这个检查点所进行的写盘操作是否完全完成了，我们就当没有这个检查点！！（注意：上面说的是非静止检查点，没说静止检查点，因为静止检查点很简单，它先让数据库停止产生新的事务，然后等待所有已经存在的事务完成，全部完成后再写入数据库，全部写完后，在日志中打检查点结束标记，最后再让数据库重新开始接受新事务，这个很不好！）好了，三种日志以及检查点都说完了，我们开始研究根据这些日志的恢复工作的具体做法吧。
Undo日志的恢复方法：前面说过了Undo日志的原理，那么恢复起来就很简单了，系统崩溃后重新启动数据库，然后有专门的恢复管理器打开日志文件，从后向前看，看到Commit 的事务就略过，看到未commit的事务就向前找这个事务中的每条操作记录，将这些操作恢复原值，注意一定要从后向前做恢复操作，都恢复完之后将所有恢复（回滚）的事务打上一个Abort标记！具体如下：–从尾部开始扫描日志–在扫描过程中，记住所有有<COMMIT T>和<ABORT T>记录的事务T–在由尾部向后扫描的过程中，若看到有记录<T, X, v>, 则• 若T的COMMIT记录已经被扫描到，则什么也不做；• 否则，T是一个未完成的事务或被中止的事务。
必须将数据库中X的值改为v。
然后，将<ABORT T>写入磁盘。
如果有检查点的话，也很简单，先看检查点是否有chk End标记，如果没有就当没有这个检查点，如果有，那么我们只需从后扫描到检查点开始部分即可，因为既然有end标记就说明检查点开始标记前的所有事务都已经正常提交并写盘了，所以我们只需要回滚检查点开始标记之后新产生的又未提交的事务！Redo日志的恢复方法：– 1 确定已提交的事务。
– 2 从首部开始扫描日志。
对遇到的每一<T, X , v>记录：• 1）如果T是未提交的事务，则什么也不做。
• 2）如果T是提交的事务，则为数据库元素X写入值v。
– 3 对每个未完成的事务T，在日志中写入一个<ABORT T>记录并刷新日志。
如果有检查点的话，与Undo不同，因为Redo的检查点在打chk End标记时是不会等待检查点开始时仍活跃的事务的写盘的，所以这些活跃的事务（检查点开始标记后面参数中活跃事务列表中的事务）和检查点之后产生的新事务，如果它们在崩溃之前有commit记录，我们还是要Redo的。
当然如果检查点没有chk End 标记，我们根本不用理睬这个检查点！Undo/Redo日志的恢复方法：1.从后往前扫描日志，构造undo-list和redo-list–对每个形如<T i commit>的记录，将T i加入redo-list–对每个形如< T i start>的记录，如果T i不属于redo-list，则将T i加入undo-list• 2. 由后至前扫描日志，对undo-list中的每个事务T i的每一个日志记录执行undo操作–在具体实现中本步骤可以和第一步一起进行• 3. 由前至后重新扫描日志，并且对redo-list中每个事务Ti的每一个日志记录执行redo操作• 4. 对每个未完成的事务在日志Ti末尾加入<Abort T i >,Flush log 并将数据库置为正常状态如果有检查点的话,我们需要注意了，如果检查点开始时仍活跃的事务和之后新的事务在系统崩溃前没有被提交，那么我们需要回滚（Undo）他们，特别是检查点开始时仍活跃的事务，需要向前追溯到这些事务的开始；而对于这些事务如果提交了，那么很简单，只需要从检查点开始标记后进行重做（Redo），因为检查点结束后就说明所有缓冲区中的“脏数据”都写盘了！！！最后注意：Undo/Redo日志中的日志记录<T,X,v,w>中的v为Undo用的旧值，w 为Redo用的新值！不带检查点（包括检查点没有结束标记）的例子我就不举了，因为你只需要记住Undo日志的恢复方法是从后向前回滚所有未提交的事务记录<T,X,v>，Redo日志是从前向后重做所有已提交的事务记录，而Undo/Redo日志则是两种日志的操作都要做，先从后向前做Undo，然后再从前向后做Redo即可！（三种日志的恢复都别忘了最后将所有未成功的事务打上Abort记号！）现在开始举例带检查点的日志恢复：（一）带检查点的Undo日志的恢复示例：<START T1><T1,A,4><START T2><COMMIT T1><T2,B,9><START CKPT(T2)><T2,C,14><START T3><T3,D,18><T3,D,19><COMMIT T2><END CKPT>大家注意：有<END CKPT>，说明检查点有效，注意：Undo日志只关心未提交的事务，我们只需要找START CKPT之后未提交的新事务(注)，可以看到未提交的T3被我们找到了，那么先回滚<T3,D,19>，再回滚<T3,D,18>，即答案为：<D = 19><D = 18><Abort T3>（注）如果没有那条<COMMIT T2>，后面又有<END CKPT>，这在Undo日志中是不可能存在的，因为Undo日志的检查点是需要等待活跃事务列表中的所有事务（本例为T2）全部完成并写盘，而且commit后才能允许打上<END CKPT>标记的，所以我们只需找START CKPT之后未提交的新事务！（二）带检查点的Redo日志的恢复示例：<START T1><T1,A,4><START T2><COMMIT T1><T2,B,9><START CKPT(T2)><T2,C,14><START T3><T3,D,19><START T4><T4,B,2><COMMIT T4><END CKPT><COMMIT T2>大家注意：有<END CKPT>，说明检查点有效，注意：Redo日志只关心已提交的事务，所以T3我们只需要写个Abort。
