系统实现技术课件

第八章系统实现技术

——事务和锁本章重要概念

（1）事务的定义，COMMIT和ROLLBACK的语义，事务的ACID性质，事务的状态变迁图。（2）存储器类型，稳定存储器的实现，数据传送过程。（3）恢复的定义、基本原则和实现方法，故障的类型，检查点技术，REDO和UNDO操作，运行记录优先原则。（4）并发操作带来的三个问题，X锁、S锁、使用X锁和S锁的操作，封锁协议，活锁、饿死和死锁，并发调度、串行调度、并发调度的可串行化，SQL中事务的存取模式和隔离级别，基于时标的并发控制。第8章系统实现技术8.1事务8.2数据库的恢复8.3数据库的并发控制为什么需要事务8.1-1例如，银行转帐问题：假定资金从帐户A转到帐户B，至少需要两步：帐户A的资金减少然后帐户B的资金相应增加银行转帐帐户A帐户B为什么需要事务8.1-2CREATETABLEbank(customerNameCHAR(10),--顾客姓名

currentMoneyMONEY--当前余额)GOALTERTABLEbank

ADDCONSTRAINTCK_currentMoneyCHECK(currentMoney>=1)GOINSERTINTObank(customerName,currentMoney)VALUES('张三',1000)INSERTINTObank(customerName,currentMoney)VALUES('李四',1)创建帐户表，存放用户的帐户信息添加约束：根据银行规定，帐户余额不能少于1元，否则视为销户张三开户，开户金额为1000元；李四开户，开户金额1元为什么需要事务8.1-3目前两个帐户的余额总和为：1000+1=1001元

为什么需要事务8.1-5--张三的帐户减少1000元，李四的帐户增加1000元UPDATEbankSETcurrentMoney=currentMoney-1000WHEREcustomerName='张三'UPDATEbankSETcurrentMoney=currentMoney+1000WHEREcustomerName='李四'GO错误原因分析：UPDATE语句违反约束：

余额>=1元执行失败，所以张三还是1000元继续往下执行：执行成功，所以李四变为1001元如何解决呢？使用事务8.1.1

事务的定义(1)定义8.1事务（transaction）是构成单一逻辑工作单元的操作集合，要么完整地执行，要么完全不执行。不论发生何种情况，DBS必须保证事务能正确、完整地执行。在程序中，事务以BEGINTRANSACTION语句开始，以COMMIT语句或ROLLBACK语句结束。

COMMIT语句表示事务执行成功地结束（提交），此时告诉系统，数据库要进入一个新的正确状态，该事务对数据库的所有更新都已交付实施（写入磁盘）。

ROLLBACK语句表示事务执行不成功地结束（应该“回退”），此时告诉系统，已发生错误，数据库可能处在不正确的状态，该事务对数据库的所有更新必须被撤消，数据库应恢复该事务到初始状态。用户定义的一个对数据库读写操作序列一个不可分割的工作单位数据库恢复和并发控制的基本单位数据库系统中通常有多个事务并行运行事务和程序比较在关系数据库中，一个事务可以是一条或多条SQL语句,也可以包含一个或多个程序。一个程序通常包含多个事务转帐过程就是一个事务。它需要两条UPDATE语句来完成，这两条语句是一个整体，如果其中任一条出现错误，则整个转帐业务也应取消，两个帐户中的余额应恢复到原来的数据，从而确保转帐前和转帐后的余额不变，即都是1001元。8.1.1

事务的定义(2)8.1.1

事务的定义(4)对数据库的访问是建立在读和写两个操作的基础上的：read（X）：把数据X，从磁盘的数据库中读到内存的缓冲区中。write（X）：把数据X，从内存缓冲区中写回磁盘的数据库。在系统运行时，write操作未必导致数据立即写回磁盘，很可能先暂存在内存缓冲区中，稍后再写回磁盘。这件事情是DBMS实现时必须注意的问题。8.1.2

事务的ACID性质性质:原子性(Atomicity):事务是一个不可分割的工作单元，事务中的操作要么都做，要么都不做(AllorNone)

一致性(Consistency):即数据不会应事务的执行而遭受破坏。事务执行的结果必须使数据库从一个一致性状态变到另一个一致性状态。与原子性密切相关。隔离性(Isolation):在多个事务并发执行时，系统应保证与这些事务先后单独执行时的结果一样。持久性(Durability):一个事务一旦完成全部操作后，它对数据库的所有更新应永久地反映在数据库中。8.2数据库的恢复8.2.1存储器结构8.2.2恢复的基本原则和实现方法8.2.3故障类型和恢复方法8.2.4检查点技术8.2.5SQL对事务的支持8.2.1存储器结构(2)3.数据访问块、物理块和缓冲块块的操作input（A）：把物理块A的内容传送到内存的缓冲块中。Output（B）：把缓冲块B的内容传送到磁盘中恰当的物理块中

B内存AB磁盘input(A)output(B)图8.2块操作8.2.1存储器结构(3)xiwrite(X)包含x的块Bx存在，read(X)事务系统开始请求read(X)事务工作区分配X磁盘缓冲区扫描内存磁盘包含x的块Bx存在，input(B)8.2.1存储器结构(4)银行转账系统A=2000B=1000事务A=A-100B=B+100output(A)output(B)断电或其他故障假设没有事务的原子性，那么重新启动事务时，要么A因为再执行一遍而为1800，要么B因从未执行而保持原值。4.恢复和原子性的联系8.2.3故障类型和恢复方法(1)1.事务故障可以预期的事务故障，如存款余额透支等非预期事务故障，如运算溢出、数据错误、死锁等2.系统故障：硬件故障、软件错误或掉电等,重新启动时，具体处理分两种情况考虑。对未完成事务作UNDO处理；对已提交事务但更新还留在缓冲区的事务进行REDO处理。8.2.3故障类型和恢复方法(2)3．介质故障在发生介质故障和遭受病毒破坏时，磁盘上的物理数据库遭到毁灭性破坏。此时恢复的过程如下：重装最近转储的后备副本到新的磁盘，使数据库恢复到转储时的一致状态。在日志中找出最近转储以后所有已提交的事务。对这些已提交的事务进行REDO处理，将数据库恢复到故障前某一时刻的一致状态。在实际中，系统故障通常称为软故障(SoftCrash)，介质故障通常称为硬故障(HardCrash)。8.2.4检查点技术(1)1．检查点方法

在DBS运行时，DBMS定时设置检查点。在检查点时刻才真正做到把对DB的修改写到磁盘，并在日志文件写入一条检查点记录(以便恢复时使用)。当DB需要恢复时，只有那些在检查点后面的事务需要恢复。事务T1不必恢复；事务T2和事务T4必须重做(REDO)；事务T3和事务T5必须撤消(UNDO)。事务检查点故障点t检查点T1T3T2T5T48.2.5SQL对事务的支持无begintransactionCommitRollback8.3数据库的并发控制8.3.1并发操作带来的三个问题8.3.2封锁技术8.3.3封锁带来的问题8.3.4并发操作的调度8.3.5SQL对事务处理的支持8.3.1并发操作带来的三个问题(1)图8.5在时间t8丢失了事务T1的更新（FIND表示从DB中读值，UPD表示把值写回到DB）

1．丢失更新问题（例8.2）时间更新事务T1数据库中A的值更新事务T2t0

100

t1FINDA

t2

FINDAt3A:=A-30

t4

A:=A*2t5UPDA

t6

80UPDAt8

200

8.3.1并发操作带来的三个问题(3)图8.8事务T2在时间t4读了未提交的A值，并在时间t8丢失了自己的更新2．读脏数据问题（例8.4，用户读了“脏数据”，引起自身的更新操作被丢失，破坏了数据库的完整性）时间更新事务T1数据库中A的值更新事务T2t0

100

t1FINDA

t2A:=A-30

t3UPDA

t4

80FINDAt5

A:=A*2t6

UPDAt8

140

t8*ROLLBACK*

t9

100

8.3.1并发操作带来的三个问题(4)图8.8事务T1两次读取A的值，却得到了不同的结果3.不可重复读问题（例8.5）时间读事务T1数据库中A的值更新事务T2t0

100

t1FINDA

t2

XFINDAt3

A:=A*2t4

UPDAt5

200COMMITt6FINDA

8.3.1并发操作带来的三个问题(5)时间更新事务T1数据库中A值更新事务T2t0

100

t1FINDA

t2

FINDAt3A:=A-30

t4

A:=A*2t5UPDA

t6

80UPDAt8

200

图8.5在时间t8丢失了事务T1的更新①②③解决方法：8.3.2

封锁技术(1)定义8.3锁（lock）是一个与数据项相关的变量，对可能应用于该数据项上的操作而言，锁描述了该数据项的状态。通常在数据库中每个数据项都有一个锁。锁的作用是使并发事务对数据库中数据项的访问能够同步。封锁技术中主要有两种封锁：●排他型封锁●共享型封锁8.3.2

封锁技术(2)1.排他型封锁（X锁，写锁）X锁定义：如果事务T对某个数据R（可以是数据项、记录、数据集乃至整个数据库）实现了X锁，那么在T对数据R解除封锁之前，不允许其他事务T再对该数据加任何类型的锁。这种锁称为“X锁”。X锁的操作有两个：封锁操作“XFINDR”：表示事务对数据R申请加X锁，若成功，则可以读或写数据R，若不成功，那么这个事务将进入等待队列，直到获得X锁，事务才继续做下去。解锁操作“XRELEASER”：表示事务要解除对数据R的X锁

X锁的解除操作应该合并到事务的结束（COMMIT或ROLLBACK）操作中。时间更新事务T1DB中A的值更新事务T2t0

100

t1XFINDA

t2

XFINDA(失败)

wait(等待)t3A:=A-30

waitt4

waitt5UPDA

waitt6

80waitt8COMMIT(含解锁)

waitt8

XFINDA(重做)t9

A:=A*2t10

UPDAt11

140COMMIT(含解锁)8.3.2

封锁技术(3)例8.6使用X锁技术，可以解决图8.5的丢失更新问题。图8.9等事务T1更新完成后再执行事务T22．共享型封锁（S锁，读锁）定义8.5如果事务T对某数据加上S锁后，仍允许其他事务再对该数据加S锁，但在对该数据的所有S锁都解除之前决不允许任何事务对该数据加X锁。S锁的操作有三个：封锁操作“SFINDR升级和写操作“UPDXR”解锁操作“SRELEASER”可以看出，获准S锁的事务只能读数据，不能更新数据，若要更新，则先要把S锁升级为X锁。另外，由于S锁只允许读数据，因此解除S锁的操作不必非要合并到事务的结束操作中去，可以随时根据需要解除S锁。8.3.2

封锁技术(4)时间更新事务T1DB中A的值更新事务T2t0

100

t1SFINDA

t2

SFINDAt3A:=A-30

t4

A:=A*2t5UPDXA(失败)

t6wait

UPDXA(失败)t8wait

waitt8wait

wait8.3.2

封锁技术(5)例8.8

使用S锁技术,也可以解决图8.5的丢失更新问题。图8.10

更新未丢失,但在时间t6发生了死锁注：①N=NO，不相容的请求

Y=YES，相容的请求②X、S、－：分别表示X锁，S锁，无锁③如果两个封锁是不相容的，则后提出封锁的事务要等待。XS—XNNYSNYY—YYYT1T28.3.2

封锁技术(6)3．封锁的相容矩阵4．封锁的粒度定义8.6

封锁对象的大小称为封锁的粒度。封锁的对象逻辑单元:属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库

物理单元

:页（数据页或索引页）、块

封锁粒度与系统并发度和并发控制开销密切相关。粒度越大，系统中能被封锁的对象就越少，并发度就越小，但同时系统的开销也就越小；相反，粒度越小，并发度越高，系统开销越大。选择封锁粒度时必须同时考虑封锁机构与并发度两个因素，对系统开销与并发度进行权衡。8.3.2

封锁技术(8)5．封锁协议：三级封锁协议，分别在不同程度上解决了并发操作带来的各种问题，为并发操作的正确调度提供一定的保证。8.3.2

封锁技术(8)表8.1封锁协议的内容和优缺点级别内容优点缺点一级封锁协议事务在修改数据之前，必须先对该数据加X锁,直到事务结束时才释放但只读数据的事务可以不加锁防止“丢失修改”不加锁的事务，可能“读脏数据”，也可能“不可重复读”二级封锁协议但其他事务在读数据之前必需先加S锁读完数据后即可释放S锁防止“丢失修改”，防止“读脏数据”对加S锁的事务,可能“不可重复读”三级封锁协议直到事务结束时才释放S锁防止“丢失修改”，防止“读脏数据”，防止“不可重复读”8.3数据库的并发控制8.3.1并发操作带来的三个问题8.3.2封锁技术8.3.3封锁带来的问题8.3.4并发操作的调度8.3.5SQL对事务处理的支持8.3.3

封锁带来的问题(1)1．“活锁”问题定义8.8系统可能使某个事务永远处于等待状态，得不到封锁的机会，这种现象称为“活锁”（LiveLock）。解决活锁问题的一种简单的方法是采用“先来先服务”的策略，也就是简单的排队方式。如果运行时，事务有优先级，那么很可能使优先级低的事务，既使排队也很难轮上封锁的机会。此时可采用“升级”方法来解决，也就是当一个事务等待若干时间（譬如5分钟）还轮不上封锁时，可以提高其优先级别，这样总能轮上封锁。8.3.3

封锁带来的问题(2)2．“饿死”问题定义8.8有可能存在一个事务序列，其中每个事务都申请对某数据项加S锁，且每个事务在授权加锁后一小段时内释放封锁，此时若另有一个事务T2欲在该数据项上加X锁，则将永远轮不上封锁的机会。这种现象称为“饿死”（starvation）。可以用下列方式授权加锁来避免事务饿死。当事务T2中请对数据项Q加S锁时，授权加锁的条件是：①不存在在数据项Q上持有X锁的其他事务；②不存在等待对数据项Q加锁且先于T2申请加锁的事务。8.3.3

封锁带来的问题(3)3.“死锁”问题定义8.9系统中有两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执行，这种现象称系统进入了“死锁”（DeadLock）状态。时间事务T1事务T2t0XFINDA

t1

XFINDBt2XFINDB

t3waitXFINDAt4waitwait图8.12在时间t4两个事务发生死锁8.3.3

封锁带来的问题(4)我们可以用事务依赖图的形式测试系统中是否存在死锁。图中每一个结点是“事务”，箭头表示事务间的依赖关系。图8.14为无环依赖图，表示系统未进入死锁状态；而图8.15为有环依赖图，则表示系统进入死锁状态。数据B数据A8.3.3

封锁带来的问题(5)DBMS中有一个死锁测试程序，每隔一段时间检查并发的事务之间是否发生死锁。如果发生死锁，那么只能抽取某个事务作为牺牲品，把它撤消，做回退操作，解除它的所有封锁，恢复到该事务的初始状态。释放出来的资源就可以分配给其他事务，使其他事务有可能继续运行下去，就有可能消除死锁现象。理论上，系统进入死锁状态时可能会有许多事务在相互等待，但是SystemR的实验表明，实际上绝大部分的死锁只涉及到两个事务，也就是事务依赖图中的循环里只有两个事务。有时，死锁也被形象地称作“死死拥抱”（DeadlyEmbrace）。8.3数据库的并发控制8.3.1并发操作带来的三个问题8.3.2封锁技术8.3.3封锁带来的问题8.3.4并发操作的调度8.3.5SQL对事务处理的支持事务的调度：事务的执行次序称为“调度”。串行调度：如果多个事务依次