数据库的控制

第五章数据库的控制第一节数据库恢复技术事务是一系列的数据库操作，是数据库应用程序的基本逻辑单元。事务处理技术主要 包括数据库恢复技术和并发控制技术。数据库恢复机制和并发控制机制是数据库管理系统 的重要组成部分。本章讨论数据库恢复的概念和常用技术。1.1事务的基本概念在讨论数据库恢复技术之前先讲解事务的基本概念和事务的性质。一、事务(Transaction)所谓事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个 不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条SQL语句、一组SQL 语句或整个程序。事务和程序是两个概念。一般地讲，一个程序中包含多个事务。事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由DBMS 按缺省规定自动划分事务。在SQL语言中，定义事务的语句有三条：BEGINTRANSACTIONCOMMITROLLBACK事务通常是以BEGINTRANSACTION开始，以COMMIT或ROLLBACK结束。COMMIT表 示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘 上的物理数据库中去，事务正常结束。ROLLBACK表示回滚，即在事务运行的过程中发生 了某种故障，事务不能继续执行，系统将事务中对数据库的所有己完成的操作全部撤销， 滚回到事务开始时的状态。这里的操作指对数据库的更新操作。二、事务的特性事务具有四个特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation) 和持续性(Durability)。这个四个特性也简称为ACID特性。1. 原子性事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。2. 一致性事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数 据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中 发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分 己写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。例如 某公司在银行中有A，B两个账号，现在公司想从账号A中取出一万元，存入账号B。那么 就可以定义一个事务，该事务包括两个操作，第1个操作是从账号A中减去一万元，第2 个操作是向账号B中加入一万元。这两个操作要么全做，要么全不做。全做或者全不做， 数据库都处于一致性状态。如果只做一个操作则用户逻辑上就会发生错误，少了一万元， 这时数据库就处于不一致性状态。可见一致性与原子性是密切相关的。3. 隔离性一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并 发事务是隔离的，并发执行的各个事务之间不能互相干扰。4. 持续性持续性也称永久性(Permanence)，指一个事务一旦提交，它对数据库中数据的改变就 应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。事务是恢复和并发控制的基本单位。所以下面的讨论均以事务为对象。保证事务ACID特性是事务处理的重要任务。事务ACID特性可能遭到破坏的因素有：(1) 多个事务并行运行时，不同事务的操作交叉执行：(2) 事务在运行过程中被强行停止。在第一种情况下，数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原 子性。在第二种情况下，数据库管理系统必须保证被强行终止的事务对数据库和其他事务 没有任何影响。这些就是数据库管理系统中恢复机制和并发控制机制的责任。1.2数据库恢复概述尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证 并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶 意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的 正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统必须具 有把数据库从错误状态恢复到某一己知的正确状态(亦称为一致状态或完整状态)的功能， 这就是数据库的恢复。恢复子系统是数据库管理系统的一个重要组成部分，而且还相当庞 大，常常占整个系统代码的百分之十以上。数据库系统所采用的恢复技术是否行之有效， 不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大影响，是衡量系 统性能优劣的重要指标。1.3故障的种类数据库系统中可能发生各种各样的故障，大致可以分以下几类：一、事务内部的故障事务内部的故障有的是可以通过事务程序本身发现的（见下面转账事务的例子），有的 是非预期的，不能由事务程序处理的。例如：银行转账事务，这个事务把一笔金额从一个账户甲转给另一个账户乙。BEGINTRANSACTION读账户甲的余额BALANCE;BALANCE=BALANCE-AMOUNT;（AMOUNT 为转账金额） IF（BALANCE<0）THEN打印金额不足，不能转账；ROLLBACK;（撤销刚才的修改，恢复事务）ELSE读账户乙的余额BALANCE1;BALANCE1二BALANCE1+AMOUNT;写回 BALANCE1;COMMIT;这个例子所包括的两个更新操作要么全部完成要么全部不做。否则就会伸数据库处 于不一致状态，例如只把账户甲的余额减少了而没有把账户乙的余在增加。在这段程序中若产生账户甲余额不足的情况，应用程序可以发现并让事务滚回，撤 销己作的修改，恢复数据库到正确状态。事务内部更多的故障是非预期的，是不能由应用程序处理的。如运算溢出、并发事 务发生死锁而被选中撤销该事务、违反了某些完整性限制等。以后，事务故障仅指这类非 预期的故障。R事务故障意味着事务没有达到预期的终点（COMMIT或者显式的OLLBACK），因此，数据 库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚 （ROLLBACK）该事务，即撤销该事务已经作出的任何对数据库的修改，使得该事务好像根 本没有启动一样。这类恢复操作称为事务撤销（UNDO）二、系统故障系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如特定类型 的硬件错误(CPU故障)、操作系统故障、DBMS代码错误、突然停电等。这类故障影响正在 运行的所有事务，但不破坏数据库。这时主存内容尤其是数据库缓冲区(在内存)中的内容 都被丢失，所有运行事务都非正常中止。发生系统故障时，一些尚未完成的事务的结果可 能己送入物理数据库;从而造成数据库可能处于不正确的状态。为保证数据一致性，需要 清除这些事务对数据库的所有修改。恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销(UNDO) 所有未完成事务。另一方面，发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区， 尚未写回到磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或全部丢 失，这也会使数据库处于不一致状态，因此应将这些事务己提交的结果重新写入数据库。 所以系统重新启动后，恢复子系统除需要撤销所有未完成事务外，还需要重做(REDO)所有 己提交的事务，以将数据库真正恢复到一致状态。三、介质故障系统故障常称为软故障(SoftCrash)，介质故障称为硬故障(HardCrash)。硬故障指外 存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破坏数据库或部分数据 库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多， 但破坏性最大。四、计算机病毒计算机病毒是一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序。这种 程序与其他程序不同，它像微生物学所称的病毒一样可以繁殖和传播，并造成对计算机系 统包括数据库的危害。病毒的种类很多，不同病毒有不同的特征。小的病毒只有20条指令，不到50B。大 的病毒像一个操作系统，由上万条指令组成。有的病毒传播很快，一旦侵入系统就马上摧毁系统;有的病毒有较长的潜伏期，机器 在感染后数天或数月才开始发病；有的病毒感染系统所有的程序和数据；有的只对某些特 定的程序和数据感兴趣。多数病毒一开始并不摧毁整个计算机系统，它们只在数据库中或 其他数据文件中将小数点向左或向右移一移，增加或删除一两个0。计算机病毒己成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。为此计 算机的安全工作者己研制了许多预防病毒的疫苗"，检查、诊断、消灭计算机病毒的软件 也在不断发展。但是，至今还没有一种使得计算机'终生免疫的疫苗。因此数据库一旦被 破坏仍要用恢复技术把数据库加以恢复。总结各类故障，对数据库的影响有两种可能性。一是数据库本身被破坏。二是数据库 没有破坏，但数据可能不正确，这是因为事务的运行被非正常终止造成的。恢复的基本原理十分简单。可以用一个词来概括：冗余。这就是说，数据库中任何一 部分被破坏的或不正确的数据可以根据存储在系统别处的元余数据来重建。尽管恢复的基 本原理很简单但实现技术的细节却相当复杂，下面略去一些细节，介绍数据库恢复的实现 技术。1.4恢复的实现技术恢复机制涉及的两个关键问题是：第一，如何建立冗余数据：第二，如何利用这些冗 余数据实施数据库恢复。建立冗余数据最常用的技术是数据转储和登录日志文件。通常在一个数据库系统中， 这两种方法是一起使用的。1数据转储数据转储是数据库恢复中采用的基本技术。所谓转储即DBA定期地将整个数据库复 制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副 本。当数据库遭到破坏后可以将后备副本重新装入，但重装后备副本只能将数据库恢复到 转储时的状态，要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务。 例如在图7.1中，系统在乙时刻停止运行事务进行数据库转储，在几时刻转储完毕，得到 Tb时刻的数据库一致性副本。系统运行到Tf时刻发生故障。为恢复数据库，首先由DBA 重装数据库后备副本，将数据库恢复至Tb时刻的状态，然后重新运行自TbTf时刻的所有 更新事务，这样就把数据库恢复到故障发生前的一致状态。转储是十分耗费时间和资源的，不能频繁进行。DBA应该根据数据库使用情况确定一 个适当的转储周期。转储可分为静态转储和动态转储。静态转储是在系统中无运行事务时进行的转储操作。即转储操作开始的时刻，数据库 处于一致性状态，而转储期间不允许(或不存在)对数据库的任何存取、修改活动。显然， 静态转储得到的一定是一个数据一致性的副本。静态转储简单，但转储必须等待正运行的用户事务结束才能进行，同样，新的事务必 须等待转储结束才能执行。显然，这会降低数据库的可用性。动态转储是指转储期间允许对数据库进行存取或修改。即转储和用户事务可以并发执 行。动态转储可克服静态转储的缺点，它不用等待正在运行的用户事务结束，也不会影响新 事务的运行。但是，转储结束时后援副本上的数据并不能保证正确有效。例如，在转储期间 的某个时刻Tc，系统把数据A=100转储到磁带上，而在下一时刻Td，某一事务将A改为200。 转储结束后，后备副本上的A已是过时的数据了。为此，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件(log file)。 这样，后援副本加上日志文件就能把数据库恢复到某一时刻的正确状态。转储还可以分为海量转储和增量转储两种方式。海量转储是指每次转储全部数据库。 增量转储则指每次只转储上一次转储后更新过的数据。从恢复角度看，使用海量转储得到 的后备副本进行恢复一般说来会更方便些。但如果数据库很大，事务处理又十分频繁，则 增量转储方式更实用更有效。数据转储有两种方式，分别可以在两种状态下进行，因此数据转储方法可以分为 四类：动态海量转储、动态增量转储、静态海量转储和静