精华内容
下载资源
问答
  • 并发控制机构的功能是
    2019-10-03 13:57:37

    并发的结构(模型)由控制结构确定

    转载于:https://www.cnblogs.com/feng9exe/p/10778106.html

    更多相关内容
  • 数据库并发控制技术

    2015-03-18 19:57:42
    数据库是一个共享资源,可以提供多个用户使用。这些用户程序可以一个一个地串行执行,每个时刻只有一个用户程序运行,执行对数据库的存取,其他用户程序必须等到这个用户程序结束...但这样就会产生多个用户程序并发存取
    数据库是一个共享资源,可以提供多个用户使用。这些用户程序可以一个一个地串行执行,每个时刻只有一个用户程序运行,执行对数据库的存取,其他用户程序必须等到这个用户程序结束以后方能对数据库存取。但是如果一个用户程序涉及大量数据的输入/输出交换,则数据库系统的大部分时间处于闲置状态。因此,为了充分利用数据库资源,发挥数据库共享资源的特点,应该允许多个用户并行地存取数据库。但这样就会产生多个用户程序并发存取同一数据的情况,若对并发操作不加控制就可能会存取和存储不正确的数据,破坏数据库的一致性,所以数据库管理系统必须提供并发控制机制。并发控制机制的好坏是衡量一个数据库管理系统性能的重要标志之一。

    DM用封锁机制来解决并发问题。它可以保证任何时候都可以有多个正在运行的用户程序,但是所有用户程序都在彼此完全隔离的环境中运行。

    一、  并发控制的预备知识

    (一)  并发控制概述

    并发控制是以事务(transaction)为单位进行的。

    1.  并发控制的单位――事务

    事务是数据库的逻辑工作单位,它是用户定义的一组操作序列。一个事务可以是一组SQL语句、一条SQL语句或整个程序。

    事务的开始和结束都可以由用户显示的控制,如果用户没有显式地定义事务,则由数据库系统按缺省规定自动划分事务。

    事务应该具有4种属性:原子性、一致性、隔离性和持久性。

    (1)原子性

    事务的原子性保证事务包含的一组更新操作是原子不可分的,也就是说这些操作是一个整体,对数据库而言全做或者全不做,不能部分的完成。这一性质即使在系统崩溃之后仍能得到保证,在系统崩溃之后将进行数据库恢复,用来恢复和撤销系统崩溃处于活动状态的事务对数据库的影响,从而保证事务的原子性。系统对磁盘上的任何实际数据的修改之前都会将修改操作信息本身的信息记录到磁盘上。当发生崩溃时,系统能根据这些操作记录当时该事务处于何种状态,以此确定是撤销该事务所做出的所有修改操作,还是将修改的操作重新执行。

    (2)一致性

    一致性要求事务执行完成后,将数据库从一个一致状态转变到另一个一致状态。它是一种以一致性规则为基础的逻辑属性,例如在转账的操作中,各账户金额必须平衡,这一条规则对于程序员而言是一个强制的规定,由此可见,一致性与原子性是密切相关的。事务的一致性属性要求事务在并发执行的情况下事务的一致性仍然满足。它在逻辑上不是独立的,它由事务的隔离性来表示。

    (3) 隔离性

    隔离性意味着一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。它要求即使有多个事务并发执行,看上去每个成功事务按串行调度执行一样。这一性质的另一种称法为可串行性,也就是说系统允许的任何交错操作调度等价于一个串行调度。串行调度的意思是每次调度一个事务,在一个事务的所有操作没有结束之前,另外的事务操作不能开始。由于性能原因,我们需要进行交错操作的调度,但我们也希望这些交错操作的调度的效果和某一个串行调度是一致的。 DM实现该机制是通过对事务的数据访问对象加适当的锁,从而排斥其他的事务对同一数据库对象的并发操作。

    (4)持久性

    系统提供的持久性保证要求一旦事务提交,那么对数据库所做的修改将是持久的,无论发生何种机器和系统故障都不应该对其有任何影响。例如,自动柜员机( ATM)在向客户支付一笔钱时,就不用担心丢失客户的取款记录。事务的持久性保证事务对数据库的影响是持久的,即使系统崩溃。正如在讲原子性时所提到的那样,系统通过做记录来提供这一保证。

    DM没有提供显式定义事务开始的语句,第一个可执行的SQL语句(除CONNECT语句外)隐含事务的开始,但事务的结束可以由用户显式的控制。在DM中以下几种情况都结束 (正常,非正常)某一事务:

    (1)当某一连接的属性设置为自动提交,每执行一条语句都会提交;

    (2)遇到COMMIT/ROLLBACK语句,便提交/回滚一事务;

    (3)当系统的 DDL自动提交开关打开时(缺省为打开),遇到DDL语句则自动提交该DDL语句和以前的DML和DDL操作;

    (4)事务所在的程序正常结束和用户退出;

    (5)系统非正常终止时;

    说明:DM在配置文件中提供了DDL语句的自动提交开关DDL_AUTO_COMMIT。 当此配置项的值为 1(缺省情况)时,所有DDL语句自动提交;当此配置项的值为0时,除CREATEDATABASE、ALTERDATABASE和CREATESCHEMA语句外的所有DDL语句都不自动提交。

    DM中的一致性是以事务为基础的。DM通过提交和回滚分别用于将对数据库的修改永久化和废除,但是无论是提交和回滚,DM保证数据库在每个事务开始前、结束后是一致的。为了提高事务管理的灵活性,DM提供了设置保存点(SAVEPOINT)语句和回滚到保存点语句。保存点提供了一种灵活的回滚,事务在执行中可以回滚到某个保存点,在该保存点以前的操作有效,而以后的操作被回滚掉。

    DM中的事务同样具有上述4个属性:原子性、一致性、隔离性和持久性。

    2. 并发操作与数据的不一致性

    如果没有锁定且多个用户同时访问一个数据库,则当他们的事务同时使用相同的数据时可能会发生问题,导致数据库中的数据的不一致性。

    一个最常见的并发操作的例子是火车/飞机订票系统中的订票操作。例如,在该系统中的一个活动序列:

    ① 甲售票员读出某航班的机票张数余额A,设A=16;

    ②  乙售票员读出同一航班的机票张数余额A,也是16;

    ③  甲售票员卖出一张机票,修改机票张数余额A=A-1=15,把A写回数据库;

    ④  乙售票员也卖出一张机票,修改机票张数余额A=A-1=15,把A写回数据库。

    结果明明卖出两张机票,数据库中机票余额只减少1。

    这种情况称为数据库的不一致性。这种不一致性是由甲、乙两个售票员并发操作引起的。在并发操作情况下,对甲、乙两个事务操作序列的调度是随机的。若按上面的调度序列行,甲事务的修改就被丢失。这是由于第4步中乙事务修改A并写回覆盖了甲事务的修改。

    并发操作带来的数据库不一致性可以分为四类:丢失或覆盖更新、脏读、不可重复读和幻像读,上例只是并发问题的一种。

    (1)       丢失或覆盖更新(lost update)

    当两个或多个事务选择同一数据,并且基于最初选定的值更新该数据时,会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新,这将导致数据丢失。上面预定飞机票的例子就属于这种并发问题。事务1与事务2先后读入同一数据A=16,事务1执行A-1,并将结果A=15写回,事务2执行A-1,并将结果A=15写回。事务2提交的结果覆盖了事务1对数据库的修改,从而使事务1对数据库的修改丢失了。



     
    (2)    脏读
    一个事务读取了另一个未提交的并行事务写的数据。当第二个事务选择其它事务正在更新的行时,会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。换句话说,当事务1修改某一数据,并将其写回磁盘,事务2读取同一数据后,事务1由于某种原因被撤销,这时事务1已修改过的数据恢复原值,事务2读到的数据就与数据库中的数据不一致,是不正确的数据,称为脏读。
    例如,在下图中,事务1将C值修改为200,事务2读到C为200,而事务1由于某种原因撤销,其修改作废,C恢复原值100,这时事务2读到的就是不正确的“脏“数据了。



    (3)    不可重复读(nonrepeatable read)
    一个事务重新读取前面读取过的数据,发现该数据已经被另一个已提交的事务修改过。即事务1读取某一数据后,事务2对其做了修改,当事务1再次读数据时,得到的与第一次不同的值。
    例如,在下图中,事务1读取B=100进行运算,事务2读取同一数据B,对其进行修改后将B=200写回数据库。事务1为了对读取值校对重读B,B已为200,与第一次读取值不一致。



    (4)    幻像读
    如果一个事务在提交查询结果之前,另一个事务可以更改该结果,就会发生这种情况。这句话也可以这样解释,事务1按一定条件从数据库中读取某些数据记录后未提交查询结果,事务2删除了其中部分记录,事务1再次按相同条件读取数据时,发现某些记录神秘地消失了;或者事务1按一定条件从数据库中读取某些数据记录后未提交查询结果,事务2插入了一些记录,当事务1再次按相同条件读取数据时,发现多了一些记录。
    产生上述四类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作,使一个用户事务的执行不受其他事务的干扰,从而避免造成数据的不一致性。
    3.    并发场景列举
    结合SQL语句,列举各种并发情况(包括可能导致数据不一致性和对数据一致性不产生影响的情况)。A表示某一条数据,b和c都表示满足某一个标准的两条或多条数据,^表示“非”的意思,∈表示属于或包含于的意思,1表示第一个事务,2表示第二个事务。



    (二)    并发操作的调度
    计算机系统对并行事务中并行操作的调度是随机的,而不同的调度可能会产生不同的结果,那么哪个结果是正确的,哪个是不正确的呢?
    如果一个事务运行过程中没有其他事务在同时运行,也就是说没有受到其他事务的干扰,那么就可能认为该事务的运行结果是正常的或者预想的,因此将所有事务串行起来的调度策略是正确的调度策略。虽然以不同的顺序串行执行事务也可能会产生不同的结果,但由于不会将数据库置于不一致状态,所以都可以认为是正确的。由此可以得到如下结论:几个事务的并行执行是正确的,当且仅当其结果与按某一次序串行地执行它们的结果相同。我们称这种并行调度策略为可串行化(serializable)的调度。可串行性(serializability)是并行事务正确性的唯一准则。
    例如,现在有两个事务,分别包含下列操作:
    事务1:读B;A=B+1;写回A;
    事务2:读A;B=A+1;写回B;
    假设A的初值为10,B的初值为2。下图给出了对这两个事务的三种不同的调度策略,(a)和(b)为两种不同的串行调度策略,虽然执行结果不同,但他们都是正确的调度。(c)中两个事务是交错执行的,由于执行结果与(a)、(b)的结果都不同,所以是错误的调度。(d)中的两个事务也是交错执行的,由于执行结果与串行调度1(图(a))的执行结果相同,所以是正确的调度。



    为了保证并行操作的正确性,DBMS的并行控制机制必须提供一定的手段来保证调度是可串行化的。
    从理论上讲,在某一事务执行时禁止其他事务执行的调度策略一定是可串行化的调度,这也是最简单的调度策略,但这种方法实际上是不可行的,因为它使用户不能充分共享数据库资源。
    目前DBMS普遍采用封锁方法(悲观方法,DM采用的就是这种方法,SQL Server也是采用的这种方法)来保证调度的正确性;即保证并行操作调度的可串行性。除此之外还有其他一些方法,如时标方法、乐观方法等。

    •    悲观并发控制 
    锁定系统阻止用户以影响其它用户的方式修改数据。如果用户执行的操作导致应用了某个锁,则直到这个锁的所有者释放该锁,其它用户才能执行与该锁冲突的操作。该方法主要用在数据争夺激烈的环境中,以及出现并发冲突时用锁保护数据的成本比回滚事务的成本低的环境中,因此称该方法为悲观并发控制。

    •    乐观并发控制
    在乐观并发控制中,用户读数据时不锁定数据。在执行更新时,系统进行检查,查看另一个用户读过数据后是否更改了数据。如果另一个用户更新了数据,将产生一个错误。一般情况下,接收错误信息的用户将回滚事务并重新开始。该方法主要用在数据争夺少的环境内,以及偶尔回滚事务的成本超过读数据时锁定数据的成本的环境内,因此称该方法为乐观并发控制。

    •    时标并发控制
    时标和封锁技术之间的基本区别是封锁是使一组事务的并发执行(即交叉执行)同步,使用它等价于这些事务的某一串行操作;时标法也是使用一组事务的交叉执行同步,但是使它等价于这些事务的一个特定的串行执行,即由时标的时序所确定的一个执行。如果发生冲突,是通过撤销并重新启动一个事务解决的。事务重新启动,则赋予新的时标。

    (三)    封锁
    封锁是事项并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象,例如,在标、记录等操作之前,先向系统发出请求,对其加锁。加锁后事务T就对数据库对象有了一定的控制,在事务T释放它的锁之前,其他事务不能更新此数据对象。
    1.    封锁类型
    DBMS通常提供了多种数据类型的封锁。一个事务对某个数据对象加锁后究竟拥有什么样的控制是由封锁类型决定的。基本的封锁类型有两种:排他锁(exclusive lock,简记为X锁)和共享锁(share lock简记为S锁)
    排他锁又称为写锁。若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他任何事务都不能再对A加任何类型的锁,直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。
    共享锁又称为读锁。若事务T对数据对象A加上S锁,则其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的锁。这就保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。
    排他锁与共享锁的控制方式可以用下图的相容矩阵来表示。  
    在下图的封锁类型相容矩阵中,最左边一列表示事务T1已经获得的数据对象上的锁的类型,其中横线表示没有加锁。最上面一行表示另一事务T2对同一数据对象发出的封锁请求。T2的封锁请求能否被满足用Y和N表示,其中Y表示事务T2的封锁要求与T1已持有的锁相容,封锁请求可以满足。N表示T2的封锁请求与T1已持有的锁冲突,T2请求被拒绝。



    2.    封锁粒度

    X锁和S锁都是加在某一个数据对象上的。封锁的对象可以是逻辑单元,也可以是物理单元。例如,在关系数据库中,封锁对象可以是属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等逻辑单元;也可以是页(数据页或索引页)、块等物理单元。封锁对象可以很大,比如对整个数据库加锁,也可以很小,比如只对某个属性值加锁。封锁对象的大小称为封锁的粒度(granularity)。

    封锁粒度与系统的并发度和并发控制的开销密切相关。封锁的粒度越大,系统中能够被封锁的对象就越小,并发度也就越小,但同时系统开销也越小;相反,封锁的粒度越小,并发度越高,但系统开销也就越大。
    因此,如果在一个系统中同时存在不同大小的封锁单元供不同的事务选择使用是比较理想的。而选择封锁粒度时必须同时考虑封锁机构和并发度两个因素,对系统开销与并发度进行权衡,以求得最优的效果。一般说来,需要处理大量元组的用户事务可以以关系为封锁单元;需要处理多个关系的大量元组的用户事务可以以数据库为封锁单位;而对于一个处理少量元组的用户事务,可以以元组为封锁单位以提高并发度。

    3.    封锁协议

    封锁的目的是为了保证能够正确地调度并发操作。为此,在运用X锁和S锁这两种基本封锁,对一定粒度的数据对象加锁时,还需要约定一些规则,例如,应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议(locking protocol)。对封锁方式规定不同的规则,就形成了各种不同的封锁协议,它们分别在不同的程度上为并发操作的正确调度提供一定的保证。本节介绍保证数据一致性的三级封锁协议和保证并行调度可串行性的两段锁协议,下一节将介绍避免死锁的封锁协议。

    (5)    保证数据一致性的封锁协议――三级封锁协议

    对并发操作的不正确调度可能会带来四种数据不一致性:丢失或覆盖更新、脏读、不可重复读和幻想读。三级封锁协议分别在不同程度上解决了这一问题。

    ①    1级封锁协议

    1级封锁协议的内容是:事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。事务结束包括正常结束(commit)和非正常结束(rollback)。

    1级封锁协议可以防止丢失或覆盖更新,并保证事务T是可以恢复的。例如,下图使用1级封锁协议解决了定飞机票例子的丢失更新问题。



    上图中,事务1在读A进行修改之前先对A加X锁,当事务2再请求对A加X锁时被拒绝,只能等事务1释放A上的锁。事务1修改值A=15写回磁盘,释放A上的X锁后,事务2获得对A的X锁,这时他读到的A已经是事务1更新过的值15,再按此新的A值进行运算,并将结果值A=14回到磁盘。这样就避免了丢失事务1的更新。

    在1级封锁协议中,如果仅仅是读数据不对其进行修改,是不需要加锁的,所以它不能保证可重复读和脏读。

    ②  2级封锁协议

    2级封锁协议的内容是:1级封锁协议加上事务T在读取数据R之前必须先对其加S锁,读完后即可释放S锁。
    2级封锁协议除防止了丢失或覆盖更新,还可进一步防止脏读。例如,下图使用2级封锁协议解决了脏读的问题。
    |
    下图中,事务1在对C进行修改之前,先对C加X锁,修改其值后写回磁盘。这时事务2请求C加上S锁,因T1已在C上加了X锁,事务2只能等待事务1释放它。之后事务1因某种原因被撤销,C恢复为原值100,并释放C上的X锁。事务2获得C上的S锁,读C=100。这就避免了事务2脏读数据。

    在2级封锁协议中,由于读完数据后即可释放S锁,所以它不能保证可重复读。



    ③    3级封锁协议

    3级封锁协议的内容是:1级封锁协议加上事务T在读取数据之前必须先对其加S锁,直到事务结束才释放。
    3级封锁协议除防止丢失或覆盖更新和不脏读数据外,还进一步防止了不可重复读和幻想读。例如下图,使用3级封锁协议解决了不可重复读和幻像读问题。



    上图中,事务1在读A,B之前,先对A,B加S锁,这样其他事务只能再对A,B加S锁,而不能加X锁,即其他事务只能读A,B,而不能修改它们。所以当事务2为修改B而申请对B的X锁时被拒绝,使其他无法执行修改操作,只能等待事务1释放B上的锁。接着事务1为验算再读A,B,这时读出的B仍是100,求和结果仍为150,即可重复读。

    上述三级协议的主要区别在于什么操作需要申请封锁以及何时释放锁(即持锁时间)。三级封锁协议可以总结为下表。



    (6)    保证并行调度可串行性的封锁协议――两段封锁协议

    可串行性是并行调度正确性的唯一准则,两段锁(two-phase locking,简称2PL)协议是为保证并行调度可串行性而提供的封锁协议。

    两段封锁协议规定:

    ①在对任何数据进行读、写操作之前,事务首先要获得对该数据的封锁,而且②在释放一个封锁之后,事务不再获得任何其他封锁。

    所谓“两段”锁的含义是,事务分为两个阶段,第一阶段是获得封锁,也称为扩展阶段,第二阶段是释放封锁,也称为收缩阶段。

    例如,事务1的封锁序列是:

    Slock A... Slock B… Xlock C… Unlock B… Unlock A… Unlock C;

    事务2的封锁序列是:

    Slock A... Unlock A… Slock B… Xlock C… Unlock C… Unlock B;

    则事务1遵守两段封锁协议,而事务2不遵守两段封锁协议。

    可以证明,若并行执行的所有事务均遵守两段锁协议,则对这些事务的所有并行调度策略都是可串行化的。因此我们得出如下结论:所有遵守两段锁协议的事务,其并行的结果一定是正确的。

    需要说明的是,事务遵守两段锁协议是可串行化调度的充分条件,而不是必要条件。即可串行化的调度中,不一定所有事务都必须符合两段封锁协议。例如,在下图中,(a)和(b)都是可串行化的调度,但(a)遵守两段锁协议,(b)不遵守两段锁协议。



    4.    死锁和活锁

    封锁技术可以有效地解决并行操作的一致性问题,但也带来一些新的问题,即死锁和活锁的问题。

    (1)    活锁

    如果事务T1封锁了数据对象R后,事务T2也请求封锁R,于是T2等待。接着T3也请求封锁R。T1释放R上的锁后,系统首先批准了T3的请求,T2只得继续等待。接着T4也请求封锁R,T3释放R上的锁后,系统又批准了T4的请求……,T2有可能就这样永远等待下去。这就是活锁的情形,如下图所示。



    避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时,封锁子系统按请求封锁的先后次序对这些事务排队,该数据对象上的锁一旦释放,首先批准申请队列中第一个事务获得锁。

    (2)    死锁

    如果事务T1封锁了数据A,事务T2封锁了数据B。之后T1又申请封锁数据B,因T2已封锁了B,于是T1等待T2释放B上的锁。接着T2又申请封锁A,因T1已封锁了A,T2也只能等待T1释放A上的锁。这样就出现了T1在等待T2,而T2又在等待T1的局面,T1和T2两个事务永远不能结束,形成死锁。如下图所示。



    死锁问题在操作系统和一般并行处理中已做了深入研究,但数据库系统有其自己的特点,操作系统中解决死锁的方法并不一定合适数据库系统。

    目前在数据库中解决死锁问题主要有两类方法,一类方法是采取一定措施来预防死锁的发生,另一类方法是允许发生死锁,采用一定手段定期诊断系统中有无死锁,若有则解除之。

    ①    死锁的预防
    在数据库系统中,产生死锁的原因是两个或多个事务都已封锁了一些数据对象,然后又都请求对已为其他事务封锁的数据对象加锁,从而出现死锁等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法。

    ◆ 一次封锁法
    一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行。例如,在上图的例子中,如果事务T1将数据对象A和B一次加锁,T1就可以执行下去,而T2等待。T1执行完后释放A,B上的锁,T2继续执行。这样就不会发生死锁。

    一次封锁法虽然可以有效地防止死锁的发生,但也存在问题。第一,一次就将以后要用到的全部数据加锁,势必扩大了封锁的范围,从而降低了系统的并发度。第二,数据库中数据是不断变化的,原来不要求封锁的数据,在执行过程中可能会变成封锁对象,所以很难实现精确地确定每个事务所要封锁的数据对象,只能采取扩大封锁范围,将事务在执行过程中可能要封锁的数据对象全部加锁,这就进一步降低了并发度。

    ◆    顺序封锁法
    顺序封锁法是预先对数据对象规定一个封锁顺序,所有事务都按这个顺序执行封锁。在上例中,我们规定封锁顺是A,B,T1和T2都按此顺序封锁,即T2也必须先封锁A。当T2请求A的封锁时,由于T1已经封锁住A,T2就只能等待。T1释放A,B上的锁后,T2继续运行。这样就不会发生死锁。

    顺序封锁法同样可以有效地防止死锁,但也同样存在问题。第一,数据库系统中可封锁的数据对象及其众多,并且随数据的插入、删除等操作而不断地变化,要维护这样极多而且变化的资源的封锁顺序非常困难,成本很高。

    第二,事务的封锁请求可以随着事务的执行而动态地决定,很难事先确定每一个事务要封锁哪些对象,因此也就很难按规定的顺序取施加封锁。例如,规定数据对象的封锁顺序为A,B,C,D,E。事务T3起初要求封锁数据对象B,C,E,但当它封锁B,C后,才发现还需要封锁A,这样就破坏了封锁顺序。

    可见,在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点,因此DBMS在解决死锁的问题上更普遍采用的是诊断并解除死锁的方法。
    ②    死锁的诊断与解除
    数据库系统中诊断死锁的方法与操作系统类似,即使用一个事务等待图,它动态地反映所有事务的等待状况。并发控制子系统周期性地(比如每隔1分钟)检测事务等待图,如果发现图中存在回路,则表示系统中出现了死锁。关于诊断死锁的详细讨论请参阅操作系统的有关书籍。
    DBMS的并发控制子系统一旦检测到系统中存在死锁,就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务,将其撤销,释放此事务持有的所有的锁,使其他事务能继续运行下去。
    二、    DM的并发控制
    (一)    事务隔离级
    事务的隔离级描述了给定事务的行为对其它并发执行事务的暴露程度。 SQL-92共规定了四种隔离级别,通过选择四个隔离级中的一个,用户能增加对其它未提交事务的暴露程度,获得更高的并发度。隔离级别是一个事务必须与其它事务进行隔离的程度。
    SQL-92的四种隔离级别如下所示,DM支持所有这些隔离级别: 
    (1)脏读(READ UNCOMMITTED):事务隔离的最低级别,事务可能查询到其它事务未提交的数据, 仅可保证不读取物理损坏的数据)。
    (2)读提交(READ COMMITTED):DM默认级别,保证不读脏数据。  
    (3)可重复读(REPEATABLE READ):保证不可重复读,但有可能读入幻像数据。 
    (4)可串行化(SERIALIZABLE):事务隔离的最高级别,事务之间完全隔离。
    DM允许用户改变未启动的事务的隔离级和读写特性 ,而且设置的选项将一直对那个连接保持有效,直到显式更改该选项为止。设置事务隔离级别虽然使程序员承担了某些完整性问题所带来的风险,但可以换取对数据更大的并发访问权。与以前的隔离级别相比,每个隔离级别都提供了更大的隔离性,但这是通过在更长的时间内占用更多限制锁换来的。DM还提供设置事务只读属性的语句,使用该语句后该事务只能做查询操作,不能更新数据库。
    需要注意的是,事务的隔离级别并不影响事务查看本身对数据的修改,也就是说,事务总可以查看自己对数据的修改。事务的隔离级别需要根据实际需要设定,较低的隔离级别可以增加并发,但代价是降低数据的正确性。相反,较高的隔离级别可以确保数据的正确性,但可能对并发产生负面影响。应用程序要求的隔离级别确定了DM使用的锁定行为。 
    下表中列出四种隔离级别允许不同类型的现象 



    注意:丢失或覆盖更新在所有的标准SQL隔离级中都是禁止的。

    (二)    并发处理

    1.    数据锁定机制

    DM用数据锁定机制来解决并发问题。它可以保证任何时候都可以有多个正在运行的事务,但是所有事务都在彼此完全隔离的环境中运行。 

    DM的封锁对象为表和元组。封锁的实施有自动和手动两种,即隐式上锁和显式上锁。隐式封锁动作的封锁根据事务的隔离级有所不同。同时, DM提供给用户4种手动上锁语句,用以适应用户定义的应用系统。 

    一般而言, DM的隐式封锁足以保证数据的一致性,但用户可以根据自己的需要改变对表的封锁。 DM提供给用户四种表锁:意向共享锁(IS:INTENSIVE SHARE)、共享锁(S:SHARE)、意向排它锁(IX:INTENSIVE EXCLUSIVE)和排它锁(X:EXCLUSIVE)。例如,在读提交隔离级下,系统缺省的表锁是 IS或IX ,在这两种表锁下,在访问元组前还需对元组进行封锁,为了提高系统的效率,用户可以手动对表进行 X封锁,这样,就不需对访问元组封锁。 

    封锁机制要达到以下目的:

    (1)一致性:保证用户正在查看时,改变的数据并未从根本上发生变化。 

    (2)完整性:保证数据库的基本结构以正确的顺序,准确地反映对它们的所有改变。 

    一个“ 锁定” 可以认为是当某一进程需要防止其它进程做某事时获得的某种东西,当该进程不再关心此事时就 “释放 ”此锁定,通常一个锁定是加在某个 “资源 ”(某些客体,如表 )上的。 

    DM的内部锁定是自动完成的。当某一进程要查看一个客体但不允许其他人修改它时,就获得一个共享方式的锁定。当某一进程要修改一客体,并且防止任何其它进程修改它时,就获得更新方式的锁定。当某一进程要修改一客体,并且防止任何其它进程修改它或以共享方式封锁它时,就获得独占方式的锁定。

    2.    锁定类型

    DM中的锁有三种,表锁、行锁和键范围锁。

    ◆   表锁
    表锁用来封锁表对象,在对表进行检索和更新时,DM会对表对象进行封锁,但是DM为用户提供手动的表锁语句,用户可以根据自己的需要改变对表的封锁类型。表锁的模式:意向共享锁 IS,意向排它锁 IX,共享锁 S,排它锁 X,共四种,其相容矩阵可定义如下表。



    ◆   行锁
    行锁封锁元组,在存取元组和更新元组前, DM会对元组上行锁,系统不提供手动的行封锁语句。行锁有两种模式:共享锁(S)、排它锁(X),其相容矩阵定义如下表。



    ◆     键范围锁
    键范围锁用在可串行事务上,主要解决了幻像读并发问题。键范围锁覆盖单个记录以及记录之间的范围,可以防止对事务访问的记录集进行幻像插入或删除。键范围锁仅用于在可串行隔离级别上操作的事务。 
    可串行性要求,如果任意一个查询在一个事务中后面的某一时刻再次执行,其所获取的行集应与该查询在同一事务中以前执行时所获得的行集相同。如果本查询试图提取的行不存在,则在试图访问该行的事务完成之前,其它事务不能插入该行。如果允许另一个事务插入该行,则它将以幻像出现。 
    如果另一个事务试图插入驻留在锁定数据页上的行,页级锁定可以防止添加幻像行,并维护可串行性。但是,如果该行要添加到未被第一个事务锁定的数据页,应设定锁定机制防止添加该行。 
    键范围锁通过覆盖索引行和索引行之间的范围来工作(而不是锁定整个基础表的行)。因为第二个事务在该范围内进行任何行插入、更新或删除操作时均需要修改索引,而键范围锁覆盖了索引项,所以在第一个事务完成之前会阻塞第二个事务的进行。 
    键范围锁由系统自行执行,执行的条件是: (1) 事务隔离级为可串行化级; (2) 查询结果通过某个索引得出。 
    用户上锁成功后锁将一直有效,直到当前事务结束时,该锁被系统自动解除。 

    3.    锁定类型比较



    4.    SQL语句锁定分析
    DM对各种 DDL和GRANT 等非DML 语句都分解为增、删、改。下表为DM对各种DML语句和查询语句的封锁策略。 

    表:SQL语句封锁策略



    注:S* 表示瞬时锁,在语句结束后释放;Range表示键范围锁。 

    上表只是系统在一般情况下的处理,当系统检测到有锁升级的可能,则会升级锁。一般而言,IS锁升级为 S锁,IX锁升级为 X锁,同时,不再进行行封锁。 

    5.    自定义锁定提高系统效率

    DM也提供了两个函数 SET_TABLE_OPTION([db.][sch.]tablename, option, value) 、SET_INDEX_OPTION([db.]indexname, option, value)(具体语法参见《 DM_SQL语言使用手册》第 8 章)供用户自行定义锁定类型,以增强系统并发度,提高系统效率。这两个函数是为那些清楚地知道特定类型的锁适用于何种情况的专家级用户提供的。 

    函数SET_TABLE_OPTION() 用于禁用指定表上的页级锁、行级锁或同时禁用二者,这一设置对该表上的所有索引都生效。函数 SET_INDEX_OPTION() 则用于禁用某一索引上的页级锁、行级锁或同时禁用二者。

    例如,当用户只需要修改索引中某定长字段时,修改操作不会造成 B 树的分裂与合并,此时就可以禁用该索引的页级锁。又如,当所有的用户都只做插入操作时,用户之间并不会对同一元组进行操作,此时就可以禁用行级锁。当用户能保证不对表进行增、删、改,而只是进行查询时,则可以同时禁用该表上的页级锁和行级锁,此时并发度最高。 

    6.    死锁处理

    解决死锁问题的三种方法:预防死锁、检测死锁及避免死锁。死锁预防要求用户进程事先申报所需的资源或按严格的规程申请资源,而死锁检测原则上应允许死锁发生,在适当的时机检查,若发生死锁,则设法排除之。与预防死锁相比,后者过于放手,致使死锁频繁。而避免死锁则以事务撤消为前提,当不能获得资源批准时,立刻进行死锁检测。它既不象预防死锁那样过于保守,也不象死锁检测那样过于放开,由于检测及时,由归纳法可知,在已获准等待的事务中,不可能存在死锁,所以检测算法比较简单。 

    DM4系统采用的是避免死锁方法。每当一个事务所申请占有的资源不能被立即获得时,便进行死锁检测,不存在死锁,则该事务入等待队列。否则,DM4视为产生运行时错误,将当前语句回滚。采用这种机制,从用户的角度看,DM4不存在解锁问题。 

    7.    加索引和不加索引的封锁区别

    加索引和不加索引的情况下,DM的封锁机制会影响到实际的封锁范围。索引的作用就在于,可以在查询中减少对无关数据的扫描。而在一般的隔离级中,总是要对扫描到的数据进行封锁。所以,利用索引可以减少封锁的数量,冲突的可能性也会大大减少。


    原文地址:http://blog.csdn.net/yanglilibaobao/article/details/1670026

    展开全文
  • 数据库并发控制

    千次阅读 2014-03-02 12:17:29
    1. 在数据库中为什么要并发控制?  答:数据库是共享资源,通常有许多个事务同时在运行。  当多个事务并发地存取数据库时就会产生同时读取和 /或修改同一数据的情况。若对并发操作不加控制就可能会存取和存储不...

    1. 在数据库中为什么要并发控制?

      答:数据库是共享资源,通常有许多个事务同时在运行。当多个事务并发地存取数据库时就会产生同时读取和(或)修改同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性。所以数据库管理系统必须提供并发控制机制。

    2. 并发操作可能会产生哪几类数据不一致?用什么方法能避免各种不一致的情况?

      答:并发操作带来的数据不一致性包括三类:丢失修改、不可重复读和读 “脏”数据。

      ( 1)丢失修改(Lost Update)

      两个事务 T1和T2读入同一数据并修改,T2提交的结果破坏了(覆盖了)T1提交的结果,导致T1的修改被丢失。

      ( 2)不可重复读(Non-Repeatable Read)

      不可重复读是指事务T1读取数据后,事务T2执行更新操作,使T1无法再现前一次读取结果。

      ( 3)读“脏”数据(Dirty Read)

      读 “脏”数据是指事务T1修改某一数据,并将其写回磁盘,事务T2读取同一数据后,T1由于某种原因被撤销,这时已被T1修改过的数据恢复原值,T2读到的数据就与数据库中的数据不一致,则T2读到的数据就为“脏”数据,即不正确的数据。

      避免不一致性的方法和技术就是并发控制。最常用的并发控制技术是封锁技术

      也可以用其他技术,例如在分布式数据库系统中可以采用时间戳方法来进行并发控制。

    3. 什么是封锁?

      答:封锁就是事务T在对某个数据对象例如表、记录等操作之前,先向系统发出请求,对其加锁。加锁后事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,其他的事务不能更新此数据对象。

    3. 基本的封锁类型有几种?试述它们的含义。

      答:基本的封锁类型有两种 : 排它锁(Exclusive Locks,简称X锁) 和共享锁(Share Locks,简称S锁)。

      排它锁又称为写锁。若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他任何事务都不能再对A加任何类型的锁,直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。

      共享锁又称为读锁。若事务T对数据对象A加上S锁,则事务T可以读A但不能修改A,其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁。这就保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。

    5. 什么是封锁协议?不同级别的封锁协议的主要区别是什么?

      答:在运用封锁技术对数据加锁时,要约定一些规则。例如,在运用X锁和S锁对数据对象加锁时,要约定何时申请X锁或S锁、何时释放封锁等。这些约定或者规则称为封锁协议(Locking Protocol)。对封锁方式约定不同的规则,就形成了各种不同的封锁协议。存在不同级别的封锁协议,例如《概论》中介绍的三级封锁协议,三级协议的主要区别在于什么操作需要申请封锁,何时申请封锁以及何时释放锁(即持锁时间的长短)。

       一级封锁协议:事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。

      二级封锁协议:一级封锁协议加上事务T在读取数据R之前必须先对其加S锁,读完后即可释放S锁。

      三级封锁协议:一级封锁协议加上事务T在读取数据R之前必须先对其加S锁,直到事务结束才释放。

    6. 不同封锁协议与系统一致性级别的关系是什么?

      答:不同的封锁协议对应不同的一致性级别。

    一级封锁协议可防止丢失修改,并保证事务T是可恢复的。在一级封锁协议中,对读数据是不加S锁的,所以它不能保证可重复读和不读“脏”数据。

    二级封锁协议除防止了丢失修改,还可进一步防止读 “脏”数据。在二级封锁协议中,由于读完数据后立即释放S锁,所以它不能保证可重复读。

    在三级封锁协议中,无论是读数据还是写数据都加长锁,即都要到事务结束时才释放封锁。所以三级封锁协议除防止了丢失修改和不读 “脏”数据外,还进一步防止了不可重复读。

    7. 试述活锁的产生原因和解决方法。

      答:活锁产生的原因:当一系列封锁不能按照其先后顺序执行时,就可能导致一些事务无限期等待某个封锁,从而导致活锁。

      避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时,封锁子系统按请求封锁的先后次序对事务排队,数据对象上的锁一旦释放就批准申请队列中第一个事务获得锁。

    8. 请给出预防死锁的若干方法。

      答:在数据库中,产生死锁的原因是两个或多个事务都已封锁了一些数据对象,然后又都请求已被其他事务封锁的数据加锁,从而出现死等待。

      防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法:

      ( 1)一次封锁法

      要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行。

      ( 2)顺序封锁法

      预先对数据对象规定一个封锁顺序,所有事务都按这个顺序实行封锁。

      不过,预防死锁的策略不大适合数据库系统的特点。

    9. 请给出检测死锁发生的一种方法,当发生死锁后如何解除死锁?

      答:数据库系统一般采用允许死锁发生, DBMS检测到死锁后加以解除的方法。DBMS中诊断死锁的方法与操作系统类似,一般使用超时法或事务等待图法。

      超时法是:如果一个事务的等待时间超过了规定的时限,就认为发生了死锁。超时法实现简单,但有可能误判死锁,事务因其他原因长时间等待超过时限时,系统会误认为发生了死锁。若时限设置得太长,又不能及时发现死锁发生。DBMS并发控制子系统检测到死锁后,就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务,将其撤消,释放此事务持有的所有锁,使其他事务得以继续运行下去。当然,对撤销的事务所执行的数据修改操作必须加以恢复。

    10. 什么样的并发调度是正确的调度?

      答:可串行化( Serializable)的调度是正确的调度。

      可串行化的调度的定义:多个事务的并发执行是正确的,当且仅当其结果与按某一次序串行地执行它们时的结果相同。

    11. 试述两段锁协议的概念。

      答:两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁。在对任何数据进行读、写操作之前,首先要申请并获得对该数据的封锁。在释放一个封锁之后,事务不再申请和获得任何其他封锁。

    “两段”的含义是,事务分为两个阶段:

      第一阶段是获得封锁,也称为扩展阶段。在这阶段,事务可以申请获得任何数据项上的任何类型的锁,但是不能释放任何锁。

      第二阶段是释放封锁,也称为收缩阶段。在这阶段,事务释放已经获得的锁,但是不能再申请任何锁。

    13. 为什么要引进意向锁? 意向锁的含义是什么?

      答:引进意向锁是为了提高封锁子系统的效率。该封锁子系统支持多种封锁粒度。

      原因是:在多粒度封锁方法中一个数据对象可能以两种方式加锁 —显式封锁和隐式封锁。因此系统在对某一数据对象加锁时不仅要检查该数据对象上有无(显式和隐式)封锁与之冲突;还要检查其所有上级结点和所有下级结点,看申请的封锁是否与这些结点上的(显式和隐式)封锁冲突;显然,这样的检查方法效率很低。为此引进了意向锁。

      意向锁的含义是:对任一结点加锁时,必须先对它的上层结点加意向锁。

      例如事务T要对某个元组加X锁,则首先要对关系和数据库加IX锁。换言之,对关系和数据库加IX锁,表示拟向(意向)它的后裔结点中的某个元组加X锁。

      引进意向锁后,系统对某一数据对象加锁时不必逐个检查与下一级结点的封锁冲突了。例如,事务T要对关系R加X锁时,系统只要检查根结点数据库和R本身是否已加了不相容的锁(如发现已经加了IX,则与X冲突),而不再需要搜索和检查R中的每一个元组是否加了X锁或S锁。

    14. 试述常用的意向锁:IS锁,IX锁,SIX锁,给出这些锁的相容矩阵。

      答: 

    IS锁:如果对一个数据对象加 IS锁,表示它的后裔结点拟(意向)加S锁。例如,要对某个元组加S锁,则要首先对关系和数据库加IS锁

    IX锁:如果对一个数据对象加 IX锁,表示它的后裔结点拟(意向)加X锁。例如,要对某个元组加X锁,则要首先对关系和数据库加IX锁。

    SIX锁:如果对一个数据对象加 SIX锁,表示对它加S锁,再加IX锁,即SIX = S + IX。

      相容矩阵(略)





    2. 并发操作与数据的不一致性
    如果没有锁定且多个用户同时访问一个数据库,则当他们的事务同时使用相同的数据时可能会发生问题,导致数据库中的数据的不一致性。
    一个最常见的并发操作的例子是火车/飞机订票系统中的订票操作。例如,在该系统中的一个活动序列:
    ① 甲售票员读出某航班的机票张数余额A,设A=16;
    ②  乙售票员读出同一航班的机票张数余额A,也是16;
    ③  甲售票员卖出一张机票,修改机票张数余额A=A-1=15,把A写回数据库;
    ④  乙售票员也卖出一张机票,修改机票张数余额A=A-1=15,把A写回数据库。
    结果明明卖出两张机票,数据库中机票余额只减少1。
    这种情况称为数据库的不一致性。这种不一致性是由甲、乙两个售票员并发操作引起的。在并发操作情况下,对甲、乙两个事务操作序列的调度是随机的。若按上面的调度序列行,甲事务的修改就被丢失。这是由于第4步中乙事务修改A并写回覆盖了甲事务的修改。
    并发操作带来的数据库不一致性可以分为四类:丢失或覆盖更新、脏读、不可重复读和幻像读,上例只是并发问题的一种。
    (1)       丢失或覆盖更新(lost update)
    当两个或多个事务选择同一数据,并且基于最初选定的值更新该数据时,会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新,这将导致数据丢失。上面预定飞机票的例子就属于这种并发问题。事务1与事务2先后读入同一数据A=16,事务1执行A-1,并将结果A=15写回,事务2执行A-1,并将结果A=15写回。事务2提交的结果覆盖了事务1对数据库的修改,从而使事务1对数据库的修改丢失了。
    (2)    脏读
    一个事务读取了另一个未提交的并行事务写的数据。当第二个事务选择其它事务正在更新的行时,会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。换句话说,当事务1修改某一数据,并将其写回磁盘,事务2读取同一数据后,事务1由于某种原因被撤销,这时事务1已修改过的数据恢复原值,事务2读到的数据就与数据库中的数据不一致,是不正确的数据,称为脏读。
    例如,在下图中,事务1将C值修改为200,事务2读到C为200,而事务1由于某种原因撤销,其修改作废,C恢复原值100,这时事务2读到的就是不正确的“脏“数据了。
    (3)    不可重复读(nonrepeatable read)
    一个事务重新读取前面读取过的数据,发现该数据已经被另一个已提交的事务修改过。即事务1读取某一数据后,事务2对其做了修改,当事务1再次读数据时,得到的与第一次不同的值。
    例如,在下图中,事务1读取B=100进行运算,事务2读取同一数据B,对其进行修改后将B=200写回数据库。事务1为了对读取值校对重读B,B已为200,与第一次读取值不一致。
    (4)    幻像读
    如果一个事务在提交查询结果之前,另一个事务可以更改该结果,就会发生这种情况。这句话也可以这样解释,事务1按一定条件从数据库中读取某些数据记录后未提交查询结果,事务2删除了其中部分记录,事务1再次按相同条件读取数据时,发现某些记录神秘地消失了;或者事务1按一定条件从数据库中读取某些数据记录后未提交查询结果,事务2插入了一些记录,当事务1再次按相同条件读取数据时,发现多了一些记录。
    产生上述四类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作,使一个用户事务的执行不受其他事务的干扰,从而避免造成数据的不一致性。
    3.    并发场景列举
    结合SQL语句,列举各种并发情况(包括可能导致数据不一致性和对数据一致性不产生影响的情况)。A表示某一条数据,b和c都表示满足某一个标准的两条或多条数据,^表示“非”的意思,∈表示属于或包含于的意思,1表示第一个事务,2表示第二个事务。



    (二)    并发操作的调度
    计算机系统对并行事务中并行操作的调度是随机的,而不同的调度可能会产生不同的结果,那么哪个结果是正确的,哪个是不正确的呢?
    如果一个事务运行过程中没有其他事务在同时运行,也就是说没有受到其他事务的干扰,那么就可能认为该事务的运行结果是正常的或者预想的,因此将所有事务串行起来的调度策略是正确的调度策略。虽然以不同的顺序串行执行事务也可能会产生不同的结果,但由于不会将数据库置于不一致状态,所以都可以认为是正确的。由此可以得到如下结论:几个事务的并行执行是正确的,当且仅当其结果与按某一次序串行地执行它们的结果相同。我们称这种并行调度策略为可串行化(serializable)的调度。可串行性(serializability)是并行事务正确性的唯一准则。
    例如,现在有两个事务,分别包含下列操作:
    事务1:读B;A=B+1;写回A;
    事务2:读A;B=A+1;写回B;
    假设A的初值为10,B的初值为2。下图给出了对这两个事务的三种不同的调度策略,(a)和(b)为两种不同的串行调度策略,虽然执行结果不同,但他们都是正确的调度。(c)中两个事务是交错执行的,由于执行结果与(a)、(b)的结果都不同,所以是错误的调度。(d)中的两个事务也是交错执行的,由于执行结果与串行调度1(图(a))的执行结果相同,所以是正确的调度。
    为了保证并行操作的正确性,DBMS的并行控制机制必须提供一定的手段来保证调度是可串行化的。
    从理论上讲,在某一事务执行时禁止其他事务执行的调度策略一定是可串行化的调度,这也是最简单的调度策略,但这种方法实际上是不可行的,因为它使用户不能充分共享数据库资源。
    目前DBMS普遍采用封锁方法(悲观方法,DM采用的就是这种方法,SQL Server也是采用的这种方法)来保证调度的正确性;即保证并行操作调度的可串行性。除此之外还有其他一些方法,如时标方法、乐观方法等。
    •    悲观并发控制 
    锁定系统阻止用户以影响其它用户的方式修改数据。如果用户执行的操作导致应用了某个锁,则直到这个锁的所有者释放该锁,其它用户才能执行与该锁冲突的操作。该方法主要用在数据争夺激烈的环境中,以及出现并发冲突时用锁保护数据的成本比回滚事务的成本低的环境中,因此称该方法为悲观并发控制。
    •    乐观并发控制
    在乐观并发控制中,用户读数据时不锁定数据。在执行更新时,系统进行检查,查看另一个用户读过数据后是否更改了数据。如果另一个用户更新了数据,将产生一个错误。一般情况下,接收错误信息的用户将回滚事务并重新开始。该方法主要用在数据争夺少的环境内,以及偶尔回滚事务的成本小于读数据时锁定数据的成本的环境内,因此称该方法为乐观并发控制。
    •    时标并发控制
    时标和封锁技术之间的基本区别是封锁是使一组事务的并发执行(即交叉执行)同步,使用它等价于这些事务的某一串行操作;时标法也是使用一组事务的交叉执行同步,但是使它等价于这些事务的一个特定的串行执行,即由时标的时序所确定的一个执行。如果发生冲突,是通过撤销并重新启动一个事务解决的。事务重新启动,则赋予新的时标。

    (三)    封锁
    封锁是事项并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象,例如,在标、记录等操作之前,先向系统发出请求,对其加锁。加锁后事务T就对数据库对象有了一定的控制,在事务T释放它的锁之前,其他事务不能更新此数据对象。
    1.    封锁类型
    DBMS通常提供了多种数据类型的封锁。一个事务对某个数据对象加锁后究竟拥有什么样的控制是由封锁类型决定的。基本的封锁类型有两种:排他锁(exclusive lock,简记为X锁)和共享锁(share lock简记为S锁)
    排他锁又称为写锁。若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他任何事务都不能再对A加任何类型的锁,直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。
    共享锁又称为读锁。若事务T对数据对象A加上S锁,则其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的锁。这就保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。
    排他锁与共享锁的控制方式可以用下图的相容矩阵来表示。  
    在下图的封锁类型相容矩阵中,最左边一列表示事务T1已经获得的数据对象上的锁的类型,其中横线表示没有加锁。最上面一行表示另一事务T2对同一数据对象发出的封锁请求。T2的封锁请求能否被满足用Y和N表示,其中Y表示事务T2的封锁要求与T1已持有的锁相容,封锁请求可以满足。N表示T2的封锁请求与T1已持有的锁冲突,T2请求被拒绝。

    2.    封锁粒度
    X锁和S锁都是加在某一个数据对象上的。封锁的对象可以是逻辑单元,也可以是物理单元。例如,在关系数据库中,封锁对象可以是属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等逻辑单元;也可以是页(数据页或索引页)、块等物理单元。封锁对象可以很大,比如对整个数据库加锁,也可以很小,比如只对某个属性值加锁。封锁对象的大小称为封锁的粒度(granularity)。

    封锁粒度与系统的并发度和并发控制的开销密切相关。封锁的粒度越大,系统中能够被封锁的对象就越小,并发度也就越小,但同时系统开销也越小;相反,封锁的粒度越小,并发度越高,但系统开销也就越大。
    因此,如果在一个系统中同时存在不同大小的封锁单元供不同的事务选择使用是比较理想的。而选择封锁粒度时必须同时考虑封锁机构和并发度两个因素,对系统开销与并发度进行权衡,以求得最优的效果。一般说来,需要处理大量元组的用户事务可以以关系为封锁单元;需要处理多个关系的大量元组的用户事务可以以数据库为封锁单位;而对于一个处理少量元组的用户事务,可以以元组为封锁单位以提高并发度。

    3.    封锁协议
    封锁的目的是为了保证能够正确地调度并发操作。为此,在运用X锁和S锁这两种基本封锁,对一定粒度的数据对象加锁时,还需要约定一些规则,例如,应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议(locking protocol)。对封锁方式规定不同的规则,就形成了各种不同的封锁协议,它们分别在不同的程度上为并发操作的正确调度提供一定的保证。本节介绍保证数据一致性的三级封锁协议和保证并行调度可串行性的两段锁协议,下一节将介绍避免死锁的封锁协议。

    (5)    保证数据一致性的封锁协议――三级封锁协议
    对并发操作的不正确调度可能会带来四种数据不一致性:丢失或覆盖更新、脏读、不可重复读和幻想读。三级封锁协议分别在不同程度上解决了这一问题。

    ①    1级封锁协议
    1级封锁协议的内容是:事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。事务结束包括正常结束(commit)和非正常结束(rollback)。
    1级封锁协议可以防止丢失或覆盖更新,并保证事务T是可以恢复的。例如,下图使用1级封锁协议解决了定飞机票例子的丢失更新问题。
    上图中,事务1在读A进行修改之前先对A加X锁,当事务2再请求对A加X锁时被拒绝,只能等事务1释放A上的锁。事务1修改值A=15写回磁盘,释放A上的X锁后,事务2获得对A的X锁,这时他读到的A已经是事务1更新过的值15,再按此新的A值进行运算,并将结果值A=14回到磁盘。这样就避免了丢失事务1的更新。

    在1级封锁协议中,如果仅仅是读数据不对其进行修改,是不需要加锁的,所以它不能保证可重复读和脏读。

    ②  2级封锁协议
    2级封锁协议的内容是:1级封锁协议加上事务T在读取数据R之前必须先对其加S锁,读完后即可释放S锁。
    2级封锁协议除防止了丢失或覆盖更新,还可进一步防止脏读。例如,下图使用2级封锁协议解决了脏读的问题。
    下图中,事务1在对C进行修改之前,先对C加X锁,修改其值后写回磁盘。这时事务2请求C加上S锁,因T1已在C上加了X锁,事务2只能等待事务1释放它。之后事务1因某种原因被撤销,C恢复为原值100,并释放C上的X锁。事务2获得C上的S锁,读C=100。这就避免了事务2脏读数据。
    在2级封锁协议中,由于读完数据后即可释放S锁,所以它不能保证可重复读。

    ③    3级封锁协议
    3级封锁协议的内容是:1级封锁协议加上事务T在读取数据之前必须先对其加S锁,直到事务结束才释放。
    3级封锁协议除防止丢失或覆盖更新和不脏读数据外,还进一步防止了不可重复读和幻想读。例如下图,使用3级封锁协议解决了不可重复读和幻像读问题。
    上图中,事务1在读A,B之前,先对A,B加S锁,这样其他事务只能再对A,B加S锁,而不能加X锁,即其他事务只能读A,B,而不能修改它们。所以当事务2为修改B而申请对B的X锁时被拒绝,使其他无法执行修改操作,只能等待事务1释放B上的锁。接着事务1为验算再读A,B,这时读出的B仍是100,求和结果仍为150,即可重复读。

    上述三级协议的主要区别在于什么操作需要申请封锁以及何时释放锁(即持锁时间)。三级封锁协议可以总结为下表。

    (6)    保证并行调度可串行性的封锁协议――两段封锁协议
    可串行性是并行调度正确性的唯一准则,两段锁(two-phase locking,简称2PL)协议是为保证并行调度可串行性而提供的封锁协议。
    两段封锁协议规定:
    ①在对任何数据进行读、写操作之前,事务首先要获得对该数据的封锁,而且②在释放一个封锁之后,事务不再获得任何其他封锁。
    所谓“两段”锁的含义是,事务分为两个阶段,第一阶段是获得封锁,也称为扩展阶段,第二阶段是释放封锁,也称为收缩阶段。
    例如,事务1的封锁序列是:
    Slock A... Slock B… Xlock C… Unlock B… Unlock A… Unlock C;
    事务2的封锁序列是:
    Slock A... Unlock A… Slock B… Xlock C… Unlock C… Unlock B;
    则事务1遵守两段封锁协议,而事务2不遵守两段封锁协议。
    可以证明,若并行执行的所有事务均遵守两段锁协议,则对这些事务的所有并行调度策略都是可串行化的。因此我们得出如下结论:所有遵守两段锁协议的事务,其并行的结果一定是正确的。
    需要说明的是,事务遵守两段锁协议是可串行化调度的充分条件,而不是必要条件。即可串行化的调度中,不一定所有事务都必须符合两段封锁协议。例如,在下图中,(a)和(b)都是可串行化的调度,但(a)遵守两段锁协议,(b)不遵守两段锁协议。

    4.    死锁和活锁
    封锁技术可以有效地解决并行操作的一致性问题,但也带来一些新的问题,即死锁和活锁的问题。

    (1)    活锁
    如果事务T1封锁了数据对象R后,事务T2也请求封锁R,于是T2等待。接着T3也请求封锁R。T1释放R上的锁后,系统首先批准了T3的请求,T2只得继续等待。接着T4也请求封锁R,T3释放R上的锁后,系统又批准了T4的请求……,T2有可能就这样永远等待下去。这就是活锁的情形,如下图所示。
    避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时,封锁子系统按请求封锁的先后次序对这些事务排队,该数据对象上的锁一旦释放,首先批准申请队列中第一个事务获得锁。
    (2)    死锁
    如果事务T1封锁了数据A,事务T2封锁了数据B。之后T1又申请封锁数据B,因T2已封锁了B,于是T1等待T2释放B上的锁。接着T2又申请封锁A,因T1已封锁了A,T2也只能等待T1释放A上的锁。这样就出现了T1在等待T2,而T2又在等待T1的局面,T1和T2两个事务永远不能结束,形成死锁。如下图所示。
    死锁问题在操作系统和一般并行处理中已做了深入研究,但数据库系统有其自己的特点,操作系统中解决死锁的方法并不一定合适数据库系统。
    目前在数据库中解决死锁问题主要有两类方法,一类方法是采取一定措施来预防死锁的发生,另一类方法是允许发生死锁,采用一定手段定期诊断系统中有无死锁,若有则解除之。

    ①    死锁的预防
    在数据库系统中,产生死锁的原因是两个或多个事务都已封锁了一些数据对象,然后又都请求对已为其他事务封锁的数据对象加锁,从而出现死锁等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法。
    ◆ 一次封锁法
    一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行。例如,在上图的例子中,如果事务T1将数据对象A和B一次加锁,T1就可以执行下去,而T2等待。T1执行完后释放A,B上的锁,T2继续执行。这样就不会发生死锁。
    一次封锁法虽然可以有效地防止死锁的发生,但也存在问题。第一,一次就将以后要用到的全部数据加锁,势必扩大了封锁的范围,从而降低了系统的并发度。第二,数据库中数据是不断变化的,原来不要求封锁的数据,在执行过程中可能会变成封锁对象,所以很难实现精确地确定每个事务所要封锁的数据对象,只能采取扩大封锁范围,将事务在执行过程中可能要封锁的数据对象全部加锁,这就进一步降低了并发度。
    ◆    顺序封锁法
    顺序封锁法是预先对数据对象规定一个封锁顺序,所有事务都按这个顺序执行封锁。在上例中,我们规定封锁顺是A,B,T1和T2都按此顺序封锁,即T2也必须先封锁A。当T2请求A的封锁时,由于T1已经封锁住A,T2就只能等待。T1释放A,B上的锁后,T2继续运行。这样就不会发生死锁。
    顺序封锁法同样可以有效地防止死锁,但也同样存在问题。第一,数据库系统中可封锁的数据对象及其众多,并且随数据的插入、删除等操作而不断地变化,要维护这样极多而且变化的资源的封锁顺序非常困难,成本很高。
    第二,事务的封锁请求可以随着事务的执行而动态地决定,很难事先确定每一个事务要封锁哪些对象,因此也就很难按规定的顺序取施加封锁。例如,规定数据对象的封锁顺序为A,B,C,D,E。事务T3起初要求封锁数据对象B,C,E,但当它封锁B,C后,才发现还需要封锁A,这样就破坏了封锁顺序。

    可见,在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点,因此DBMS在解决死锁的问题上更普遍采用的是诊断并解除死锁的方法。
    ②    死锁的诊断与解除
    数据库系统中诊断死锁的方法与操作系统类似,即使用一个事务等待图,它动态地反映所有事务的等待状况。并发控制子系统周期性地(比如每隔1分钟)检测事务等待图,如果发现图中存在回路,则表示系统中出现了死锁。关于诊断死锁的详细讨论请参阅操作系统的有关书籍。
    DBMS的并发控制子系统一旦检测到系统中存在死锁,就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务,将其撤销,释放此事务持有的所有的锁,使其他事务能继续运行下去。
    二、    DM的并发控制
    (一)    事务隔离级
    事务的隔离级描述了给定事务的行为对其它并发执行事务的暴露程度。 SQL-92共规定了四种隔离级别,通过选择四个隔离级中的一个,用户能增加对其它未提交事务的暴露程度,获得更高的并发度。隔离级别是一个事务必须与其它事务进行隔离的程度。
    SQL-92的四种隔离级别如下所示,DM支持所有这些隔离级别: 
    (1)脏读(READ UNCOMMITTED):事务隔离的最低级别,事务可能查询到其它事务未提交的数据, 仅可保证不读取物理损坏的数据)。
    (2)读提交(READ COMMITTED):DM默认级别,保证不读脏数据。  
    (3)可重复读(REPEATABLE READ):保证不可重复读,但有可能读入幻像数据。 
    (4)可串行化(SERIALIZABLE):事务隔离的最高级别,事务之间完全隔离。
    DM允许用户改变未启动的事务的隔离级和读写特性 ,而且设置的选项将一直对那个连接保持有效,直到显式更改该选项为止。设置事务隔离级别虽然使程序员承担了某些完整性问题所带来的风险,但可以换取对数据更大的并发访问权。与以前的隔离级别相比,每个隔离级别都提供了更大的隔离性,但这是通过在更长的时间内占用更多限制锁换来的。DM还提供设置事务只读属性的语句,使用该语句后该事务只能做查询操作,不能更新数据库。
    需要注意的是,事务的隔离级别并不影响事务查看本身对数据的修改,也就是说,事务总可以查看自己对数据的修改。事务的隔离级别需要根据实际需要设定,较低的隔离级别可以增加并发,但代价是降低数据的正确性。相反,较高的隔离级别可以确保数据的正确性,但可能对并发产生负面影响。应用程序要求的隔离级别确定了DM使用的锁定行为。 
    下表中列出四种隔离级别允许不同类型的现象 

    注意:丢失或覆盖更新在所有的标准SQL隔离级中都是禁止的。


    (二)    并发处理
    1.    数据锁定机制
    DM用数据锁定机制来解决并发问题。它可以保证任何时候都可以有多个正在运行的事务,但是所有事务都在彼此完全隔离的环境中运行。 
    DM的封锁对象为表和元组。封锁的实施有自动和手动两种,即隐式上锁和显式上锁。隐式封锁动作的封锁根据事务的隔离级有所不同。同时, DM提供给用户4种手动上锁语句,用以适应用户定义的应用系统。 
    一般而言, DM的隐式封锁足以保证数据的一致性,但用户可以根据自己的需要改变对表的封锁。 DM提供给用户四种表锁:意向共享锁(IS:INTENSIVE SHARE)、共享锁(S:SHARE)、意向排它锁(IX:INTENSIVE EXCLUSIVE)和排它锁(X:EXCLUSIVE)。例如,在读提交隔离级下,系统缺省的表锁是 IS或IX ,在这两种表锁下,在访问元组前还需对元组进行封锁,为了提高系统的效率,用户可以手动对表进行 X封锁,这样,就不需对访问元组封锁。 


    封锁机制要达到以下目的:
    (1)一致性:保证用户正在查看时,改变的数据并未从根本上发生变化。 
    (2)完整性:保证数据库的基本结构以正确的顺序,准确地反映对它们的所有改变。 
    一个“ 锁定” 可以认为是当某一进程需要防止其它进程做某事时获得的某种东西,当该进程不再关心此事时就 “释放 ”此锁定,通常一个锁定是加在某个 “资源 ”(某些客体,如表 )上的。 

    DM的内部锁定是自动完成的。当某一进程要查看一个客体但不允许其他人修改它时,就获得一个共享方式的锁定。当某一进程要修改一客体,并且防止任何其它进程修改它时,就获得更新方式的锁定。当某一进程要修改一客体,并且防止任何其它进程修改它或以共享方式封锁它时,就获得独占方式的锁定。


    2.    锁定类型
    DM中的锁有三种,表锁、行锁和键范围锁。
    ◆   表锁
    表锁用来封锁表对象,在对表进行检索和更新时,DM会对表对象进行封锁,但是DM为用户提供手动的表锁语句,用户可以根据自己的需要改变对表的封锁类型。表锁的模式:意向共享锁 IS,意向排它锁 IX,共享锁 S,排它锁 X,共四种,其相容矩阵可定义如下表。
    ◆   行锁
    行锁封锁元组,在存取元组和更新元组前, DM会对元组上行锁,系统不提供手动的行封锁语句。行锁有两种模式:共享锁(S)、排它锁(X),其相容矩阵定义如下表。
    ◆     键范围锁
    键范围锁用在可串行事务上,主要解决了幻像读并发问题。键范围锁覆盖单个记录以及记录之间的范围,可以防止对事务访问的记录集进行幻像插入或删除。键范围锁仅用于在可串行隔离级别上操作的事务。 
    可串行性要求,如果任意一个查询在一个事务中后面的某一时刻再次执行,其所获取的行集应与该查询在同一事务中以前执行时所获得的行集相同。如果本查询试图提取的行不存在,则在试图访问该行的事务完成之前,其它事务不能插入该行。如果允许另一个事务插入该行,则它将以幻像出现。 
    如果另一个事务试图插入驻留在锁定数据页上的行,页级锁定可以防止添加幻像行,并维护可串行性。但是,如果该行要添加到未被第一个事务锁定的数据页,应设定锁定机制防止添加该行。 
    键范围锁通过覆盖索引行和索引行之间的范围来工作(而不是锁定整个基础表的行)。因为第二个事务在该范围内进行任何行插入、更新或删除操作时均需要修改索引,而键范围锁覆盖了索引项,所以在第一个事务完成之前会阻塞第二个事务的进行。 
    键范围锁由系统自行执行,执行的条件是: (1) 事务隔离级为可串行化级; (2) 查询结果通过某个索引得出。 
    用户上锁成功后锁将一直有效,直到当前事务结束时,该锁被系统自动解除。 

    3.    锁定类型比较
    4.    SQL语句锁定分析
    DM对各种 DDL和GRANT 等非DML 语句都分解为增、删、改。下表为DM对各种DML语句和查询语句的封锁策略。 


    表:SQL语句封锁策略
    注:S* 表示瞬时锁,在语句结束后释放;Range表示键范围锁。 
    上表只是系统在一般情况下的处理,当系统检测到有锁升级的可能,则会升级锁。一般而言,IS锁升级为 S锁,IX锁升级为 X锁,同时,不再进行行封锁。 

    5.    自定义锁定提高系统效率
    DM也提供了两个函数 SET_TABLE_OPTION([db.][sch.]tablename, option, value) 、SET_INDEX_OPTION([db.]indexname, option, value)(具体语法参见《 DM_SQL语言使用手册》第 8 章)供用户自行定义锁定类型,以增强系统并发度,提高系统效率。这两个函数是为那些清楚地知道特定类型的锁适用于何种情况的专家级用户提供的。 
    函数SET_TABLE_OPTION() 用于禁用指定表上的页级锁、行级锁或同时禁用二者,这一设置对该表上的所有索引都生效。函数 SET_INDEX_OPTION() 则用于禁用某一索引上的页级锁、行级锁或同时禁用二者。
    例如,当用户只需要修改索引中某定长字段时,修改操作不会造成 B 树的分裂与合并,此时就可以禁用该索引的页级锁。又如,当所有的用户都只做插入操作时,用户之间并不会对同一元组进行操作,此时就可以禁用行级锁。当用户能保证不对表进行增、删、改,而只是进行查询时,则可以同时禁用该表上的页级锁和行级锁,此时并发度最高。 

    6.    死锁处理
    解决死锁问题的三种方法:预防死锁、检测死锁及避免死锁。死锁预防要求用户进程事先申报所需的资源或按严格的规程申请资源,而死锁检测原则上应允许死锁发生,在适当的时机检查,若发生死锁,则设法排除之。与预防死锁相比,后者过于放手,致使死锁频繁。而避免死锁则以事务撤消为前提,当不能获得资源批准时,立刻进行死锁检测。它既不象预防死锁那样过于保守,也不象死锁检测那样过于放开,由于检测及时,由归纳法可知,在已获准等待的事务中,不可能存在死锁,所以检测算法比较简单。 
    DM4系统采用的是避免死锁方法。每当一个事务所申请占有的资源不能被立即获得时,便进行死锁检测,不存在死锁,则该事务入等待队列。否则,DM4视为产生运行时错误,将当前语句回滚。采用这种机制,从用户的角度看,DM4不存在解锁问题。 

    7.    加索引和不加索引的封锁区别
    加索引和不加索引的情况下,DM的封锁机制会影响到实际的封锁范围。索引的作用就在于,可以在查询中减少对无关数据的扫描。而在一般的隔离级中,总是要对扫描到的数据进行封锁。所以,利用索引可以减少封锁的数量,冲突的可能性也会大大减少。




    原文链接:

    http://blog.sina.com.cn/s/blog_61e6d0d3010169p8.html

    http://blog.csdn.net/yanglilibaobao/article/details/1670026

    展开全文
  • 并发控制 目录: 1.并发操作带来的3个问题 2.封锁技术 3.封锁带来的问题 4.并发操作的调度 5.SQL对事务并发处理的支持   1.并发操作带来的几个问题 1.丢失更新问题 2.读脏数据问题 ...

    并发控制

    目录:

    1.并发操作带来的3个问题

    2.封锁技术

    3.封锁带来的问题

    4.并发操作的调度

    5.SQL对事务并发处理的支持

     

    1.并发操作带来的几个问题

    1.丢失更新问题

    2.读脏数据问题

    3.不可重复读问题

    4.幻读

     

    2.封锁技术

    定义:锁是一个与数据项相关的变量,对可能应用于该数据项上的操作而言,锁描述了该数据项的状态。

    通常在数据库中的每个数据项都有一个锁。锁的作用是使并发事务对数据库中数据项的访问能够同步。封锁技术中主要有两种封锁:排他型封锁和共享型封锁。

    1.排他型封锁(写锁,X锁)

    定义:如果事务T对某个数据R实现了X锁,那么在T对数据R解除封锁之前,不允许其他事务T再对该数据加任何类型的锁。

    2.共享型封锁(读锁,S锁)

    定义:如果事务T对某数据加上S锁后,仍允许其他事务再对该数据加S锁,但在对该数据的所有S锁都接触之前,决不允许任何事务对该数据加X锁。

    3.封锁的粒度

    X锁和S锁都是加在某一个数据对象上的。封锁的对象可以是逻辑单元,也可以是物理单元。

    定义:封锁对象的大小称为封锁的粒度。

    封锁粒度与系统的并发度和并发控制的开销密切相关。封锁的力度越大,并发度也就越小,同时系统的开销也就越小。

    因此选择封锁粒度时必须同时考虑封锁机构和并发度两个因素,对系统的开销与并发度进行权衡。

     

    3.封锁带来的问题

    采用封锁技术,可以避免并发操作引起的各种错误,但有可能产生其他3个问题:活锁,饿锁,死锁。

    1.“活锁”问题

    定义:系统可能使某个事务永远处于等待状态,得不到封锁的机会,这种现象称为“活锁”。

    解决:①先来先服务;②如果事务有优先级,可以采用等待时间长“升级”的策略。

    2.“饿锁”问题

    定义:有可能存在一个事务序列,其中每个事务都申请对某数据项加S锁,且每个事务在授权加锁后的一小段时间内释放封锁,此时若另有一个事务T2欲在该数据项上加X锁,则将永远轮不上封锁的机会。

    解决:可以用下列方式授权加锁来避免事务饿死。

    ①不存在数据项Q上持有X锁的其他事务。

    ②不存在等待对数据项Q加锁且优先于T2申请加锁的事务。

    3.“死锁”问题

    定义:系统中有两个或两个以上的事务都处于等待状态,并且每个事务都在等待其中另一个事务接触封锁,它才能继续执行下去,结果造成任何一个事务都无法继续执行,这种现象成系统进入“死锁”状态。

    解决:如果发生死锁,那么只能抽取某个事务作为牺牲品,把它撤销,做回退操作,解除它的所有封锁,恢复到该事务的初始状态。

     

    4.并发操作的调度

    1.事务的调度、串行调度和并发调度

    定义:事务的执行次序称为“调度”。如果多个事务依次执行,则称为事务的串行调度。如果利用分时的方法同时处理多个事务,则称为事务的并发调度。

    如果有n个事务并发调度,可能的并发调度数目远远大于n!。但其中有的并发调度是正确的,有的是不正确的。如何产生正确的并发调度,是由DBMS的并发控制子系统实现的。

    2.可串行化概念

    每个事务中,语句的先后顺序在各种调度中始终保持一致。在这个前提下,如果一个并发调度的执行结果与某一串行调度的执行结果等价,那么这个并发调度称为“可串行化的调度”,否则是不可串行化的调度。

     

    5.SQL对事务并发处理的支持

    SQL2对事务的存取模式隔离级别做了具体规定,并提供语句让用户使用,以控制事务的并发执行。

    1.事务的存取模式

    ①READ ONLY(只读型)。事务对数据库的操作只能是读操作。定义这个模式后,表示随后的事务均是只读型。

    ②READ WRITE(读写型)。事务对数据库的操作可以使读操作,也可以是写操作。定义了这个模式后,表示随后的事务均是读写型。在程序开始时,默认为这种模式。

    2.事务的隔离级别

    ①SERIALIZABLE(可串行化)。允许事务与其他事务并发执行,单系统必须保证并发调度是可串行化的,不致发生错误。在程序开始时默认这个级别。

    ②REPEATABLE READ(可重复读)。只允许事务读已提交的数据,并且在两次读同一个数据时不允许其他事务修改此数据。

    ③READ COMMITTED(读提交数据)。允许事务读已提交的数据,但不要求“可重复读”。

    ④READ UNCOMMITTED(可以读未提交数据)。允许事务读已提交或未提交的数据。这是SQL2中所允许的最低一致性级别。

    转载于:https://my.oschina.net/u/3786691/blog/1816299

    展开全文
  • 目录 12.1 什么是事务处理......12.2 事务处理控制语句... 1 12.2.1 COMMIT处理... 2 12.2.2 ROLL BACK处理... 2 12.2.3 SAVEPOINT和ROLL BACK TO SAVEPOINT. 3 12.2.4 SET TRANSACTION..
  • 数据库的并发控制技术

    千次阅读 2011-05-10 15:53:00
    数据库的基本概念总结 1. 数据库定义:数据库是长期储存在计算机内、有组织的、...主要功能:1,数据定义功能。2,数据组织、存储和管理。3,数据操纵功能。4,数据库的事务管理和运行管理。5,数据库的建立和维护功能
  • 本实验要求学生模拟PV操作同步机构的实现,模拟进程的并发执行,了解进程并发执行时同步机构作用。 三. 实验题目 模拟PV操作同步机构,且用PV操作解决生产者—消费者问题。 运行环境:Microsoft Visual Studio ...
  • 在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。我们现在一起来讨论下,优化的思路和方法哈。...
  • 多线程与高并发

    千次阅读 2019-05-13 18:18:57
    在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。我们现在一起来讨论下,优化的思路和方法哈。...
  • 在大住宿内部,每个部门关心的指标侧重点会不同,权限控制也都会不一样,所以数据展示的方式也是多样化。 HData每天有将近2200左右的UV,10w左右的PV来访问我们的系统,而节假日期间的访问量基本都会翻2到3倍。 从...
  • Splashtop为全球的跨国企业和中小型企业、教育机构、托管服务供应商(MSP)和个人提供安全且易于管理的远程控制和远程支持软件及服务。经过17年的发展,Splashtop现在拥有3000万全球用户、20万企业用户,支持会话...
  • 什么是服务器的高并发

    千次阅读 2018-03-02 11:18:04
    在网上购物,秒抢某个商品,比如说小米...1、大规模并发带来的挑战比如说5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。...
  • 训练营将基于一线电商平台脱敏架构应用场景,结合实操演练,帮助你切实落地实现电商系统搭建和微服务机构的优雅设计,灵活掌握JVM调优方法、SpringBoot+Dubbo等电商模块、Sentinel限流组件、Nacos等服务注册和发现...
  • 并发下秒杀系统架构

    千次阅读 2019-12-04 14:00:32
    1、秒杀业务分析 正常电子商务流程 (1)查询商品; (2)创建订单; (3)扣减库存;...假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要...
  • 一、大规模并发带来的挑战[电商秒杀与抢购]:在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。...
  • 死锁是指两个或两个以上的进程(线程)在运行过程中因争夺资源而造成的一种僵局(Deadly-Embrace) ) ,若无外力作用,这些进程(线程)都将无法向前推进。 下面我们通过一些实例来说明死锁现象。 先看生活中的一个...
  • 电商实例、业务并发、网站并发及解决方法 一、怎么防止多用户同一时间抢购同一商品,防止高并发同时下单同一商品 最近在做抢购系统,但头疼的是,在多用户高并发的情况下经常会库存出现问题。排查到,在同一时间...
  • Java高并发解决方案

    万次阅读 多人点赞 2019-03-03 22:23:50
    电商的秒杀和抢购,对我们来说,都不是一个陌生的东西。然而,从技术的角度来说,这对于Web系统是一个巨大的考验。...在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个W...
  • 在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。我们现在一起来讨论下,优化的思路和方法哈。...
  • 并发 – 相关概念 并发: 在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行,但任一个时刻点上只有一个程序在处理机上运行; 我们所说的高并发 在...
  • Java 高并发解决方案(电商的秒杀和抢购)

    万次阅读 多人点赞 2018-07-25 14:08:08
    电商的秒杀和抢购,对我们来说,都不是一个陌生的东西。然而,从技术的角度来说,这对于Web系统是一个巨大的考验。当一个Web系统,在...在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整...
  • 2w字 + 40张图带你参透并发编程!

    千次阅读 多人点赞 2020-08-19 07:28:16
    并发历史 在计算机最早期的时候,没有操作系统,执行程序只需要一种方式,那就是从头到尾依次执行。任何资源都会为这个程序服务,在计算机使用某些资源时,其他资源就会空闲,就会存在 浪费资源 的情况。 这里说的...
  • 并发支付场景分析及设计

    千次阅读 2018-12-04 23:46:09
    一、专题分享-高并发支付场景分析及设计1.1 背景 大家好,我是20XX年加入永乐票务,之前一直负责公司票务系统的整体规划、实现、优化及改造。目前主要负责公司的基础平台、支付平台、消息平台、云平台、运维平台、...
  • 一、实习内容 模拟实现用同步机构避免发生进程执行时可能出现的与时间有关的错误。 二、实习目的 ...本实习要求学生模拟PV操作同步机构的实现,模拟进程的并发执行,了解进程并发执行时同步机构作用
  • Web系统大规模并发处理

    千次阅读 2017-01-23 22:11:57
    面对5w每秒的高并发秒杀功能,如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。我们现在一起来讨论下,优化的思路和方法哈。  1. 请求接口的合理设计 一个秒杀或者抢购页面,通常分为2个部分,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 27,525
精华内容 11,010
热门标签
关键字:

并发控制机构的功能是