1. CMU SSD7: Database Systems Lu Wei School of Software Northwestern Polytechnical University

2. 4.1 事务管理 数据库系统两个核心概念： • 数据抽象 • 事务支持 事务特性和事务保证 Lu Wei

3. 4.1.1事务支持 A transaction is the execution of a program segment that performs some function or task by accessing a shared database. A transaction is a logical unit of work on the database • deposit, withdraw, or transfer money • reserve a seat on a flight • reserve a room in a hotel Lu Wei

4. We also defined a transaction as a unit of consistency. • A transaction always takes the database from one consistent state to another. • Transaction must end in either of two result. Lu Wei

5. 事务属性 ACID属性 As data models support data abstraction, transactions can be thought of similarly as supporting activity abstraction. Transactions provide application programmers with a high-level execution interface that hides both the effects of concurrency among the different transactions, and the presence of failures. How to do this? Lu Wei

6. 原子性（Atomicity） Atomicity requires that either "all or none" of the transaction's operations be performed. Thus, all the operations of a transaction are treated as a single, indivisible, atomic unit. 由DBMS的恢复子系统保证。 Lu Wei

7. 一致性（Consistency） Consistency requires that a transaction maintain the integrity constraints on the database. Thus, transactions are assumed to be correct and are treated as the unit of consistency. 由DBMS和应用程序开发者共同保证 Lu Wei

8. 隔离性（Isolation） Isolation requires that a transaction execute without any interference from other concurrent transactions. That is, transactions are assumed to be independent. 由DBMS的并发控制子系统保证 Lu Wei

9. 持久性（Durability） Durability requires that all the changes made by a committed transaction become permanent in the database, surviving any subsequent failures. 由DBMS的恢复子系统保证。 Lu Wei

10. A DBMS supports the ACID properties of transactions by implementing three different sets of algorithms. The first set, referred to as concurrency control protocols, ensures the isolation property; the second set, referred to as recovery protocols, ensures atomicity and durability properties; and the last set, referred to as triggering mechanisms, enforces the integrity constraints on a database. Lu Wei

11. 4.1.2并发控制（Concurrency Control） 管理数据库上的并发操作使之不相互干扰的过程。 Lu Wei

12. 并发控制的必要性 1.丢失更新问题（lost update problem ） Lu Wei

13. 2.未提交读取问题（脏读问题 dirty read problem ） Lu Wei

14. 3.不可重复读问题（non-repeatable read problem） Lu Wei

15. 幻读（phantom）问题 Lu Wei

16. 分析原因 以上错误现象产生原因根本上是事务交叉执行导致的，单个事务本身都是正确的，如果让以上事务串行执行，可以消除问题。 对于都是更新问题，如果禁止事务T1读balx的值直到T2完成更新，则可避免。 对于为提交读取问题，如果在T4成功提交或撤销之前禁止T3读取balx，则可避免。 对于不可重复读问题，如果禁止事务T6在事务T5之前读取balx和baly，则可避免。 Lu Wei

17. 基本概念 1.调度：包含一套并发事务中的所有操作，且不改变单个事务内部各操作之间相对次序的执行序列。 2.串行调度：每个事务的操作连续执行，各事务之间的操作没有任何重叠的调度。 3.非串行调度：并发事务集合的操作互相重叠执行的调度。 Lu Wei

18. 所有的串行调度都被认为是正确的，尽管串行调度可能产生不同的结果，但是它从不会使数据库处于不一致的状态。所有的串行调度都被认为是正确的，尽管串行调度可能产生不同的结果，但是它从不会使数据库处于不一致的状态。 可串行化（Serializable）：事务集合并发执行，调度是可串行化的当且仅当它能够产生和某一串行调度相同的结果。 正确调度：可串行化的调度。 等价调度 冲突操作，非冲突操作 冲突可串行化 Lu Wei

19. 判断调度冲突可串行化方法：有向图法 对于调度S，先后顺序图（precedence graph）是一个有向图G=(N,E)，由节点集合N和有向边集合E构成，构成方式如下： 1）为每个事务创建一个节点； 2）如果Tj读取Ti已经执行了写操作的数据项的值，创建有向边Ti→Tj; 3）如果Tj对Ti已经读取的数据项执行写操作，创建有向边Ti→Tj； 4）如果Tj对Ti已经执行了写操作的数据项执行写操作，创建有向边Ti→Tj； 结论：如果有向图包含循环，则调度不是冲突可串行化的 Lu Wei

20. 冲突可串行调度 Lu Wei

21. Lu Wei

22. x T9 T10 y 非冲突可串行调度 考察上面关于丢失更新、未提交读取和不可重复读取的案例 Lu Wei

23. 视图可串行化 • 所有冲突可串行化调度都是视图可串行的，反之则不然。 任何不是冲突可串行调度的视图可串行调度都包含一个或多个盲写。 Lu Wei

24. 通过考察得知，上面提到的3个问题中的两个都是由于调度是不可串行化而导致的，能否找到一种方法或策略控制事务调度，使其满足可串行化？通过考察得知，上面提到的3个问题中的两个都是由于调度是不可串行化而导致的，能否找到一种方法或策略控制事务调度，使其满足可串行化？ 并发控制技术：加锁和时间戳（悲观方法） 乐观方法 Lu Wei

25. 加锁方法 加锁：用来控制数据访问的一个过程。当一个事务访问数据库时，锁将拒绝其他事务的访问请求，从而避免产生不正确的结果。 共享锁：如果事务在数据项上加一个共享锁，那么该事务只能读而不能更新数据项。 互斥锁：如果事务在数据项上加一个互斥锁，那么该事务既可读也可更新数据项。 既然读操作是不冲突的，因此应该允许多个并发事务同时获得同一数据项的共享锁； 由于写操作是冲突的，因此只要事务在数据项上拥有了互斥锁，其他事务都无法读取或修改数据。 Lu Wei

26. 锁的使用规则如下： 1）任何需要访问数据项的事务首先要对数据项加锁，共享锁或互斥锁 2）如果数据项没有被其他事务加锁，可以对该数据项加锁 3）如果数据项已经被加锁，由DBMS判断当前的加锁请求和已经存在的锁是否兼容（只有共享锁和共享锁兼容）。若不兼容，则事务必须等待，直到现有锁被释放。 4）事务继续保持锁，直到它在执行期间或终止（提交或回滚）后显示释放。 Lu Wei

27. 使用封锁的方法是否能够一定保证调度的可串行化？使用封锁的方法是否能够一定保证调度的可串行化？ Lu Wei

28. 对上图使用前面的加锁规则，可能会产生如下的调度：对上图使用前面的加锁规则，可能会产生如下的调度： S={write_lock(T9,balx),read(T9,balx),write(T9,balx),unlock(T9,balx), write_lock(T10,balx),read(T10,balx), write(T10,balx), unlock(T10,balx), write_lock(T10,baly),read(T10,baly), write(T10,baly),unlock(T10,baly), commit(T10), write_lock(T9,baly),read(T9,baly),write(T9,baly),unlock(T9,baly), commit(T9)} S仍然不是一个可串行化调度 Lu Wei

29. 在上面的例子中，事务一旦对某各数据项的读/写操作完成，调度就释放事务对这个数据项的锁，然后该事务又对其他数据项加锁，这看起来增加了并发性，但由于这允许事务彼此交叉，导致事务的原子性和隔离性的丢失。在上面的例子中，事务一旦对某各数据项的读/写操作完成，调度就释放事务对这个数据项的锁，然后该事务又对其他数据项加锁，这看起来增加了并发性，但由于这允许事务彼此交叉，导致事务的原子性和隔离性的丢失。 换一种加锁机制试试（事务提交或回滚时再释放锁） 结论：仅仅使用加锁技术并不能够保证调度一定是可串行化的。 如何通过加锁技术保证事务调度的可串行化？ Lu Wei

30. 两段锁协议（Two-Phase Locking Protocols） 2PL：如果事务中所有的加锁操作都在事务的第一个解锁操作之前进行，那么这个事务是遵循两段锁协议的。 具体如下： 1）数据在对一个数据项进行操作之前，必须先获得对该数据项的锁。根据访问类型，锁可以是读或写锁。 2）一旦事务释放了一个锁，它就不能再获得任何新锁。 根据该协议，每个事务可以被分为两个阶段：第一阶段是增长阶段，在这个阶段，事务获得它所需要的所有锁（不一定是同时），但不释放其中任何一个；第二阶段是收缩阶段，在这个阶段，事务释放它所拥有的锁，但不能在请求任何新锁。 Lu Wei

31. 使用两段锁协议解决前面的三个问题 1.丢失更新 Lu Wei

32. 2.未提交读取问题 Lu Wei

33. 3.不可重复读取问题（下一页） Lu Wei

34. Lu Wei

35. 如果一个调度中的每个事务都遵循两段锁协议，那么该调度必然是冲突可串行化的。如果一个调度中的每个事务都遵循两段锁协议，那么该调度必然是冲突可串行化的。 事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。 问题： 1）如何确定事务执行到哪一点就不再需要更多的锁了？ 2）事务遵循两段锁协议保证调度可串行化的同时，还会不会产生问题？ Lu Wei

36. Lu Wei

37. 级联回滚：级联回滚是一种不好的现象，它潜在导致了大量工作的作废。如果能设计一种避免级联回滚现象的协议，将非常有用。在两段锁基础上，如果规定，事务只有到结束才释放所有锁，情况会怎么样？级联回滚：级联回滚是一种不好的现象，它潜在导致了大量工作的作废。如果能设计一种避免级联回滚现象的协议，将非常有用。在两段锁基础上，如果规定，事务只有到结束才释放所有锁，情况会怎么样？ Lu Wei

38. 严格两段锁协议（Strict 2PL protocol） Sttict 2PL is one in which transactions request locks just before they operate on a data item and their growing phase ends just before they are committed. 严格两段锁协议将事务以他们提交的顺序串行化。 次严格2PL：互斥锁直到事务结束才被释放 Lu Wei

39. 死锁 两段锁协议下的一个重要问题是死锁。 死锁：当两个或多个事务相互等待对方所拥有的锁被释放时，所产生的僵持局面。 Lu Wei

40. 两个事务都无法继续，他们都在相互等待对方结束从而获得对方的锁。两个事务都无法继续，他们都在相互等待对方结束从而获得对方的锁。 Lu Wei

41. 死锁解除：撤销其中的一个或多个事务。 死锁避免： 1）超时技术（timeout） 2）时间戳技术：两种算法：Wait-Die；Wound-Wait 死锁检测： 1）等待图（WFG）： 1.为每个事务创建一个节点； 2.若事务Ti等待对一个当前被Tj加锁的数据项进行加锁，则创建有向边Ti→Tj。 当且仅当WFG中包含回路时存在死锁。 Lu Wei

42. x T17 T18 y 该图有一个环T17→ T18 →T17，因此，可断言该系统处于死锁状态 Lu Wei

43. 死锁检测频率： 1）定期 2）每当有事务阻塞 3）动态死锁检测算法 死锁检测后的恢复： 死锁损失程度选择 事务回滚程度 避免饿死现象：死锁后，某个事务总是被选为牺牲品。 Lu Wei

44. 活锁 事务处于无限期的等待中，不能获得任何锁，但是DBMS并未发生死锁。这是由于事务等待算法不公平导致的，为考虑事务等待时间长短。未避免活锁，可以采用优先级系统，例如“先来先服务”队列。 Lu Wei

45. 封锁粒度 Lu Wei

46. 事务隔离等级 SET TRANSACTION READ ONLY | READ WRITE [ ISOLATION LEVEL READ UNCOMMITTED | READ COMMIT | REPEATABLE READ | SERIALIZABLE ] Lu Wei

47. 4.1.2 数据库恢复 数据库恢复：在故障发生时，将数据库恢复到正确状态的过程。 Lu Wei

48. 可恢复性 若事务都不失效，可串行化能保证数据库并发性的调度。 另一个问题就是事务的可恢复性： 若事务失效，事务的原子性要求将数据库恢复到事务执行之前的状态。另外，事务持久性要求，一旦事务提交，则对数据库所做的修改就无法恢复。 Lu Wei

49. 若T9最后决定回滚事务，T10已经读取了T9写入数据库的数据，T10也应该回滚，但持久性却不允许这么做。这个调度是不可恢复的。若T9最后决定回滚事务，T10已经读取了T9写入数据库的数据，T10也应该回滚，但持久性却不允许这么做。这个调度是不可恢复的。 Lu Wei

50. 可恢复调度 可恢复调度： 对于每一对事务Ti和Tj，如果Tj读取了早先被Ti改写过的数据项，那么Ti事务应该在事务Tj之前提交自己的操作。 Lu Wei