数据库并发控制及SQLSERVER的并发控制机制.pptVIP

An Introduction to Database System 为何要并发？ 并发执行可能引起哪些问题？ 如何知道并发执行后结果是正确的？ 并发执行如何控制实现？ 第十一章 数据库并发控制及SQL Server的并发控制机制 11.1 并发控制概述 11.2 并发调度的可串行性 11.3 封锁 11.4 两段锁协议 11.5 封锁的粒度 11.6 活锁和死锁 11.7 SQL Server的并发控制机制 11.8 小结 多事务执行方式 事务串行执行 每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行 不能充分利用系统资源，发挥数据库共享资源的特点 多事务执行方式（续） 交叉并发方式（interleaved concurrency） 事务的并行执行是这些并行事务的并行操作轮流交叉运行 单处理机系统中的并发方式，能够减少处理机的空闲时间，提高系统的效率 多事务执行方式（续） 同时并发方式（simultaneous concurrency） 多处理机系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行。 事务并发执行带来的问题 可能会存取和存储不正确的数据，破坏事务的隔离性和数据库的一致性 DBMS必须提供并发控制机制 并发控制机制是衡量一个DBMS性能的重要标志之一 并发控制机制的目的 改善系统的性能，交叉利用系统资源 改善短事务的响应时间 （1）甲售票点（甲事务）读出某航班的机票余额A，设A=16。（2）乙售票点（乙事务）读出同一航班的机票余额A，也为16。（3）甲售票点卖出一张机票，修改余额A?A-1，所以A为15，把A写回数据库。（4）乙售票点卖出一张机票，修改余额A?A-1，所以A为15，把A写回数据库。 原因：并发操作破坏了事务的隔离性。 并发操作带来的数据不一致性 丢失修改（lost update） 读“脏”数据（dirty read） 不可重复读（non-repeatable read） 丢失修改 丢失修改（续） 丢失修改是指事务1与事务2从数据库中读 入同一数据并修改 事务2的提交结果破坏了事务1提交的结果 导致事务1的修改被丢失 丢失修改（续） 原因： 两个（或多个）事务对“同一数据”并发地“写入”引起（违背了事务的隔离性，事务间产生了干扰） 称为“写-写”冲突。 结果： 与串行地执行两个（或多个）事务的结果不一致。 读“脏”数据 读“脏”数据 事务1修改某一数据，并将其写回磁盘 事务2读取同一数据后，事务1由于某种原因被撤消，这时事务1已修改过的数据恢复原值 事务2读到的数据就与数据库中的数据不一致，是不正确的数据，又称为“脏”数据。 读“脏”数据 原因: 由一事务读另一事务尚未提交的数据引起 称为“写-读”冲突 结果: 有可能读到要回退的更新数据 不可重复读 不可重复读 事务1读取数据后，事务2执行更新操作，使事务1无法再现前一次读取结果。 不可重复读 原因： 由“读-写”冲突引起 结果： 第二次读的值与前次读的值不同 三类不可重复读 事务1读取某一数据后： 事务2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。 事务2删除了其中部分记录，当事务1再次读取数据时，发现某些记录神密地消失了。 事务2插入了一些记录，当事务1再次按相同条件读取数据时，发现多了一些记录。 后两种不可重复读有时也称为幻影现象（phantom row） 不可重复读----幻影现象 第十一章 数据库并发控制及SQL Server的并发控制机制 11.1 并发控制概述 11.2 并发调度的可串行性 11.3 封锁 11.4 两段锁协议 11.5 封锁的粒度 11.6 活锁和死锁 11.7 SQL Server的并发控制机制 11.8 小结 11.2 并发调度的可串行性 一、 可串行化调度 二、 冲突可串行化调度 一、 可串行化调度 将所有事务串行起来的调度策略一定是正确的调度策略。 如果一个事务运行过程中没有其他事务在同时运行，也就是说它没有受到其他事务的干扰，那么就可以认为该事务的运行结果是正常的或者预想的 可串行化调度（续） 几个事务的并行执行是正确的，当且仅当其结果与按某一次序串行地执行它们时的结果相同。这种并行调度策略称为可串行化（Serializable）的调度。 可串行化调度（续） 可串行性是并行事务正确性的唯一准则 例：现在有两个事务，分别包含下列操作： 　 事务1：读B；A=B+1；写回A； 事务2：读A；B=A+1；写回B； 假设A的初值为2，B的初值为2。 可串行化调度（续） 对这两个事务的不同调度策略 串行执行 串行