数据库并发控制Word格式文档下载.docx
《数据库并发控制Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《数据库并发控制Word格式文档下载.docx（13页珍藏版）》请在冰豆网上搜索。
并发控制的单位――事务
事务是数据库的逻辑工作单位，它是用户定义的一组操作序列。
一个事务可以是一组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并写回覆盖了甲事务的修改。
并发操作带来的数据库不一致性可以分为四类：
丢失或覆盖更新、脏读、不可重复读和幻像读，上例只是并发问题的一种。
<
!
--[if!
supportLists]-->
（1）
<
--[endif]-->
丢失或覆盖更新（lostupdate）
当两个或多个事务选择同一数据，并且基于最初选定的值更新该数据时，会发生丢失更新问题。
每个事务都不知道其它事务的存在。
最后的更新将重写由其它事务所做的更新，这将导致数据丢失。
上面预定飞机票的例子就属于这种并发问题。
事务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）
不可重复读（nonrepeatableread）
一个事务重新读取前面读取过的数据，发现该数据已经被另一个已提交的事务修改过。
即事务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采用的就是这种方法，SQLServer也是采用的这种方法）来保证调度的正确性；
即保证并行操作调度的可串行性。
除此之外还有其他一些方法，如时标方法、乐观方法等。
•
悲观并发控制
锁定系统阻止用户以影响其它用户的方式修改数据。
如果用户执行的操作导致应用了某个锁，则直到这个锁的所有者释放该锁，其它用户才能执行与该锁冲突的操作。
该方法主要用在数据争夺激烈的环境中，以及出现并发冲突时用锁保护数据的成本比回滚事务的成本低的环境中，因此称该方法为悲观并发控制。
乐观并发控制
在乐观并发控制中，用户读数据时不锁定数据。
在执行更新时，系统进行检查，查看另一个用户读过数据后是否更改了数据。
如果另一个用户更新了数据，将产生一个错误。
一般情况下，接收错误信息的用户将回滚事务并重新开始。
该方法主要用在数据争夺少的环境内，以及偶尔回滚事
升级会员 