《数据库原理及应用》课件第7章.pptx

1、第7章 数据库管理第7章 数据库管理7.1 数据库管理概述数据库管理概述7.2 数据库恢复技术数据库恢复技术7.3 并发控制并发控制7.4 安全性安全性7.5 完整性完整性本章小结本章小结习题习题7案例三案例三第7章 数据库管理本章主要内容本章主要内容在本章，我们先讨论事务的概念和基本性质，然后再使用事务处理的概念和技术研究数据库恢复技术及SQL Server数据恢复技术和数据库的并发控制及SQL Server的并发控制，最后讨论数据库的安全性和完整性以及SQL Server的安全性管理和SQL Server的完整性策略。第7章 数据库管理本章学习目标本章学习目标 理解并掌握数据库恢复技术。本

2、章介绍了事务的概念和基本性质，数据库转储和登记日志文件，最后介绍了SQL Server数据库恢复技术。熟练掌握并发控制。本章介绍了两类最常见的封锁、三级封锁协议及两段锁协议、死锁和活锁，最后介绍了SQL Server的并发控制。第7章 数据库管理 理解数据库的安全性。本章介绍了与数据库有关的用户标识语鉴别、存取控制、数据库审计等安全技术，最后介绍了SQL Server的安全性管理。理解数据库的完整性。本章首先介绍了DBMS完整性实现的机制，最后介绍了SQL Server的完整性策略。第7章 数据库管理7.1 数据库管理概述数据库管理概述数据库管理(DataBase Administration

3、)是有关建立、修改和存取数据库中信息的技术，是为保证数据库系统的正常运行和服务质量，有关人员必须进行的技术管理工作。负责这些技术管理工作的个人或集体称为数据库管理员(DBA)。数据库管理的主要内容有：数据库的建立、数据库的调整、数据库的重组、数据库的重构、数据库的安全控制、数据库的完整性控制和对用户提供技术支持。第7章 数据库管理数据库系统正确有效运行的过程中，一个很重要的问题就是如何保障数据库的一致性。这就需要数据库管理系统(DBMS)对数据库的各种操作进行监控，因此有必要引入一个逻辑上“最小”的操作单位，以便有效地完成这种监控，这就是引入事务概念的背景。有了事务概念，对数据库操作的监控就是

4、对数据库事务的管理。数据库事务管理的目标是保证数据一致性。事务的并发操作会引起丢失修改、读“脏”数据和不可重复读等基本问题，数据库故障会引起数据的破坏与损失等严重后果。所有这些都将破坏数据库的一致性。因此，事务并发控制和数据库故障恢复就是数据库事务管理中的两项基本课题。第7章 数据库管理数据库的安全性和完整性也属于数据库管理的范畴。一般而言，数据库安全性是指保护数据库以防止非法用户恶意造成的破坏，数据库完整性则是指保护数据库以防止合法用户无意中造成的破坏。也就是说，安全性是确保用户被限制在其能做的事情的范围之内，完整性则是确保用户所做的事情是正确的。安全性措施的防范对象是非法用户的进入和合法用

5、户的非法操作，完整性措施的防范对象是不合语义的数据进入数据库。第7章 数据库管理7.2 数据库恢复技术数据库恢复技术 7.2.1 事务的概念及特性事务的概念及特性1事务事务(Transaction)的概念的概念1)事务的基本概念事务是用户定义的一个操作序列，这些操作要么全做，要么全不做，它们是一个不可分割的工作单元。数据库事务是指作为单个逻辑工作单元执行的一系列操作。第7章 数据库管理设想网上购物的一次交易，其付款过程至少包括以下数据库操作：(1)更新客户所购商品的库存信息。(2)保存客户付款信息，可能包括与银行系统的交互。(3)生成订单并且保存到数据库中。(4)更新用户相关信息，例如购物数量

6、等。第7章 数据库管理 2)SQL中事务的定义中事务的定义在SQL语言中，定义事务的语句有以下三条：BEGIN TRANSACTION；COMMIT；ROLLBACK。事务通常是以BEGIN TRANSACTION开始，以COMMIT或ROLLBACK结束。COMMIT表示提交，即提交事务的所有操作。具体地说，就是将事务中所有对数据库的更新写回磁盘上的物理数据库中，事务正常结束。第7章 数据库管理 ROLLBACK表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。这里的操作是指对数据库的更新操作。第7章 数据

7、库管理 2事务的特性事务的特性事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功、要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足事务的四个特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持续性(Durability)。这个四个特性也简称为ACID特性。第7章 数据库管理 1)原子性原子性事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系

8、统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。第7章 数据库管理 2)一致性一致性事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此，当数据库只包含成功事务提交的结果时，就说明数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的一致状态。第7章 数据库管理 3)隔离性隔离性一个事务的执行不能被其他事务干扰。例如，对于任何一对事务T1和T2，从T1来看，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行。即一个事务内部的操作及

9、使用的数据对其他并发事务来说是隔离的，且并发执行的各个事务之间不能互相干扰。4)持续性持续性持续性也称永久性(Permanence)，一个事务一旦提交之后，不管DBMS发生什么故障，该事务对数据库的所有更新操作都会永远保留在数据库中，不会丢失。第7章 数据库管理事务是恢复和并发控制的基本单位，保证事务ACID特性是事务处理的重要任务。事务ACID特性可能遭到破坏的因素有：(1)多个事务并行运行时，不同事务的操作交叉执行。(2)事务在运行过程中被强行停止。在第一种情况下，数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原子性。在第二种情况下，数据库管理系统必须保证被强行终止的事务对数据库

10、和其他事务没有任何影响。保证这些就是数据库管理系统中恢复机制和并发机制的责任。第7章 数据库管理 7.2.2 数据库恢复基本概念数据库恢复基本概念当前，计算机硬件、软件技术已经发展到相当高的水平，人们采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并行事务的正确执行。但计算机系统中硬件的故障，系统软件和应用软件的错误，操作员的失误，以及恶意的破坏仍然是不可避免的。这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性；重则破坏数据库，使数据库中全部或部分数据丢失。第7章 数据库管理事务是数据库的基本工作单位。一个事务中包含的操作要么全部完成，要么全部不做，二者必居其一。如果数据

11、库中只包含成功事务提交的结果，就说明此数据库处于一致性状态。保证数据一致性是对数据库的最基本要求。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，此时数据库就处于一种不正确的状态，或者说是不一致状态。这就需要DBMS的恢复子系统根据故障类型采取相应的措施，将数据库恢复到某种一致状态。第7章 数据库管理数据库系统中可能发生各种各样的故障，大致可以分为以下四类：1事务故障(Task Crash)事务故障有些是预期性的，可通过事务程序本身发现，并让事务回滚，撤销错误的修改，恢复数据库到正确状态。事务故障意味着事务没有达到预期的终点(

12、COMMIT或者显示ROLLBACK)，因此数据库可能处于不正确的状态，系统就要强行回滚此事务，即撤销该事务已经做出的任何对数据库的修改，使得该事务好像根本没有启动过一样。第7章 数据库管理2系统故障(软故障，Soft Crash)系统在运行过程中，由于某种原因，如操作系统或DBMS代码错误、操作员操作失误、特定类型的硬件错误(如CPU故障)、突然停电等造成系统停止运行，致使所有正在运行的事务都以非正常方式终止，这时内存中数据库缓冲区的信息全部丢失，但存储在外部存储设备上的数据未受影响，此类型为系统故障。第7章 数据库管理3介质故障(硬故障，Hard Crash)介质故障是指外存故障，如磁盘损

13、坏、磁头碰撞或操作系统的某种潜在错误，瞬时强磁场干扰等，使存储在外存中的数据部分丢失或全部丢失。这类故障比前两类故障的可能性小得多，但破坏性最大。发生介质故障后，需要导入数据库发生介质故障前某个时刻的数据副本，并重做自此时起的所有成功事务，将这些事务已提交的结果重新记入数据库。第7章 数据库管理4计算机病毒计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。为此，计算机安全工作者已研制了许多预防病毒的“疫苗”，检查、诊断、消灭计算机病毒的软件也在不断发展，但至今还没有一种可以使计算机“终生”免疫的疫苗出现。因此，数据库一旦被破坏仍要用恢复技术把数据库恢复到一致状态。第7章 数据

14、库管理7.2.3 恢复实现技术恢复实现技术恢复就是利用存储在系统其他地方的冗余数据来重建数据库中被破坏的或不正确的数据。因此，恢复机制涉及两个关键问题：第一，如何建立冗余数据；第二，如何利用这些冗余数据实施数据库恢复。实现恢复功能主要有以下两方面技术。第7章 数据库管理1数据转储数据转储转储是数据库恢复中采用的基本技术，即数据库管理员(DBA)定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。当数据库遭到破坏后就可以利用后备副本恢复数据库。这时，数据库只能恢复到转储时的状态，从那以后的所有更新事务必须重新运行才能恢复到故障时的状态，如图7.1所

15、示。第7章 数据库管理图7.1 转储和恢复第7章 数据库管理数据转储按操作可分为静态转储和动态转储，按方式可分为海量转储和增量转储，它们的定义、优点、缺点如表7.1所示。第7章 数据库管理2登记日志文件登记日志文件日志文件是用来记录对数据库每一次更新活动的文件。在动态转储方式中，必须建立日志文件的后备副本，它和日志文件综合起来才能有效地恢复数据库。在静态转储方式中，也可以建立日志文件。当数据库毁坏后，可重新装入后备副本把数据库恢复到转储结束时刻的正确状态；然后利用日志文件，对已完成的事务进行重做(Redo)处理，对故障发生时尚未完成的事务进行撤销(Undo)处理。这样不必重新运行那些已完成的事

16、务程序，就可以把数据库恢复到故障前某一时刻的正确状态，如图7.2所示。第7章 数据库管理图7.2 利用日志文件恢复第7章 数据库管理对于以记录为单位的日志文件，日志文件中需登记的内容包括：(1)事务标识。(2)事务开始标记(BEGIN TRANSACTION)和结束标记(COMMIT或ROLLBACK)。(3)操作的类型(插入、删除或修改)。(4)操作对象。(5)更新前数据的旧值(对插入操作，此项为空值)。(6)更新后数据的新值(对删除操作而言，此项为空值)。第7章 数据库管理为保证数据库是可恢复的，登记日志文件必须遵循以下两条原则：(1)登记的次序严格按照并行事务执行的时间次序。(2)必须先

17、写日志文件，后写数据库。第7章 数据库管理利用日志文件恢复事务的过程分为两步：第一步：从头扫描日志文件，找出哪些事务在故障发生时已经结束(这些事务有BEGIN TRANSACTION和COMMIT记录)，哪些事务尚未结束(这些事务只有BEGIN TRANSACTION记录，无COMMIT记录)。第二步：对尚未结束的事务进行撤销(Undo)处理，即反向扫描日志文件，对每个Undo事务的更新操作执行反操作。对已经插入的新记录进行删除操作，对已删除的记录重新插入，对修改的数据恢复旧值(用旧值代替新值)。然后，对已经结束的事务进行重做(Redo)处理，即正向扫描文件，重新执行登记操作。第7章 数据库管

18、理7.2.4 恢复策略恢复策略1事务级故障恢复事务级故障恢复事务故障是指事务运行至正常终止点前被中止。这时，恢复子系统应利用日志文件撤销(Undo)此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。小型故障属于事务内部故障，恢复方法是利用事务的Undo操作，即在事务非正常终止时利用Undo恢复到事务起点。具体有下面两种情况：第7章 数据库管理(1)可以预料到的事务故障，即在程序中可以预先估计到的错误。例如，银行存款余额透支、商品库存量达到最低量等，此时继续取款或者发货就会出现问题。因此，可以在事务的代码中加入判断和回滚语句ROLLBACK，当事务执行到ROLLBAC

19、K语句时，由系统对事务进行回滚操作，即执行Undo操作。(2)不可预料到的事务故障，即在程序中发生的未估计到的错误。例如，运算溢出、数据错误、由并发事务发生死锁而被选中撤销的事务等。此时，由系统直接对事务执行Undo处理。第7章 数据库管理2系统级故障恢复系统级故障恢复系统故障造成数据库不一致状态的原因有两个，一个是尚未完成的事务对数据库的更新可能已写入数据库，另一个是已提交事务对数据库的更新可能还留在缓冲区中没来得及写入数据库。因此，恢复操作就是要撤销故障发生时未完成的事务，重做已完成的事务。第7章 数据库管理系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预。系统恢复的步骤如下：

20、(1)正向扫描日志文件(即从头扫描日志文件)，找出在故障发生前已经提交的事务(这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录)，将其事务标识记入重做(Redo)队列。同时找出故障发生时尚未完成的事务(这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录)，将其事务标识记入撤销队列。第7章 数据库管理(2)对撤销队列中的各个事务进行撤销(Undo)处理。进行Undo处理的方法是，反向扫描日志文件，对每个Undo事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。(3)对重做队列中的各个事务进行重做(Redo)处理。进行Redo处理的

21、方法是，正向扫描日志文件，对每个Redo事务重新执行日志文件登记操作，即将日志记录中“更新后的值”写入数据库。第7章 数据库管理3介质级故障恢复介质级故障恢复发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障。恢复的方法是重装数据库，然后重做已完成的事务。具体如下：(1)装入最新的数据库后备副本(离故障发生时刻最近的转储副本)，使数据库恢复到最近一次转储时的一致性状态。对于动态转储的数据库后备副本，还需要同时装入转储开始时刻的日志文件副本，并利用恢复系统故障的方法(即Redo+Undo)，将数据库恢复到一致性状态。第7章 数据库管理(2)装入相应的日志文件副本(转储结束时刻

22、的日志文件副本)，重做已完成的事务。即首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列；然后正向扫描日志文件，对重做队列中的所有事务进行重做处理，也就是将日志记录中“更新后的值”写入数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态了。第7章 数据库管理事务级故障恢复和系统级故障恢复都是由系统重新启动后自动完成的，不需要用户的介入；而介质级故障恢复需要DBA介入，但DBA的基本工作只是需要重新装入最近存储的数据后备副本和有关日志文件副本，然后执行系统提供的恢复命令，其具体恢复操作实施仍由DBMS完成。第7章 数据库管理7.2.5 数据库镜像数据库镜像1概述概述数据库镜

23、像是SQL Server 2014用于提高数据库可用性的新技术。数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器，并且能够在出现故障时快速转移到备用服务器。2数据库镜像介绍数据库镜像介绍在数据库镜像中，一台SQL Server 2014实例连续不断地将数据库事务日志发送到另一台备用的SQL Server 2014实例的数据库副本中。第7章 数据库管理数据库镜像中，需要注意的一些重要事项如下：主数据库必须为Full(完全)还原模型。由于Bulk-logged操作会导致日志记录无法发送到镜像数据库。初始化镜像数据库必须首先使用Norecovery(完全恢复)还原主数据库，然后再按顺序还原

24、诸数据库事务日志备份。镜像数据库和主数据库的名称必须一致。由于镜像数据库处于Recovering状态，因此不能直接访问。通过在镜像数据库上创建数据库快照可以间接读取某一个时刻点的镜像数据库。第7章 数据库管理7.2.6 SQL Server数据恢复技术数据恢复技术SQL Server利用事务日志、设置检查点、磁盘镜像等机制进行故障恢复。在SQL数据库中，有关数据库的所有修改都被自动地记录在名为Syslogs(事务日志)的统计表中。每个数据库都有自己专用的Syslogs，当发生故障时系统能利用Syslogs自动恢复。SQL Server采用提前写日志的方法实现系统的自动恢复。对数据库进行任何修改

25、时，SQL Server首先把这种修改记入日志；需要恢复时，系统则通过Syslogs回滚到数据修改前的状态。第7章 数据库管理SQL Server磁盘镜像通过建立数据库镜像设备实现数据库设备的动态复制，即把所有写到主设备的内容也同时写到另一个独立的镜像设备上。对系统数据库Master、用户数据库、用户数据库事务日志建立镜像后，即使其中一个设备发生故障，另一个设备仍能正常工作，这就保证了数据库事务逻辑的完整性。第7章 数据库管理设有一个事务T，要在某数据库中插入3行数据A、B、C，则第1步：BEGIN TRANSACTION。第2步：INSERT A。第3步：INSERT B。第4步：CHECK

26、POINT。第5步：INSERT C。第6步：COMMIT。第7章 数据库管理在实践中，应做好Master数据库和用户数据库的备份，利用DUMP DATABASE和DUMP TRANSACTION命令可以将数据库和事务日志转储，实现动态备份。当用户数据库发生介质故障时，可利用数据库和事务日志的备份来重构该数据库，进行数据库恢复(RESTORE)，具体利用LOAD DATABASE命令来实现从备份设备恢复数据库。这一命令只允许DBO使用，执行此命令的全过程都作为一个事务来对待。在数据库装入期间，任何未提交的事务都被回滚且不准任何用户对该数据库进行存取。当完成最后一次数据库备份装入之后，就可以利用

27、LOAD TRANSACTION命令把事务日志的备份再添加到数据库上，使数据库恢复到事务转储时的状态。第7章 数据库管理Master数据库是主数据库，它的恢复与用户数据库的恢复不同，当它的存储介质发生故障时，不能使用人工恢复的办法。因为它的崩溃将导致Server(服务器)不能启动，所以无法使用LOAD命令，此时必须重建、重载Master数据库，利用SQL Server Setup安装程序进行恢复。第7章 数据库管理 Master数据库恢复的具体办法为：首先启动SQL Server Setup使用程序，选择Rebuild Master DataBase复选框，创建新的Master数据库。此时创建

28、的Master库与初装SQL Server时的Master库一样；然后，以单用户方式启动Server，并用LOAD DATABASE命令装载Master库的备份；最后，对每个数据库执行数据库一致性检查程序，待一切正常后，则可在多用户方式下重新启动Server。第7章 数据库管理 7.3 并并 发发 控控 制制 7.3.1 并发控制概述并发控制概述事务是并发控制的基本单位，保证事务ACID的特性是事务处理的重要任务，而并发操作有可能会破坏其ACID特性。DBMS并发控制机制的目的是对并发操作进行正确调度，确保数据库的一致性。第7章 数据库管理下面用订某一大酒店标准房的一个活动序列(同一时刻读取)

29、的实例来说明并发操作带来的数据不一致的问题。步骤1：甲地点(甲事务)读取这一酒店剩余标准房数量为A，A=20。步骤2：乙地点(乙事务)读取这一酒店剩余标准房数量为A，A=20。步骤3：甲地点订出一间标准房，修改A=A-1，即A=19，写入数据库。步骤4：乙地点订出一间标准房，修改A=A-1，即A=19，写入数据库。结果：订出两间标准房，数据库中标准房的数量只减少1。第7章 数据库管理造成数据库的不一致性是由并发操作引起的。在并发操作情况下，对甲、乙事务的操作序列是随机的。若按上面的调度序列执行，甲事务的修改丢失，因为步骤4中乙事务修改A并写回后覆盖了甲事务的修改。如果没有锁定且多个用户同时访问

30、一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。由并发操作带来的数据不一致性包括：丢失数据修改、读“脏”数据(脏读)和不可重复读。第7章 数据库管理 1丢失数据修改丢失数据修改当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，就会发生丢失更新问题。每个事务都不知道其他事务的存在，最后的更新将重写由其他事务所做的更新，这将导致数据修改丢失，如表7.2所示。第7章 数据库管理第7章 数据库管理 2读读“脏脏”数据数据(脏读脏读)读“脏”数据是指事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤销，而此时T1把已修改过的数据又恢复到原值，T2读

31、到的数据与数据库的数据不一致，则T2读到的数据就为“脏”数据，即不正确的数据。如表7.3所示，T1将B值修改为400，T2读到B为400，而T1由于某种原因撤销，其修改作废，B恢复到原值200，但是T2读到的B仍为400，该数据与数据库内容不一致就是“脏”数据。第7章 数据库管理第7章 数据库管理 3不可重复读不可重复读不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法读取前一次结果。不可重复读包括三种情况：(1)事务T1读取某一数据后，T2对其做了修改，当T1再次读该数据后，得到与前一次读不同的值。如表7.4所示，T1读取D=100进行运算，T2读取同一数据D，对其修改后将D

32、=200写回数据库。T1为了对读取值校对重读D，D为200，与第1次读取值不一致。第7章 数据库管理第7章 数据库管理(2)事务T1按一定条件从数据库中读取了某些记录后，T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录消失。(3)事务T1按一定条件从数据库中读取某些数据记录后，T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。后两种不可重复读有时也称为产生幽灵数据。第7章 数据库管理 7.3.2 封锁协议封锁协议1封锁封锁所谓封锁，是指事务T在对某个数据对象如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后T对数据对象有一定的控制(具体的控制由封锁

33、类型决定)，在事务T释放锁前，其他事务不能更新此数据对象。按事务对数据对象的封锁程度来分，封锁有两种基本类型：排他锁(Exclusive Locks，简称X锁)和共享锁(Share Locks，简称S锁)。第7章 数据库管理排他锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务不能对A加任何类型的锁，直到T释放A上的锁为止，从而保证其他事务在T释放A上的锁前不能再读取和修改A。共享锁又称为读锁。若事务T对数据对象A加上S锁，则T可以读A，但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁为止，从而保证了在T对A加S锁过程中其他事务对A只能读

34、，不能修改。第7章 数据库管理给数据对象加排他锁或共享锁时应遵循如表7.5所示的锁相容矩阵。如果一个事务对某一个数据对象加上了共享锁，则其他任何事务只能对该数据对象加共享锁，而不能加排他锁，直到相应的锁被释放为止。如果一个事务对某一个数据加上了排他锁，则其他任何事务不可以再对该数据对象加任何类型的锁，直到相应的锁被释放为止。第7章 数据库管理第7章 数据库管理 2封锁协议封锁协议所谓封锁协议，是指在数据对象加锁、持锁和放锁时所约定的一些规则。不同的封锁规则形成了不同的封锁协议，下面分别介绍三级封锁协议。1)一级封锁协议事务T在修改数据A之前必须先对其加X锁，直到事务结束(即通过COMMIT和R

35、OLLBACK结束)才释放。作用：防止丢失修改，保证事务T可恢复，如图7.3所示。第7章 数据库管理图7.3 使用一级封锁协议防止丢失修改第7章 数据库管理 2)二级封锁协议二级封锁协议二级封锁协议规定事务T在更新数据对象以前必须对数据对象加X锁，且直到事务T结束时才可以释放该锁。另外，还规定事务T在读取数据对象以前必须先对其加S锁，读完后即可释放S锁。作用：防止丢失修改及读“脏”数据，如图7.4所示。第7章 数据库管理图7.4 使用二级封锁协议防止丢失修改及读“脏”数据第7章 数据库管理 3)三级封锁协议三级封锁协议三级封锁协议规定事务T在更新数据对象以前，必须对数据对象加X锁，且直到事务T

36、结束时才可以释放该锁。另外，还规定事务T在读取数据对象以前必须先对其加S锁，该S锁也必须在事务T结束时才可释放。作用：防止丢失修改、读“脏”数据以及不可重复读，如图7.5所示。第7章 数据库管理图7.5 使用三级封锁协议防止丢失修改、读“脏”数据以及不可重复读第7章 数据库管理三个级别的封锁协议的主要区别在于什么操作需要申请封锁，以及何时释放锁(即持锁时间)。三个级别的封锁协议可以总结为如表7.6所示的内容。第7章 数据库管理 3活锁和死锁活锁和死锁和操作系统一样，封锁的方法可能引起活锁(Livelock)和死锁(Deadlock)问题。封锁技术可以有效解决并发操作的一致性问题，但也可能产生新

37、的问题，即活锁和死锁问题。活锁和死锁是并发应用程序经常发生的问题，也是多线程编程中的重要概念。下面举一个实例对死锁和活锁进行形象的描述。第7章 数据库管理 1)活锁活锁当某个事务请求对某一数据进行排他性封锁时，由于其他事务对该数据的操作而使这个事务处于永久等待状态，这种状态称为活锁。例如：事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后，系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后，系统又批准了T4的请求，T2有可能永远等待。这就是活锁的例子。第7章 数据库管理 2)死锁死锁在同时处于等待状态的两

38、个或多个事务中，其中的每一个事务在它能够执行之前都等待着某个数据，而这个数据已被它们中的某个事务所封锁，这种状态称为死锁。例如：事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面。T1和T2两个事务永远不能结束，从而形成死锁。第7章 数据库管理目前，数据库中解决死锁问题主要有两类方法，一类方法是采取一定措施来预防死锁的发生，另一类方法是允许发生死锁，通常采用一定手段定期诊断系统中有无死锁，若有则解

39、除之。(1)死锁的预防。在数据库系统中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死锁等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法：第7章 数据库管理 一次封锁法。一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。例如，在上面的例子中，如果事务T1将数据对象A和B一次加锁，T1就可以执行下去，而T2等待。T1执行完后，释放A和B上的锁，T2继续执行。这样就不会发生死锁。第7章 数据库管理 顺序封锁法。顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序执行封锁。

40、在上例中，我们规定封锁顺序是A、B，T1和T2都按此顺序封锁，即T2也必须先封锁A。当T2请求A的封锁时，由于T1已经封锁住A，T2就只能等待。T1释放A、B上的锁后，T2继续运行。这样就不会发生死锁。第7章 数据库管理(2)死锁的诊断与解除。死锁的诊断与解除通常有两种方法：超时法。如果一个事务的等待时间超过了规定的时限，就认为它发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为它发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。第7章 数据库管理 事务等待图法。事务等待图是一个有向图G=(T,U)。T为结点的集合，每个结

41、点均表示正正运行的事务；U为边的集合，每条边均表示事务等待的情况。若T1等待T2，则T1、T2之间画一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地(比如每隔1分钟)检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。第7章 数据库管理 7.3.3 并发调度的可串行性并发调度的可串行性计算机系统对并发事务中并发操作的调度是随机的，不同的调度可能会产生不同的结果，那么哪个结果是正确的，哪个是不正确的呢？如果一个事务运行过程中没有其他事务同时运行，也就是说它没有受到其他事务的干扰，那么就可以认为该事务的运行结果是正常的或者预想的。因此，将所有事

42、务串行起来的调度策略一定是正确的调度策略。虽然以不同的顺序串行执行事务可能会产生不同的结果，但由于不会将数据库置于不一致状态，所以都是正确的。第7章 数据库管理并发调度的可串行性是指多个事务的并发执行是正确的。当且仅当其结果与按某一次序串行地执行它们的结果相同时，我们称这种调度策略为可串行化(Serializable)的调度。可串行性(Serializability)是并发事务正确性的准则。按这个准则规定，一个给定的并发调度，当且仅当它是可串行化的，才认为它是正确的调度。下面给出串行执行、并发执行(不正确)以及并发执行可以串行化(正确)的例子。第7章 数据库管理以银行转账为例，事务T1从账号A

43、(初值为200元)转100元到账号B(初值为200元)，事务T2从账号A转10%的款项到账号B，T1和T2具体执行过程如下：第7章 数据库管理事务T1和事务T2串行化调度的方案如表7.7到表7.10所示。第7章 数据库管理第7章 数据库管理为了保证并发操作的正确性，DBMS的并发控制机制必须提供一定的手段来保证调度是可串行化的。从理论上讲，在某一事务执行时禁止其他事务执行的调度策略一定是可串行化的调度，这也是最简单的调度策略。但这种方法实际上是不可取的，因为它使得用户不能充分共享数据库资源。目前，DBMS普遍采用封锁方法实现并发操作调度的可串行性，从而保证调度的正确性。两段锁(Two-Phas

44、e Locking，2PL)协议就是保证并发调度可串行性的封锁协议。除此之外，还可以用其他一些方法，如时标方法、乐观方法等来保证调度的正确性。第7章 数据库管理 7.3.4 两段锁协议两段锁协议所谓两段锁协议，是指所有事务必须分两个阶段对数据项进行加锁和解锁。在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁。在释放一个封锁之后，事务不再申请和获得任何其他封锁。第7章 数据库管理所谓“两段”锁的含义是，事务分为两个阶段：第一阶段是获得封锁，也称为扩展阶段，在这个阶段，事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁；第二阶段是释放封锁，也称为收缩阶段，在这个阶段，事务

45、可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。第7章 数据库管理例如，事务T1遵守两段锁协议，其封锁序列是：又如，事务T2不遵守两段锁协议，其封锁序列是：S Lock A Unlock A S Lock B X Lock C Unlock C Unlock B。可以证明，若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。第7章 数据库管理需要说明的是，事务遵循两段锁协议是可串行化调度的充分条件，而不是必要条件。也就是说，若并发事务都遵循两段锁协议，则对这些事务的任何并发调度策略都是可串行化的；若对并发事务的一个调度是可串行化的，则不一定所有事务都符

46、合两段锁协议。表7.11和表7.12都是可串行化的调度，但在表7.11中T1和T2都遵守两段锁协议，在表7.12中T1和T2都不遵守两段锁协议。第7章 数据库管理第7章 数据库管理7.3.5 SQL Server的并发控制的并发控制上面介绍了并发控制的一般原则与方法，下面简单介绍SQL Server数据库系统中的并发控制机制。SQL Server提供了一套安全保护机制，具有高安全性、完整性以及并发控制与故障恢复的数据控制能力。SQL Server支持广泛的并发控制机制。通过定义下列各项，用户可以指定并发控制类型：(1)用于连接的事务隔离级别。(2)游标上的并发选项。第7章 数据库管理SQL S

47、erver锁保持的时间长度是保护所请求级别上的资源所需的时间长度，具体事例如下：(1)用于保护读取操作的共享锁的保持时间取决于事务隔离级别。采用Read Committed的默认事务隔离级别时，只在读取页的期间内控制共享锁。在扫描中，直到在扫描内的下一页上获取锁时才释放锁。如果指定Holdlock提示或者将事务隔离级别设置为Repeatable Read或Serializable，则直到事务结束才释放锁。第7章 数据库管理(2)根据为游标设置的并发控制，游标可以获取共享模式的滚动锁，以保护提取。当需要滚动锁时，直到下一次提取或关闭游标(以先发生者为准)时，才能释放滚动锁。但是，如果指定Hold

48、lock，则直到事务结束才释放滚动锁。(3)用于保护更新的排他锁将直到事务结束才释放。第7章 数据库管理在SQL Server中，如果一个连接试图获取一个锁，而该锁与另一个连接所控制的锁冲突，则试图获取锁的连接将一直阻塞到以下情况为止。(1)将冲突锁释放而且连接获取了所请求的锁。(2)连接的超时间隔已到期。默认情况下，应用程序没有超时间隔，但是一些应用程序会设置超时间隔以防止无限期等待。第7章 数据库管理如果几个连接因在某个单独的资源上等待冲突的锁而被阻塞，那么在前面的连接释放锁时将按先来先服务的方式授予锁。SQL Server有一个算法可以检测死锁，即两个连接互相阻塞的情况。如果SQL Se

49、rver实例检测到死锁，将终止一个事务，以使另一个事务继续。第7章 数据库管理 7.4 安安 全全 性性 7.4.1 安全性概述安全性概述数据库是一个共享的资源，其中存放了组织、企业和个人的各种信息，有的是比较一般可以公开的数据，而有的可能是非常关键的或机密的数据，例如国家军事秘密、银行储蓄数据、证券投资信息、个人Internet账户信息等。如果对数据库控制不严，就有可能使重要的数据被泄露出去，甚至会受到不法分子的破坏。因此，必须严格控制用户对数据库的使用，这是由数据库的安全性控制来完成的。第7章 数据库管理所谓数据库的安全性，就是指保护数据，以防止不合法的使用所造成的数据泄漏、更改或破坏。随

50、着计算机资源共享和网络技术的应用日益广泛和深入，特别是Internet技术的发展，计算机安全性问题越来越得到人们的重视。网络环境下，数据库应用系统需要考虑的安全问题主要包括以下五个层面的问题：第7章 数据库管理(1)硬件平台的安全问题：确保支持数据库系统运行的硬件设施的安全。(2)网络系统的安全问题：对于可以远程访问的数据库系统来说，网络软件内部的安全性也非常重要。(3)操作系统安全问题：安全的操作系统是安全的数据库的重要前提。(4)数据库系统的安全问题：进行用户标识与鉴定、数据库存取控制，且只允许合法用户进入系统并进行合法的数据存取操作。(5)应用系统的安全问题：防止对应用系统的不合法使用所