数据库保护技术

第8章数据库保护技术本章内容8.1事务1

8.2并发控制和锁的管理328.1事务管理8.1.1事务的基本概念8.1.2事务的特性8.1.3SQLServer的事务的模式8.1.4事务的处理语句8.1.5批处理8.1.1事务的基本概念 事务概念是一个数据库动态特性的核心，是数据库一致性的单位。事务(transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单元。一个事务就是一组程序，完成对数据库的某些一致性操作，事务中的SQL语句必须按逻辑次序执行。事务是数据库中的最基本的工作单元，也是数据库恢复和并发控制的基本单元。事务的应用背景(1)例1：某公司在银行中有A，B两个帐号，现在公司想从帐号A中取出1万元，存入帐号B。那么在A中取出1万元的操作和在B中增加1万元的操作要么都成功完成，要么都不做。因此，需要把这二个操作定义在一个事务中。银行转帐：事务T从A帐户过户1￥到B帐户。

T： read(A); A:=A–1; write(A); read(B); B:=B+1; write(B);read(X)：从数据库传送数据项X到事务的工作区中。write(X)：从事务的工作区中将数据项X写回数据库。例2：考虑飞机订票系统中的一个活动序列：(1)甲售票点读出某航班的机票余额=16；(2)乙售票点读出同一航班的机票余额也为16；(3)甲售票点卖出一张机票，修改余额为15，并把A写回数据库；(4)乙售票点也卖出一张机票，也修改余额为15，并把A写回数据库。甲： read(A);乙： read(A);甲： A:=A–1;乙： A:=A–1;甲： write(A);乙： write(A);

结果卖出了两张票，数据库中机票余额只减少1。因此，要把甲乙售票点的操作放在两个事务中，一个执行完了才能执行另一个。事务的应用背景(2)8.1.2事务的特性(1)事务具有四个特性：原子性(Atomicity)、一致性(Consistency)、分离性(Isolation)、持久性(Durability)。这四个特性也简称为ACID特性。8.1.2事务的特性(2)(1)原子性(Atomicity)

事务的原子性指的是，事务中包含的程序作为数据库的逻辑工作单位，它所做的对数据修改操作要么全部执行，要么完全不执行。这种特性称为原子性。(2)一致性(Consistency)

事务的一致性指的是，在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。8.1.2事务的特性(3)(3)分离性(Isolation)

分离性指并发的事务是相互隔离的。即一个事务内部的操作及正在操作的数据必须封锁起来，不被其它企图进行修改的事务看到。

分离性是DBMS针对并发事务间的冲突提供的安全保证，通过并发控制机制实现。DBMS可以通过加锁在并发执行的事务间提供不同级别的分离。

对任何一对事务T1，T2，在T1看来，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行。8.1.2事务的特性(4)(4)持久性(Durability)

持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即一旦一个事务提交，DBMS保证它对数据库中数据的改变应该是永久性的，耐得住任何系统故障。

DBMS保证采取措施：

系统发生故障不能改变事务的持久性。持久性通过事务日志、数据库备份和恢复来保证。8.1.3SQLServer的事务模式SQLServer的事务模式可分为三种：显式事务、隐式事务、自动事务模式。显式事务：

是指由用户执行T-SQL事务语句而定义的事务。SQL语言中事务的定义：

事务以Begintransaction开始，以Committransaction或Rollbacktransaction结束。Committransaction表示事务正常结束，可以提交。

Rollbacktransaction表示事务非正常结束，撤消事务已做的操作，回滚到事务开始时状态。

在SQLServer中，用SETIMPLICITY_TRANSACTIONSON和SETIMPLICITY_TRANSACTIONSOFF语句来进入隐式事务连接模式和退出隐式事务连接模式。

隐式事务不需要使用BEGINTRANSACTION语句标识事务的开始，但需要有事务结束语句COMMITTRANSACTION(或COMMITWORK)标识事务的结束。在隐式事务模式下，某些SQL语句（例CREATETABLE，DROPTABLE语句等）被执行后，马上导致提交操作，结束当前事务。隐式事务：

自动事务是SQLServer的默认事务管理模式。在自动事务模式下，当一个语句成功执行后，它被自动提交，而当它执行过程中产生错误时，则被自动回滚。当应用程序与SQLServer建立连接后，直接进入自动事务模式，直到使用BEGINTRANSACTION语句开始一个显式事务，或者打开IMPLICIT_TRANSACTIONS

连接选项进入隐式事务模式为止。当显式事务被提交或回滚，或者关闭IMPLICIT_TRANSACTIONS连接选项后，SQLServer又进入自动事务管理模式。自动事务模式：8.1.4事务处理语句

SQLServer中有关事务处理的语句包括：

BEGINTRANSACTION

：建立一个显式事务。

COMMITTRANSACTION

：标识一个显式事务或隐式事务正常结束而提交。

SAVETRANSACTION

：在事务内定义一个存储点标记。

ROLLBACKTRANSACTION

：回滚事务。(1)定义和提交事务BEGINTRANSACTION和COMMITTRANSACTION的语句格式：BEGINTRANSACTION[事务名称] {SQL语句}COMMITTRANSACTION①哪些SQL语句组成一个事务由用户根据情况而定。②定义一个事务时，BEGINTRANSACTION语句与COMMITTRANSACTION语句必须成对出现。ROLLBACKTRANSACTION:回滚事务，消除事务执行的影响。在一个事务被提交之前可以使用ROLLBACKTRANSACTION回滚，一旦提交就不能撤销。语句格式：ROLLBACKTRANSACTION[事务名称|存储点名称]该语句回滚整个事务或是存储点定义以后所发生的事务。

ROLLBACKTRANSACTION语句应在COMMITTRANSACTION语句之前调用。(2)回滚事务(3)定义存储点标记SAVETRANSACTION：在事务内建立一个存储点标记。ROLLBACKTRANSACTION语句可使用该标记来回滚部分事务操作。SAVETRANSACTION语句的格式为：

SAVETRANSACTION存储点名称(4)定义、提交和回滚事务示例下面例子说明怎样建立一个用户定义事务及事务中的存储点、回滚操作和事务提交操作。

BEGINTRANSACTIONdemoSELECT*FROMdiscounts

SAVETRANSACTION

save_demo/存储点/INSERTdiscountsVALUES(‘demo’,null,null,null,20.0)SELECT*FROMdiscounts

ROLLBACKTRANSACTION

save_demo/回滚/COMMITTRANSACTIONSELECT*FROMdiscounts/结果没有变化/

在SQLServer中，允许定义嵌套事务，但只有最外层的BEGINTRANSACTION语句和COMMITTRANSACTION语句才能建立和提交事务，在回滚事务时，也只能使用最外层定义的事务名或存储点标记，而不能使用内层定义的事务名。 事务嵌套常用在存储过程或触发器内，它们可以使用BEGINTRANSCATION

……COMMITTRANSACTION对来相互调用。(5)事务嵌套(6)事务状态的变化0活动状态2失败状态1部分可提交状态，部分语句没执行3提交状态4回滚状态初始状态事务无法继续正常执行事务回滚，数据库恢复到事务开始前状态执行最后一条语句成功完成，永久写入数据库图7-6事务状态的变化5结束状态8.1.5批处理批是一组SQL语句的集合，一个批以批处理结束符号GO结束。批中语句被一次提交给SQLServer，SQLServer将这些语句编译为一个执行单元，称做SQLServer执行计划。GO不是SQL语句。它是在某些客户端工具中使用的符号，客户端工具将它解释为：最后一个GO上面的所有内容都应该一起发送到服务器来执行。例：右边例子中的注释符号并没有起到预先的目的。原因：客户端工具并没有解释任何SQL语句，它只是将语句分解成多个批处理。SQLServer批处理的示例(1)SELECT*FROMauthors/*GOSELECT*FROMsalesGOSELECT*FROMpublishersGO*/SELECT*FROMtitlesGO

如果在一个包含批处理结束的GO命令T-SQL语句集合中，想注释一些语句，那么应该在每个GO的前面使用另外一种注释标记符：两个短划线(也可以用其它字符代替两个短划线)。上例中的应改为：SELECT*FROMauthors/*--GOSELECT*FROMsales--GOSELECT*FROMpublishers--GO*/SELECT*FROMtitlesGOSQLServer批处理的示例(2)

在执行批时，如果其中任一个T-SQL语句存在语法错误，SQLServer将取消批中所有语句的执行。例1：SELECT*FROMsalesSELECT*FRO

titleauthorGO

在上例中，第一个语句是正确的，第二个语句存在语法错误，但由于这两个语句是在一个批中，第一个语句不会被执行，执行这个批的结果是返回一个错误信息。SQLServer批处理的示例(3)建立批时应注意的事项CREATEVIEW、CREATERULE、CREATEDEFAULT、CREATETRIGGER、CREATEPROCEDURE 语句应在批中单独提交，它们不能与其它T-SQL语句一起构成一个批。(2)使用ALTERTABLE语句修改表结构后，不能在同一个批中参照新定义列。(3)EXECUTE(或EXEC)语句为批中第一个语句时，EXECUTE(或EXEC)关键字可以省略。否则，必须使用该关键字。批和事务的区别批是一个客户端的基本概念，它控制多个语句如何发送到SQLServer以便立即处理。而事务是一个服务器端的概念，是SQLServer执行T-SQL语句的基本工作单元。批语句的组合发生在编译时刻，而事务中语句的组合发生在执行时刻。当在编译时，如果批中某个语句存在语法错误，SQLServer将取消这个批中所有语句的执行。在执行时刻，如果事务中某个数据修改操作违犯约束、规则、触发器等条件时，SQLServer将回滚整个事务。在一个批中可以包含多个事务，在一个事务中也可以包含多个批。一个事务中包含批的示例例1：下面的例子是一个事务，它由四个批处理组成：BEGINTRANINSERTauthorsVALUES(...)GOSELECT*FROMauthorsGOUPDATEpublishersSETpub_id=(...)GOSELECT*FROMpublishersGOCOMMITTRAN一个批中包含多个事务示例例2：下面的例子是一个批处理，它由两个事务组成：BEGINTRANINSERTauthorsVALUES(...)SELECT*FROMauthorsCOMMITTRANBEGINTRAN

UPDATEpublishersSETpub_id=...INSERTpublishersVALUES(...)COMMITTRANGO8.2并发控制和锁的管理8.2.1并发控制8.2.2锁的管理8.2.1并发控制数据库是一个共享资源，可供多个用户使用。允许多个用户同时使用的数据库系统称为多用户数据库系统。例如：银行数据库系统、机票订票数据库系统等。当多个用户并发地存取数据库数据时，就可能会产生多个事务同时存取同一数据的情况。若对并发操作不加控制，就可能会导致读和写不正确的数据，破坏数据库的一致性。并发控制的核心问题是在保证数据库一致性的前提下最大限度地提高并发度。并发所引起的问题事务如果不加控制地并发执行，会产生下列三个问题：丢失更新(lostupdate)读脏数据

(dirtyread)读值不可复现(unrepeatableread)丢失更新右图是事务T1和T2并发执行的情况。如果x的初始值为5，则x的结果值为15。即T1对x的更新被丢失。T1T2read(x)read(x)x:=x+1write(x)x:=3xwrite(x)时间把X由5增加1变为6把X由5乘3变为15初始值X=5

丢失更新问题是由于两个事务对同一数据并发写入所引起的，这称为“写－写冲突”。读脏数据(1)

右图中，T1对某元组t的两个属性x，y进行更新，T2并发地读取t[x]，t[y]，x在更新前读，y在更新后读，这样所读得的值既不反映t更新前的状态，也不反映t更新后的状态，是不一致的数据。T1T2read(x)write(t)时间read(y)(rollback)更新t[x]更新t[y]读更新后的t[y]读更新前的t[x]可能会读到脏数据的另一种情况：当T2计算某种聚集函数(例如AVG)时，要用到多个元组的某一属性值(例如工资)，如果T1并发地修改工资值，则T2在计算平均工资时，有些可能是修改前的工资值，有些可能是修改后的工资值，这也是一种不一致性。读脏数据问题是由于一个事务读另一个更新事务尚未提交的数据所引起的，这称为“读－写冲突”。读脏数据(2)读值不可复现(1)

在右图中，T1两次读x，本来T1两次读出的x应该是一样的，但如果在两次读之间，另一个与T1并发执行的事务T2修改了x，则T1两次读出的x可能就不同。读值不可复现也是由“读－写冲突”所引起的。T1T2read(x)write(x)时间read(x)更新X值读更新前的X值读更新后的X值并发控制的任务就是避免访问冲突所引起的数据不一致。数据库管理系统一般都提供并发控制机制。即采用对资源加锁的方法控制用户并发操作。读值不可复现(2)8.2.2锁的管理

为了避免并发事务引起操作的冲突，DBMS提供了对数据进行封锁的管理机制。1.加锁和解锁加锁(LOCK)：当一个事务访问数据库中的某个数据单元时，要先对被访问的数据单元加锁。假如要访问的数据单元还没有设置其他锁，该事务就获得访问权，否则，该事务必须等待直到释放其他的锁。解锁(UNLOCK)：进程访问结束释放锁。1.两种基本的锁类型

通常设置的两种基本类型的锁:

共享锁(S锁，Sharedlock)：只用于并发的只读数据操作。任何试图修改某数据的事务，如果该数据上有共享锁，那么该事务就会被阻塞，直到所有的共享锁被释放。

独占锁(X锁，eXclusivelock)

：任何写操作均要使用独占锁。独占锁被授予已经准备好进行数据修改的事务，确保其它事务不能访问该独占锁锁定的数据。图8－4两种锁的相容矩阵T1T2独占锁

共享锁

—独占锁共享锁

—NONOYESNOYESYESYESYESYESYES=相容的请求，NO＝不相容的请求2.两段式锁协议

所谓"两段式协议"名字的来源出于如下事实:

一个进程分为两个阶段，在第一个阶段，该进程放置的锁的数目稳定的增长，全是加锁；

第二个阶段只能释放锁，而且是一起释放。必须遵守的两段式协议的内容:(1)一个数据单元在第一次被访问之前必须对它加锁。(2)如果一个数据单元已经有了一个共享锁，只能对它再附加共享锁。假如它有了一个独占锁，不能再对它附加任何锁。(3)由一个进程设置的所有锁，只能在该进程结束时释放，而且要一起释放。

DBMS通过拦截从事务来的操作满足第一条。第三条在事务结束时实现。3.封锁策略(1)

DBMS封锁数据单元的策略有如下几种：(1)封锁一个数据单元意味着封锁了它的所有后代单元。这种策略实现起来很困难。因为一个单元的后代单元可能又是其他单元的后代，因此，在封锁该数据单元的同时要找出它的所有后代单元，同时给予加锁。释放时要同时释放。3.封锁策略(1)(2)封锁一个数据单元，只封锁该单元本身，并不涉及它的后代。这种方法实现简单，但要采用一些其他手段保证数据的完整性。例如，当某数据单元是其他多个数据单元的组成部分时，容易引起冲突。3.封锁策略(2)(3)关系数据库管理系统中，采用分层封锁策略，即封锁了上层节点就意味着封锁了所有内层节点。 例如，如果有事务T1已经对关系R中的某元组加了S锁，而事务T2要对该元组所在的关系R加X锁，因而隐含地需要用X锁封锁该元组，这两个事务就会产生矛盾。

4.封锁的粒度(1) 数据库中某独立部分数据称为一个数据单元，关系数据库中，一个数据单元小到可以是一个数据项、一个元组、一个关系，大到一个存储域，直至一个数据库。封锁单元的大小称为封锁粒度(Granularity)。4.封锁的粒度(1)

封锁的单元可以是逻辑单元，也可以是物理单元。关系数据库中的逻辑单元为：属性值、元组、关系、某索引项、整个索引、直至整个数据库。关系数据库中的物理单元为：页（数据页或索引页）和存储区。4.封锁的粒度(2)

封锁的粒度、系统的并发度和并发控制的开销密切相关。封锁的粒度越大，数据库所能够封锁的数据单元就越少，并发度越小，系统开销也越小，并行度也就越低。

反之，封锁粒度越小，并行度越高，系统管理锁的开销也越大，实现起来也更加困难。因此，在封锁单元的大小、并行度和管理锁的开销之间要进行权衡。

4.封锁的粒度(2)从用户的角度看，如果在一个系统中同时支持多种封锁粒度供不同的事务选择是比较理想的，这种封锁方法称为多粒度封锁（MultipleGranularityLocking）。多粒度锁数据库DB...…

图8-5分层多粒度树关系Rn关系R1元组m元组1属性k属性1...5死锁一个事务如果申请锁而未获准，则须等待其他事务释放锁。这就形成了事务间的等待关系。当事务中出现循环等待时，如果不加干预，则会一直等待下去，即出现死锁现象。

死锁发生时，至少有两个或多个事务同时处于等待状态，每个事务都在等待其他事务释放锁才可继续执行。事务相互等待示例R2R1R3T1已占有资源T3已占有资源T2已占有资源图8-7(2)死锁的解决办法解决死锁一般采用两个方法：死锁的预防死锁的检测与解除(3)死锁的预防预防死锁的方法较多，如：(1)一次封锁法：一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。(3)死锁的预防(2)顺序封锁法：顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实现封锁。例如，在图8-7中，如果封锁的次序都是R1-R2，就不会出现死锁，因为在T1没有结束之前，T2不可能开始。(4)死锁的检测与解除(1)如果允许数据库中出现死锁，应尽可能及时发现和处理，死锁的检测一般使用超时法或等待图法。(1)超时法：如果一个事务的等待时间超过了规定的时限，则认为发生了死锁。(4)死锁的检测与解除(1)(2)等待图法：事务等待图是一个有向图G=(T,U)，T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2，则T1，T2之间有一条有向边，从T1指向T2。如果发现图中存在回路，则表示系统中出现了死锁。发现死锁后，靠事务本身无法打破死锁，必须由DBMS干预。DBMS对死锁