|
知识路径: > 计算机系统知识 > 系统配置和方法 > 系统配置技术 > 事务管理(并发控制、独占控制、故障恢复、回滚、前滚) >
|
被考次数:1次
被考频率:低频率
总体答错率:41%  
知识难度系数:
|
由 软考在线 用户真实做题大数据统计生成
|
相关知识点:14个
|
|
|
|
|
所谓事务是用户定义的一个数据库操作序列,这些操作要么全做要么全不做,是一个不可分割的工作单位。事务和程序是两个概念。一般地讲,一个程序中包含多个事务。例如,在关系数据库中,一个事务可以是一条SQL语句、一组SQL语句或整个程序。
|
|
|
事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务,则由DBMS按默认规定自动划分事务。在SQL语言中,定义事务的语句有三条:
|
|
|
|
|
|
事务通常是以BEGIN TRANSACTION开始,以COMMIT或ROLLBACK结束。COMMIT表示提交,即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去,事务正常结束。ROLLBACK表示回滚,即在事务运行的过程中发生了某种故障,事务不能继续执行,系统将事务中对数据库的所有已完成的操作全部撤销,滚回到事务开始时的状态。这里的操作指对数据库的更新操作。
|
|
|
事务具有4个特性:原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持续性(durability),这四个特性也简称为ACID特性。
|
|
|
|
事务是数据库的逻辑工作单位,事务中包括的诸操作要么都做,要么都不做。
|
|
|
|
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时,就说数据库处于一致性状态。如果数据库系统运行中发生故障,有些事务尚未完成就被迫中断,这些未完成事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态,或者说是不一致的状态。
|
|
|
|
一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。
|
|
|
|
持续性也称永久性(permanence),指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
|
|
|
事务是恢复和并发控制的基本单位。所以下面的讨论均以事务为对象。
|
|
|
|
事务可以一个一个地串行执行,即每个时刻只有一个事务运行,其他事务必须等到这个事务结束以后方能运行。事务在执行过程中需要不同的资源,有时需要CPU,有时需要存取数据库,有时需要I/O,有时需要通信。如果事务串行执行,则许多系统资源将处于空闲状态。因此,为了充分利用系统资源发挥数据库共享资源的特点,应该允许多个事务并行地执行。在单处理机系统中,事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行。这种并行执行方式称为交叉并发方式(Interleaved Concurrency)。当多个用户并发地存取数据库时就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会存取和存储不正确的数据,破坏数据库的一致性。所以数据库管理系统必须提供并发控制机制。并发控制机制是衡量一个数据库管理系统性能的重要标志之一。
|
|
|
事务是并发控制的基本单位,保证事务ACID特性是事务处理的重要任务,而事务ACID特性可能遭到破坏的原因之一是多个事务对数据库的并发操作造成的。为了保证事务的隔离性和数据库的一致性,DBMS需要对并发操作进行正确调度。这些就是数据库管理系统中并发控制机制的责任。并发操作带来的数据不一致性包括三类。丢失修改、不可重复读和读“脏”数据。产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作,使一个用户事务的执行不受其他事务的干扰,从而避免造成数据的不一致性。
|
|
|
封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前,先向系统发出请求,对其加锁。加锁后事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,其他的事务不能更新此数据对象。
|
|
|
确切的控制由封锁的类型决定。基本的封锁类型有两种:排它锁(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做任何修改。
|
|
|
尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏,保证并发事务的正确执行,但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的,这些故障轻则造成运行事务非正常中断,影响数据库中数据的正确性,重则破坏数据库,使数据库中全部或部分数据丢失,因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的功能,这就是数据库的恢复。恢复子系统是数据库管理系统的一个重要组成部分,而且还相当庞大,常常占整个系统代码的百分之十以上。数据库系统所采用的恢复技术是否行之有效,不仅对系统的可靠程度起着决定性作用,而且对系统的运行效率也有很大影响,是衡量系统性能优劣的重要指标。
|
|
|
事务内部的故障有的是可以通过事务程序本身发现,有的是非预期的,不能由事务程序处理的。事务内部更多的故障是非预期的,是不能由应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制等。以后,事务故障仅指这类非预期的故障。
|
|
|
事务故障意味着事务没有达到预期的终点(commit或者显式的rollback),因此,数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下,强行回滚(rollback)该事务,即撤销该事务已经做出的任何对数据库的修改,使得该事务好像根本没有启动一样。这类恢复操作称为事务撤销(undo)。
|
|
|
发生系统故障时,一些尚未完成的事务的结果可能已送入物理数据库,从而造成数据库可能处于不正确的状态。为保证数据一致性,需要清除这些事务对数据库的所有修改。恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚,强行撤销(undo)所有未完成事务。
|
|
|
另一方面,发生系统故障时,有些已完成的事务可能有一部分甚至全部留在缓冲区,尚未写回到磁盘上的物理数据库中,系统故障使得这些事务对数据库的修改部分或全部丢失,这也会使数据库处于不一致状态,因此应将这些事务已提交的结果重新写入数据库。所以系统重新启动后,恢复子系统除需要撤销所有未完成事务外,还需要重做(redo)所有已提交的事务,以将数据库真正恢复到一致状态。
|
|
|