第6章 管理数据库.ppt

1、2020/8/31,1,数据库原理与设计,第6章 管理数据库,2020/8/31,数据库的安全管理 数据库的完整性管理 SQL SERVER数据库恢复 并发控制,第4章 数据库保护,2020/8/31,数据的安全性控制指防止非法用户对数据进行访问，以保证数据库的数据不会由于非法使用而造成数据的泄漏、更改和破坏。 数据库安全必须从以下几个级别上设置安全措施： （1）环境级 （2）职员级 （3）操作系统级 （4）网络级 （5）数据库系统级,6.1 数据库的安全管理,6.1.1 安全性概述,2020/8/31,6.1 数据库的安全管理,6.1.2 数据库管理系统的身份识别机制,数据库管理系统通过用户

2、标识（用户名）来识别用户的身份，以管理和决定一个用户在数据库中的操作权限。在一个运行的数据库管理系统实例下可以建立和管理多个数据库，身份识别实际上有3个层次 ，具体如下： （1）一个用户要访问某个数据库必须首先登录到数据库管理系统，即必须首先有一个登录（login）身份。 （2）每个登录用户不一定能够访问所有的数据库，对其能够访问的数据库还需要有数据库用户（database user）身份。 （3）一个数据库用户并不意味着他在这个数据库上可以进行任何操作，数据库用户的任何操作都必须首先得到相应的授权。,2020/8/31,6.1 数据库的安全管理,6.1.3 SQL Server的用户和角色管

3、理,（1）概述 用户管理有两个层次，一是由系统管理员管理的登录用户，二是由数据库管理员管理的数据库用户。 在一个系统或一个数据库上会有很多用户，每个用户可能有独立的职责，也可能很多用户有相同或相近的职责，即不同的用户可能担当相同的角色。为了避免管理每个单个用户的繁琐，可以通过角色管理使权限管理变得简单、清晰。SQL Server为了方便系统和数据库管理预定了固定的服务器角色和数据库角色。,2020/8/31,6.1 数据库的安全管理,6.1.3 SQL Server的用户和角色管理,（2）服务器角色 服务器级角色的权限作用域为服务器范围。数据库管理员将相应的权限赋予角色，然后再将角色赋给登录用

4、户，从而使登录用户拥有了相应的权限。 SQL Server 2008提供了9种固定的服务器角色，如下： Sysadmin 、Serveradmin、 Securityadmin、 Processadmin、 Setupadmin、 Bulkadmin、 Diskadmin、 Dbcreator和 public 。,2020/8/31,（3）数据库角色 数据库的角色分为固定数据库角色和用户定义的数据库角色。固定数据库角色指SQL Server为每个数据库提供的角色。各固定数据库角色的权限如下： db_owner：在数据库中有全部权限。 db_accessadmin：负责数据库用户的管理。 db_

5、securityadmin：负责数据库的安全管理等。 db_ddladmin：主要负责数据库的完整性和一致性检查及管理。 db_backupoperator：主要负责数据库的备份和恢复。 db_datareader：可以查询数据库中任何用户表中的所有数据。 db_ data writer：可以更改数据库中任何用户表中的所有数据。 db_denydatareader：不能查询数据库中任何用户表中的任何数据。 db _ denydatawriter：不能更改数据库中任何用户表中的任何数据。,6.1 数据库的安全管理,6.1.3 SQL Server的用户和角色管理,2020/8/31,6.1 数据

6、库的安全管理,6.1.4 SQL Server的安全认证模式,（1）Windows 安全认证模式 （2）SQL Server 认证模式 （3）混合认证模式,2020/8/31,6.2 数据库的完整性管理,6.2.1 完整性约束,数据库的完整性是为了保证数据库中存储的数据的正确性，包括数据的合法性、有效性和相容性三个方面。 数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。在关系系统中，最重要的完整性约束是实体完整性和参照完整性，其他完整性约束条件都可归入用户定义的完整性。,完整性约束可以分为6类：静态列级约束、静态元组约束、静态关系约束、动态列级约

7、束、动态元组约束、动态关系约束。动态约束通常由应用软件来实现。,2020/8/31,6.2 数据库的完整性管理,6.2.1 完整性约束,2020/8/31,6.2 数据库的完整性管理,6.2.2 完整性控制,完整性控制包括完整性约束条件定义机制、完整性检查机制和违约反应三部分。 （1）完整性约束条件定义机制 完整性约束条件是数据模型的一个重要组成部分，它约束了数据库中数据的语义。DBMS应给用户提供根据现实世界的语义定义数据库的约束条件的手段，并允许用户把这些完整性约束条件作为模式的一部分存入数据库中。 （2）完整性检查机制 完整性检查机制检查用户发出的操作请求是否违背了完整性约束条件。 （3

8、）违约反应 违约反应保证了在发现用户的操作请求使数据违背了完整性约束条件后，采取一定的动作来保证数据的完整性。,2020/8/31,完整性规则从执行时间上可分为立即执行约束（Immediate Constraints）和延迟执行约束（Deferred Constrainsts）。 立即执行约束是指在执行用户事务过程中，某一条语句执行完成后，系统立即对此数据进行完整性约束条件检查。 延迟执行约束是指在整个事务执行结束后，再对约束条件进行完整性检查，结果正确后才能提交。 某一条语句执行完成后，系统立即对此数据进行完整性约束条件检查。,立即执行约束和延迟执行约束,2020/8/31,例如，银行数据库

9、中“借贷总金额应平衡”的约束就应该属于延迟执行约束，从账号A转一笔钱到账号B为一个事务，从账号A转出去钱后，账就不平了，必须等转入账号B后，账才能重新平衡，这时才能进行完整性检查。,立即执行约束和延迟执行约束(2),2020/8/31,实现参照完整性应解决的问题,（1） 外码能否接受空值问题 （2） 在被参照关系中删除元组的问题 步级联删除（CASCADES） 受限删除（RESTRICTED） 置空值删除（NULLIFIES） （3）在参照关系中插入元组时的问题 受限插入 递归插入 （4）修改关系中主码的问题 不允许修改主码 允许修改主码,2020/8/31,6.2 数据库的完整性管理,6.2

10、.3 SQL Server数据完整性的实现方法,SQL Server实现数据完整性的主要方法有4种：约束、默认、规则和触发器。,（1）约束 约束通过限制列中的数据、行中的数据和表之间数据来保证数据完整性。SQL Server约束的5种类型和完整性功能。,2020/8/31,6.2 数据库的完整性管理,6.2.3 SQL Server数据完整性的实现方法,（2）触发器 触发器是一种功能强、开销高的数据完整性方法。触发器具有INSERT、UPDATE和DELETE三种类型。一个表可以具有多个触发器。 触发器的用途是维护行级数据的完整性。与CHECK约束相比，触发器能强制实现更加复杂的数据完整性，能

11、执行操作或级联操作，能实现多行数据间的完整性约束，能按定义动态地、实时地维护相关的数据。,2020/8/31,6.2 数据库的完整性管理,6.2.3 SQL Server数据完整性的实现方法,（3）默认与规则 默认（DEFAULT）和规则（RULE）都是数据库对象。当它们被创建后，可以绑定到一列或几列上，并可以反复使用。当使用INSERT语句向表中插入数据时，如果有绑定DEFAULT的列，系统就会将DEFAULT指定的数据插入；如果有绑定RULE的列，则所插入的数据必须符合RULE的要求。 默认可以绑定到一列或多列上或用户自定义的数据类型上，其作用类似于DEFAULT约束，能为INSERT语句

12、中没有指定数据的列提供事先定义的默认值。默认值可以是常量、内置函数或数学表达式。,2020/8/31,数据库恢复的含义 虽然数据库系统中已采取一定的措施，来防止数据库的安全性和完整性的破坏，保证并发事务的正确执行，但数据库中的数据仍然无法保证绝对不遭受破坏，比如计算机系统中硬件的故障、软件的的错误，操作员的失误，恶意的破坏等都有可能发生，这些故障的发生影响数据库数据的正确性，甚至可能破坏数据库，使数据库中的数据全部或部分丢失。 因此，系统必须具有检测故障并把数据从错误状态中恢复到某一正确状态的功能，这就是数据库的恢复。,6.3 恢复,2020/8/31,6.3.1 恢复的原理,1故障的种类 （

13、1）事务内部的故障 事务故障表示由非预期的、不正常的程序结束所造成的故障。 造成程序非正常结束的原因包括输入数据错误、运算溢出、违反存储保护、并行事务发生死锁等。 发生事务故障时，被迫中断的事务可能已对数据库进行了修改，为了消除该事务对数据库的影响，要利用日志文件中所记载的信息，强行回滚（ROLLBACK）该事务，将数据库恢复到修改前的初始状态。,2020/8/31,（2）系统故障,系统故障是指系统在运行过程中，由于某种原因，造成系统停止运转，致使所有正在运行的事务都以非正常方式终止，要求系统重新启动。 引起系统故障的原因可能有：硬件错误如CPU故障、操作系统或DBMS代码错误、突然断电等。

14、这时，内存中数据库缓冲区的内容全部丢失，存储在外部存储设备上的数据库并未破坏，但内容不可靠了。,2020/8/31,（3）介质故障,介质故障通常称为硬故障（Hard Crash）。硬故障指外存故障，例如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。 对付这类故障，一方面需要尽可能提高硬件系统的可靠性，但这种提高是有限的。另一方面，在系统发生此类故障后，可以利用冗余的数据备份将系统恢复到先前一致的状态。,2020/8/31,（4）计算机病毒,计算机病毒是一种人为的故障或破坏，是一些

15、恶作剧者编写的一种计算机程序。这种程序可以繁殖和传播，并造成对计算机系统包括数据库的危害。 计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。,2020/8/31,数据库恢复的基本原理十分简单，就是数据的冗余。 数据库中任何一部分被破坏的或不正确的数据都可以利用存储在系统其他地方的冗余数据来修复。 因此恢复系统应该提供两种类型的功能： 一种是生成冗余数据，即对可能发生的故障作某些准备； 另一种是冗余重建，即利用这些冗余数据恢复数据库。 生成冗余数据最常用的技术是登记日志文件和数据转储，在实际应用中，这两种方法常常结合起来一起使用。,6.3.1 恢复的原理,2020/8/31,

16、6.3.2 恢复的实现,1数据转储 数据转储是指定期地将整个数据库复制到多个存储设备如磁带、磁盘上保存起来的过程，它是数据库恢复中采用的基本手段。 转储的数据文本称为后备副本或后援副本，当数据库遭到破坏后就可利用后援副本把数据库有效地加以恢复。 转储是十分耗费时间和资源的，不能频繁地进行，应该根据数据库使用情况确定一个适当的转储周期。,2020/8/31,用数据库副本恢复数据库,数据转储与恢复,2020/8/31,（1）静态转储和动态转储 静态转储期间不允许有任何数据存取活动，因而需在当前用户事务结束之后进行，新用户事务又需在转储结束之后才能进行，这就降低了数据库的可用性。 动态转储指转储期间

17、允许对数据库进行存取和修改，即转储和用户事务可并发执行。 （2）海量转储和增量转储 海量转储是指每次转储全部数据库； 增量转储则指每次只转储上一次转储后更新过的数据。,数据转储,2020/8/31,数据转储方法,表4.9 数据转储方法,2020/8/31,日志文件是用来记录事务对数据库的更新操作的文件。对数据库的每次修改，都将被修改项目的旧值和新值写在一个叫做运行日志的文件中，目的是为数据库的恢复保留详细的数据。 （1）日志文件的格式和内容 日志文件是用来记录事务对数据库的更新操作的文件。不同数据库系统采用的日志文件格式也不完全一样。一般日志文件主要有两种格式：以记录为单位的日志文件和以数据块

18、为单位的日志文件。,2.登记日志文件（Logging）,2020/8/31, 以记录为单位的日志文件,对于以记录为单位的日志文件，日志文件中需要记录各个事务的开始（BEGIN TRANSACTION）标记、结束（COMMIT或ROLLBACK）标记和所有更新操作。这里每个事务开始的标记、每个事务的结束标记和每个更新操作均作为日志文件中的一条日志记录（log record）。 每条日志记录的内容主要包括：事务标识（标明是哪个事务）、操作类型（插入、删除或修改）、操作对象（记录内部标识）、更新前数据的旧值（对插入操作而言，此项为空值）、更新后数据的新值（对删除操作而言，此项为空值），例如： （T0

19、1; update; Student (age); 23; 24),2020/8/31, 以数据块为单位的日志文件,对于以数据块为单位的日志文件，日志记录的内容包括事务标识和被更新的数据块。由于将更新前的整个块和更新后的整个块都放入日志文件中，操作的类型和操作对象等信息就不必放入日志记录中。,2020/8/31,（2）日志文件的作用, 事务故障恢复和系统故障必须用日志文件。 在动态转储方式中必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库。 在静态转储方式中，也可以建立日志文件。当数据库被毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件，把已完成的

20、事务进行重做处理，对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务就可把数据库恢复到故障前某一时刻的正确状态。,2020/8/31,（3）登记日志文件的原则,登记的次序严格按并发事务执行的时间次序。 必须先写日志文件，后写数据库。,2020/8/31,3恢复策略,数据库系统在运行中发生故障后，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库。 这时数据库就处于一种不正确的状态，或者说是不一致的状态，这时可利用日志文件和数据库转储的后备副本将数据库恢复到故障前的某个一致性状态。 根据故障类型的不同，应该采取不同的恢复策略。,2020/8

21、/31,事务故障是指事务在运行至正常终止点前被终止，这时恢复子系统应利用日志文件撤销（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤如下。 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则做删除操作（因此时“更新前的值”为空）；若记录中是删除操作，则做插入操作；若是修改操作，则要用修改前值代替修改后值。 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。 如此处理下去，直至读到此事务的开始标记，事务故障恢复

22、就完成了。,（1）事务故障的恢复,2020/8/31,系统故障发生后，对数据库的影响有两种情况： 一种情况是一些未完成事务对数据库的更新已写入数据库，这样在系统重新启动后，要强行撤消（UNDO）所有未完成事务，清除这些事务对数据库所做的修改。这些未完成事务在日志文件中只有BEGIN TRANSCATION标记，而无COMMIT标记。 另一种情况是有些己提交的事务对数据库的更新结果还保留在缓冲区中，尚未写到磁盘上的物理数据库中，这也使数据库处于不一致状态，因此应将这些事务己提交的结果重新写入数据库。这类恢复操作称为事务的重做（REDO）。这种己提交事务在日志文件中既有BEGIN TRANSCAT

23、ION标记，也有COMMIT标记。 因此，系统故障的恢复要完成两方面的工作，既要撤消所有未完成的事务，还需要重做所有己提交的事务，这样才能将数据库真正恢复到一致的状态。,（2）系统故障的恢复,2020/8/31,具体做法如下： 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录），将其事务标识记入撤销队列。 对撤销队列中的各个事务进行撤销（UNDO）处

24、理。 进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。 对重做队列中的各个事务进行重做（REDO）处理。 进行REDO处理的方法是，正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”写入数据库。,（2）系统故障的恢复(2),2020/8/31,登记日志文件顺序,恢复过程,（2）系统故障的恢复(3),2020/8/31,（3）介质故障的恢复,发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。 装入最新的数据库后备副

25、本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。 对于动态转储的数据库副本，还需同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。 装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。然后正向扫描日志文件，对重做队列中的所有事务进行重做处理，将日志记录中“更新后的值”写入数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态了。 介质故障的恢复需要数据库管理员介入。具体的恢复操作仍由DBMS完成。,2020/

26、8/31,4具有检查点的恢复技术,利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要REDO，哪些事务需要UNDO。原则上需要检查所有日志记录。但这样做会引起两个问题。 搜索整个日志将耗费大量的时间，数据库系统可能难以承受。 大多数需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了，然而恢复子系统又重新执行了这些操作，浪费了大量时间。 为了解决这些问题，提出了具有检查点的恢复技术。这种技术在日志文件中增加一类新的记录检查点（checkpoint）记录，增加一个重新开始文件，恢复子系统在登录日志文件期间动态地维护日志。,2020/8/31, 检查点记录的内容,

27、建立检查点时刻所有正在执行的事务清单； 这些事务最近一个日志记录的地址； 重新开始文件用来记录各个检查点记录在日志文件中的地址。,2020/8/31,动态维护日志文件的方法,动态维护日志文件的方法是周期性地执行如下操作： 将当前日志缓冲中的所有日志记录写入磁盘的日志文件上； 在日志文件中写入一个检查点记录； 将当前数据缓冲的所有数据记录写入磁盘的数据库中； 把检查点记录在日志文件中的地址写入一个重新开始文件。,2020/8/31,6.3.1 数据库复制与数据库镜像,(1) 数据库复制 数据库复制是使数据库更具容错性的方法，主要用于分布式数据库系统。复制是将整个数据库或数据库的子集复制到网络中的

28、其他服务器上，使这部分数据在不同地点拥有多个备份。这样做有助于消除网络拥挤，提高多个服务器之间的数据访问速度。例如，可以将用于报表的重要数据从事务处理繁忙的服务器中移出。,2020/8/31,复制的过程一般通过发送每个活动事务日志记录的方式来进行，在接收服务器上会尽快按日志记录顺序将其应用到本地数据库中，保证数据库的一致性。 当数据库出现故障时，系统可以采用副本对其进行联机恢复，而在恢复过程中用户可以继续访问数据库的副本，而不必中断应用。 数据库复制的过程类似于报纸杂志的出版过程，即把信息从信息源迅速传送到信息接收处，因此也称复制模型为出版/订阅模型。其中，提供数据的过程称为出版，提供数据给其

29、他服务器使用的服务器称为出版服务器。把数据从出版服务器发送到信息接收处（订阅服务器）的过程称为分发。请求数据称为订阅。,2020/8/31,复制方式,（1）对等复制（peer-to-peer） 对等复制是最理想的复制方式。在对等复制方式中，各个数据库副本的地位是平等的，可以相互复制数据。用户可以在任何场地读取和更新公共数据集，而且不管在哪个数据库进行数据更新，DBMS都会立即将数据传送给所有其他副本。 （2）主/从复制（master/slave） 主/从复制指数据只能从主数据库复制到从数据库中。在这种方式中，只能在主数据库中更新数据，其他副本数据库只供用户读取数据。在主数据库出现故障时，更新数

30、据的操作可以转到另一数据库副本上进行。这种复制方式实现起来比较简单，易于维护数据一致性。主数据库与各个数据库副本在任何时候都必须保持事务的完整性。 （3）级联复制（cascade） 级联复制（cascade）是指某数据库副本从主数据库中复制过来的数据又从该数据库再次复制到其他数据库副本。例如，从数据库A把数据复制到数据库B，再从数据库B把这些数据或其中部分数据复制到数据库C。级联复制可以平衡当前各种数据需求对网络交通的压力。,2020/8/31,(2) 数据库镜像,数据库镜像（Mirror）根据数据库管理员的要求，自动把整个数据库或其中的关键数据复制到不同环境的另一个数据库中。每当主数据库更新

31、时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。这样，一旦出现介质故障，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。在没有出现故障时，数据库镜像还可以用于并发操作，即当一个用户对数据加排它锁修改数据时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。,2020/8/31,完整性是保证各个事务本身能得到正确的数据，只考虑一个用户使用数据库的情况，但实际上数据库中有许多用户。 每个用户在存取数据库中的数据时，可能是串行执行，即每个时刻只有一个用户程序运行，也可能是多个用户并行地存取数据库。

32、 数据库的最大特点之一就是数据资源是共享的。 为了充分利用数据库资源，很多时候数据库用户都是对数据库系统并行存取数据，这样就会发生多个用户并发存取同一数据块的情况，如果对并发操作不加控制可能会产生不正确的数据，破坏数据的完整性，并发控制就是解决这类问题，以保持数据库中数据的一致性。,6.4 并发控制,2020/8/31,1事务（Transaction） 事务（Transaction）是数据库的逻辑工作单元，它是一组对数据操作的序列，这些操作要么全做要么全不做。事务是并发控制的基本单位。 事务是由有限的数据库操作序列组成，但并不是任意的数据库操作序列都能成为事务，为了保护数据的完整性，一般要求事

33、务具有以下四个特征： 原子性 一致性 隔离性 持续性,6.4.1 并发控制概述,2020/8/31, 原子性（Atomicity），即一个事务是不可分割的数据库逻辑工作单位。 一致性（Consistency），事务的执行结果必须使数据库从一个一致性状态变到另一个一致性状态。 隔离性（Isolation），一个事务的执行不能被其他事务干扰。 持续性（Durability），持续性也称为永久性，指一个事务一旦提交，它对数据库中数据的改变应该是永久性的，其他操作或故障不对其产生任何影响。,事务的特征,2020/8/31,2事务的状态,一般将事务的执行状态分为5种 活动状态：事务的初始状态，事务执行时

34、处于这个状态。 部分提交状态：当操作序列的最后一条语句自动执行后，事务处于部分提交状态。这时，事务虽然已经完全执行，但由于实际输出可能还驻留在内存中，而在事务成功完成前仍有可能出现硬件故障，事务仍可能不得不中止。因此，事务处于部分提交状态不表示事务成功执行。 失败状态：由于硬件或逻辑等错误，使得事务不能继续正常执行，事务就进入了失败状态，处于失败状态的事务必须回滚（ROLLBACK）。这样，事务就进入了中止状态。 中止状态：事务回滚并且数据库恢复到事务开始执行前的状态。 提交状态：当事务成功完成后，称事务处于提交状态（COMMIT）。,2020/8/31,3SQL中的事务定义,在SQL中定义事

35、务的语句有BEGIN TRANSACTION、COMMIT、ROLLBACK。事务以BEGIN TRANSACTION语句开始，以COMMIT（事务提交）或ROLLBACK（回滚）结束。提交即提交事务的所有操作，将事务中所有对数据库的更新写回到物理数据库，事务正常结束。回滚表示在事务运行中发生了某种故障，事务不能继续执行，系统将事务中对数据库已完成的所有操作（指更新操作）全部撤销，回滚到事务开始时的状态。,2020/8/31,下面是一个事务的例子，从帐号A转移资金额R到帐号B： BEGIN TRANSACTION READ A AA-R IF A0/* A 款不足*/ THEN BEGIN D

36、ISPLAY “A款不足” ROLLBACK END ELSE /* 拨款 */ BEGIN BB+R DISPLAY “拨款完成” COMMIT END,3SQL中的事务定义(2),2020/8/31,这是对一个简单事务的完整的描述。 该事务有两个出口： 当A 帐号的款项不足时，事务以ROLLBACK（撤销）命令结束，即撤销该事务的影响； 另一个出口是以COMMIT（提交）命令结束，完成从帐号A到帐号B的拨款。 在COMMIT之前，即在数据库修改过程中，数据可能是不一致的，事务本身也可能被撤销。 只有在COMMIT之后，事务对数据库所产生的变化才对其他事务开放，这就可以避免其他事务访问不一致

37、或不存在的数据。,3SQL中的事务定义(3),2020/8/31,4事务的调度的一般概念,（1）调度（schedule） （2）串行调度（serial schedule） （3）并行调度（concurrent schedule） 交叉并发方式（interleaved concurrency），指在单处理机系统中，多个并行事务的操作轮流交叉运行，从而减少处理机的空闲时间，提高系统的效率。 多处理机系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行。这是最理想的并发方式，但对于硬件环境要全较高。,2020/8/31,例1并发取款操作。假设存款余额R=10

38、00元，甲事务T1取走存款100元，乙事务T2取走存款200元，如果正常操作，即甲事务T1执行完毕再执行乙事务T2，存款余额更新后应该是700元。但是如果按照如下顺序操作，则会有不同的结果： 甲事务T1读取存款余额R =1000元； 乙事务T2读取存款余额R =1000元； 甲事务T1取走存款100元，修改存款余额R =R 100=900，把R =900写回到数据库； 乙事务T2取走存款200元，修改存款余额R =R 200=800，把R =800写回到数据库。,5并发所引起的问题,2020/8/31,结果两个事务共取走存款300元，而数据库中的存款却只少了200元。 得到这种错误的结果是由甲

39、乙两个事务并发操作引起的，数据库的并发操作导致的数据库不一致性主要有以下三种： （1）丢失更新（Lost Update） 当两个事务T1和T2读入同一数据做修改，并发执行时， T2把T1或T1把T2的修改结果覆盖掉，,5并发所引起的问题(2),2020/8/31,造成了数据的丢失更新问题，导致数据的不一致。 仍以例中的操作为例进行分析。 在表4.1中，数据库中R的初值是1000，事务T1包含三个操作：读入R初值（FIND R）；计算（R=R-100）；更新R（UPDATE R）。 事务T2也包含三个操作：FIND R；计算（R=R-200）；UPDATE R。 如果事务T1和T2顺序执行，则更

40、新后，R的值是700。但如果T1和T2按照表4.1所示的并发执行，R的值是800，得到错误的结果，原因在于在t7时刻丢失了T1对数据库的更新操作。 因此，这个并发操作不正确。,（1）丢失更新,2020/8/31,表4.1 丢失更新问题,（1）丢失更新(2),2020/8/31,事务T1更新了数据R，事务T2读取了更新后的数据R，事务T1由于某种原因被撤消，修改无效，数据R恢复原值。事务T2得到的数据与数据库的内容不一致，这种情况称为“污读”。 在表4.2中，事务T1把R的值改为900，但此时尚未做COMMIT操作，事务T2将修改过的值900读出来，之后事务T1执行ROLLBACK操作，R的值恢

41、复为1000，而事务T2将仍在使用已被撤消了的R值900。 原因在于在t4时刻事务T2读取了T1未提交的更新操作结果，这种值是不稳定的，在事务T1结束前随时可能执行ROLLBACK操作。 对于这些未提交的随后又被撤消的更新数据称为“脏数据”。比如，这里事务T2在t2时刻读取的就是“脏数据”。,（2）脏读（Dirty Read）,2020/8/31,（2）脏读（Dirty Read）(2),2020/8/31,事务T1读取了数据R，事务T2读取并更新了数据R，当事务T1再读取数据R以进行核对时，得到的两次读取值不一致，这种情况称为“不可重读”。 在表4.3中，在t0时刻事务T1读取R的值为100

42、0，但事务T2在t4时刻将R的值更新为为800。所以T1所使用的值已经与开始读取的值不一致。,表4.3 不可重读问题,（3）不可重读（Unrepeatable Read）,2020/8/31,1调度策略对事务并发操作的影响 如果有两个事务T1、T2分别对数据X，Y进行赋值操作，由于事务的不同调度，引起了不同的结果，如图所示。已知X，Y的初值均为0。,6.4.2 并发操作的调度,2020/8/31,2将所有事务串行起来的调度策略一定是正确的调度策略,定义4.1 多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行它们时的结果相同，我们称这种调度策略为可串行化（Serializable

43、）的调度。 可串行性（Serializability）是并发事务正确性的准则。按这个准则规定，一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度。 为了保证并发操作的正确性，DBMS的并发控制机制必须提供一定的手段来保证调度是可串行化的。目前DBMS普遍采用封锁方法实现并发操作调度的可串行性，从而保证调度的正确性。,2020/8/31,1封锁及锁的类型 所谓封锁就是当一个事务在对某个数据对象（可以是数据项、记录、数据集、以至整个数据库）进行操作之前，必须获得相应的锁，以保证数据操作的正确性和一致性。 封锁的3个环节：申请加锁，获得锁，释放锁。 基本的封锁类型有2种：排它锁（Exclu

44、sive Locks，也称X锁）和共享锁（Share Locks，也称S锁）。,6.4.3 封锁,2020/8/31,排它锁（Exclusive Lock） 排它锁又称写锁，简称为X锁，其采用的原理是禁止并发操作。 当事务T对某个数据对象R实现X封锁后，其他事务要等T解除X封锁以后，才能对R进行封锁。这就保证了其他事务在T释放R上的锁之前，不能再对R进行操作。 共享锁（Share Lock） 共享锁又称读锁，,简称为S锁，其采用的原理是允许其他用户对同一数据对象进行查询，但不能对该数据对象进行修改。 当事务T对某个数据对象R实现S封锁后，其他事务只能对R加S锁，而不能加X锁，直到T释放R上的S

45、锁。 这就保证了其他事务在T释放R上的S锁之前，只能读取R，而不能再对R作任何修改。,基本的封锁类型,2020/8/31,封锁可以保证合理的进行并发控制，保证数据的一致性。 实际上，锁是一个控制块，其中包括被加锁记录的标识符及持有锁的事务的标识符等。 在封锁时，要考虑一定的封锁规则，例如，何时开始封锁、封锁多长时间、何时释放等,这些封锁规则称为封锁协议。 对封锁方式规定不同的规则，就形成了各种不同的封锁协议。 封锁协议在不同程序上对正确控制并发操作提供了一定的保证。 上面讲述过的并发操作所带来的丢失更新、污读和不可重读等到数据不一致性问题，可以通过三级封锁协议在不同程度上给予解决，下面介绍三级

46、封锁协议。,2 .锁协议（Lock Protocol）,2020/8/31,一级封锁协议的内容是：事务T在修改数据对象之前必须对其加X锁，直到事务结束。 具体地说，就是任何企图更新记录R的事务必须先执行“XLOCK R”操作，以获得对该记录进行寻址的能力并对它取得X封锁。 如果未获准“X 封锁”，那么这个事务进入等待状态，一直到获准“X封锁”，该事务才继续做下去。 该事务规定事务在更新记录R时必须获得排它性封锁，使得两个同时要求更新R的并行事务之一必须在一个事务更新操作执行完成之后才能获得X封锁，这样就避免了两个事务读到同一个R值而先后更新时所发生的丢失更新问题。,一级封锁协议,2020/8/

47、31,利用一级封锁协议可以解决表4.5中的数据丢失更新问题，如表4.4所示。 事务T1先对R进行X封锁（XLOCK），事务T2执行“XLOCK R”操作，未获准“X封锁”，则进入等待状态，直到事务T1更新R值以后，解除X封锁操作（UNLOCK X）。 此后事务T2再执行“XLOCK R”操作，获准“X封锁”，并对R值进行更新（此时R已是事务T1更新过的值，R=900）。 这样就能得出正确的结果。,一级封锁协议(2),2020/8/31,一级封锁协议(3),一级封锁协议只有当修改数据时才进行加锁，如果只是读取数据并不加锁，所以它不能防止“脏读”和“重读”数据。,2020/8/31,二级封锁协议的

48、内容是：在一级封锁协议的基础上，另外加上事务T在读取数据R之前必须先对其加S锁，读完后释放S锁。 所以二级封锁协议不但可以解决更新时所发生的数据丢失问题，还可以进一步防止“脏读”。 利用二级封锁协议可以解决表4.2中的数据“脏读”问题，如表4.5所示。 事务T1先对R进行X封锁（XLOCK），把R的值改为900，但尚未提交。这时事务T2请求对数据R加S锁，因为T1已对R加了X锁，T2只能等待，直到事务T1释放X锁。,二级封锁协议,2020/8/31,之后事务T1因某种原因撤销，数据R恢复原值1000，并释放R上的X锁。事务T2可对数据R加S锁，读取R=1000，得到了正确的结果，从而避免了事务

49、T2读取“脏数据”。,二级封锁协议(2),2020/8/31,二级封锁协议在读取数据之后，立即释放S锁，所以它仍然不能防止“重读”数据。 三级封锁协议的内容是：在一级封锁协议的基础上，另外加上事务T在读取数据R之前必须先对其加S锁，读完后并不释放S锁，而直到事务T结束才释放。 所以三级封锁协议除了可以防止更新丢失问题和“污读”数据外，还可进一步防止不可重读数据，彻底解决了并发操作所带来的三个不一致性问题。 利用三级封锁协议可以解决表4.3中的不可重读问题，如表4.6所示。, 三级封锁协议,2020/8/31,在表4.6中，事务T1读取R的值之前先对其加S锁，这样其他事务只能对R加S锁，而不能加

50、X锁，即其他事务只能读取R，而不能对R进行修改。 所以当事务T2在t3时刻申请对R加X锁时被拒绝，使其无法执行修改操作，只能等待事务T1释放R上的S锁，这时事务T1再读取数据R进行核对时，得到的值仍是1000，与开始所读取的数据是一致的，即可重读。 在事务T1释放S锁后，事务T2可以对R加X锁，进行更新操作，这样便保证了数据的一致性。, 三级封锁协议(2),2020/8/31, 三级封锁协议,2020/8/31,3两段锁协议,两段锁协议是保证调度可串行性的协议，该协议要求所有事务必须分两个阶段对数据项加锁和解锁。 扩展阶段：在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁。 收缩

51、阶段：在释放一个封锁之后，事务不再申请和获得任何其他封锁。,2020/8/31,封锁粒度指封锁的单位。 根据对数据的不同处理，封锁的对象可以是这样一些逻辑单元：字段、记录、表、数据库等。 封锁粒度与系统的并发度和并发控制的开销密切相关。 封锁粒度越小，系统中能够被封锁的对象就越多，并发度越高，但封锁机构复杂，系统开销也就越大。相反，封锁粒度越大，系统中能够被封锁的对象就越少，并发度越小，封锁机构简单，相应系统开销也就越小。 因此，在实际应用中，选择封锁粒度时应同时考虑封锁机构和并发度两个因素，对系统开销与并发度进行权衡，以求得最优的效果。 由于同时封锁一个记录的概率很小，一般数据库系统都在记录

52、级上进行封锁，以获得更高的并发度。,4.封锁的粒度（Lock Granularity）,2020/8/31,封锁技术可有效解决并行操作的一致性问题，但也可产生新的问题，即活锁和死锁问题。 1活锁（Livelock） 当某个事务请求对某一数据的排它性封锁时，由于其他事务对该数据的操作而使这个事务处于永久等待状态，这种状态称为活锁。 例如，事务T1在对数据R封锁后，事务T2又请求封锁R，于是T2等待。T3也请求封锁R。当T1释放了R上的封锁后首先批准了T3的请求，T2继续等待。然后又有又T4请求封锁R，T3释放了R上的封锁后又批准了T4的请求T2可能永远处于等待状态，从而发生了活锁。如表4.7所示

53、。,6.4.4 死锁和活锁,2020/8/31,6.4.4 死锁和活锁(2),2020/8/31,避免活锁的简单方法是采用先来先服务的策略，按照请求封锁的次序对事务排队，一旦记录上的锁释放，就使申请队列中的第一个事务获得锁。 有关活锁的问题我们不再详细讨论，因为死锁的问题较为常见，这里主要讨论有关死锁的问题。 2死锁（Deadlock） 在同时处于等待状态的两个或多个事务中，其中的每一个在它能够进行之前，都等待着某个数据、而这个数据已被它们中的某个事务所封锁，这种状态称为死锁。 例如，事务T1在对数据R1封锁后，又要求对数据R2封锁，而事务T2已获得对数据R2的封锁，又要求对数据R1封锁，这样

54、两个事务由于都不能得到封锁而处于等待状态，发生了死锁。如表4.8所示。,4.3.4 死锁和活锁(3),2020/8/31,表4.8 死锁,4.3.4 死锁和活锁(4),2020/8/31,死锁一旦发生，系统效率将会大大下降，因而要尽量避免死锁的发生。 在操作系统的多道程序运行中，由于多个进程的并行执行需要分别占用不同资源时，也会发生死锁。 要想预防死锁的产生，就得破坏形成死锁的条件。 同操作系统预防死锁的方法类似，在数据库环境下，常用的方法有以下两种： （1）一次封锁法 一次加锁法是每个事物必须将所有要使用的数据对象全部依次加锁，并要求加锁成功，只要一个加锁不成功，表示本次加锁失败，则应该立即释放所有已加锁成功的数据对象，然后重新开始从头加锁。 一次加锁法的程序框图如下图。,3死锁的预防,2020/8/31,(1)一次封锁法,2020/8/31,如表4.8发生死锁的例子，可以通过一次加锁法加以预防。 事务T1启动后，立即对数据R1和R2依次加锁，加锁成功后，执行T1，而事务T2等待。 直到T1执行完后释放R1和R2上的锁，T2继续执行。这样就不会发生死锁。 一次加锁法虽然可以有效地预防死锁的