事务管理与并发控制学习笔记数据库的三种日志详解.docVIP

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标记，完后才真正的写数据库。那么我们理所当然的会想到，如果系统崩溃了，在日志中