《数据库实用教程董健全丁宝康编著1》由会员分享，可在线阅读，更多相关《数据库实用教程董健全丁宝康编著1（60页珍藏版）》请在金锄头文库上搜索。
1、第8章 数据库的管理 在DBS运行时，DBMS要对DB进行监控，以保证整个系统的正常运行，防止数据意外丢失和不一致数据的产生。DBMS对DB的监控，称为数据库的管理，有时也称为数据库的保护。对数据库的管理主要通过四个方面实现：数据库的恢复、并发控制、完整性控制和安全性控制。每一方面构成了DBMS的一个子系统。本章先介绍事务的概念，然后介绍这四个子系统如何实现对数据库的管理。8.1 事 务 的 概 念8.1.1事务的定义从用户观点看，对数据库的某些操作应是一个整体，也就是一个独立的工作单元，不能分割。譬如，客户认为电子资金转账（从账号A转一笔款子到账号B）是一个独立的操作，而在DBS中这是由几个
2、操作组成的。显然，这些操作要么全都发生，要么由于出错（可能账号A已透支）而全不发生。保证这一点非常重要，我们决不允许发生下面的 事情：在账号A透支情况下继续转账；或者从账号A转出了一笔钱，而不知去向未能转入账号B中。这样就引 出了事务的概念。定义8.1 事务（Tansaction）是构成单一逻辑工作单元的操作集合。DBS的主要意图是执行“事务”。事务是数据库环 境中一个逻辑工作单元，相当于操作系统环境中的“ 进程”概念。一个事务由应用程序中的一组操作序列 组成，在程序中，事务以BEGIN TRANSACTION语句开始，以COMMIT语句或 ROLLBACK语句结束。COMMIT语句表示事务执
3、行成功地结束（提交），此时告诉系统，数据库要进入一个新的正确状态，该事务对数据库的所有更新都已交付实施（写入磁盘）。ROLLBACK语句表示事务执行不成功地结束（应该“回退”），此时告诉系统，已发生错误，数据库可能处在不正确的状态，该事务对数据库的所有更新必须被撤消，数据库应恢复该事务到初始状态。8.1.2 事务的ACID性质 为了保证数据完整性（数据是正确的）,我们要求 事务具有下列四个性质：1. 原子性（Atomicity） 一个事务对数据库的所有操作，是一个不可分割的工作单元。这些操作要么全部执行，要么什么也不 做（就效果而言）。保证原子性是数据库系统本身的职责，由DBMS的 事务管理子
4、系统来实现。2. 一致性（Consistency）一个事务独立执行的结果，应保持数据库的一致 性，即数据不会因事务的执行而遭受破坏。确保单个事务的一致性是编写事务的应用程序员 的职责。在系统运行时，由DBMS的完整性子系统执行 测试任务。3. 隔离性（Isolation）在多个事务并发执行时，系统应保证与这些事务 先后单独执行时的结果一样，此时称事务达到了隔离 性的要求。也就是在多个事务并发执行时，保证执行结果是 正确的，如同单用户环境一样。隔离性是由 DBMS的并发控制子系统实现的。4. 持久性（Durability）一个事务一旦完成全部操作后，它对数据库的所 有更新应永久地反映在数据库中。
5、即使以后系统发生 故障，也应保留这个事务执行的痕迹。持久性是由 DBMS的恢复管理子系统实现的。上述四个性质称为事务的ACID性质，这一缩写来 自四条性质的第一个英文字母。例8.1设银行数据库中有一转账事务T，从账号A转一笔款子（50）到账号B，其操作如下：T：read（A）; A:=A 50 ; write（A）;read（B）; B:= B+ 50 ; write（B）（l）（一致性）在事务T执行结束后，要求数据库中A的值减 50, B的值增加 50，也就是A与B的和不变，此时称数据库处于一致状态。如果A的值减了50，而 B的值未变，那么称数据库处于不一致状态。事务的执行结果应保证数据库仍
6、然处于一致的状态。 （2）（原子性）从事务的一致性可以看出，事务 中所有操作应作为一个整体，不可分割，要么全做， 要么全不做。假设由于电源故障、硬件故障或软件出 错等，造成事务 T执行的结果只修改了A值而未修改B 值，那么就违反了事务的原子性。事务的原子性保证了事务的一致性。但是在事务 T执行过程中，譬如某时刻数据库中A值已减了 50，而 B值尚未增，显然这是一个不一致的状态。但是这个不 一致状态将很快由于 B值增加 50而又改变成一致的状 态。事务执行中出现的暂时不一致状态，是不能让用 户知道的，用户也不用为此担忧。（3）（持久性）一旦事务成功地完成执行，并且告知用户转账已经发生，系统就必须
7、保证以后任何故障都不会再引起与这次转账相关的数据的丢失。持久性保证一旦事务成功完成，该事务对数据库施加的所有更新都是永久的。也就是计算机系统的故障将会导致内存的数据丢失，但已写入磁盘的数据决不会丢失。DBMS的事务管理子系统和恢复管理子系统的密切配合，保证了事务持久性的实现。 （4）（隔离性）多个事务并发执行时，相互之间应该互不干扰。譬如事务T在A值减50后，系统暂时处于不一致状态。此时若第二个事务插进来计算A与B之和，则得到错误的数据；甚至于第三个事务插进来修改 A、B的值，势必造成数据库中数据有错。DBMS的并发控制子系统尽可能提高事务的并发程度，而又不让错误发生。8.2 数据库的恢复8.
8、2.1 恢复的定义、原则和方法1恢复的定义 在DBS运行时，可能会出现各式各样的故障，譬如磁盘损坏、电源故障、软件错误、机房火灾和恶意破坏等。在发生故障时，很可能丢失数据库中的数据。DBMS的恢复管理子系统采取一系列措施保证在任何情况下保持事务的原子性和持久性，确保数据不丢失、不破坏。定义 8.2 系统能把数据库从被破坏、不正确的 状态、恢复到最近一个正确的状态，DBMS的这种能力 称为数据库的可恢复性（Recovery）。2. 恢复的基本原则和实现方法要使数据库具有可恢复性，基本原则很简单，就 是“冗余”，即数据库重复存储。数据库恢复具体实现方法如下：(1) 平时做好两件事：转储和建立日志。
9、周期性地(比如一天一次）对整个数据库进行 拷贝，转储到另一个磁盘或磁带一类存储介质中。 建立日志数据库。记录事务的开始、结束标志，记录事务对数据库的每一次插入、删除和修改前后 的值，写到“日志”库中，以便有案可查。（2）一旦发生数据库故障，分两种情况进行处理：如果数据库已被破坏，例如磁头脱落、磁盘损坏等，这时数据库已不能用了，就要装入最近一次拷 贝的数据库备份到新的磁盘，然后利用日志库执行“ 重做”（REDO）处理，将这两个数据库状态之间的所 有更新重新做一遍。这样既恢复了原有的数据库，又没有丢失对数据库的更新操作。 如果数据库未被破坏，但某些数据不可靠，受到怀疑。例如程序在批处理修改数据库时
10、异常中断。这时不必去拷贝存档的数据库。只要通过日志库执行“撤消”（UNDO）处理，撤消所有不可靠的修改，把数据库恢复到正确的状态。恢复的原则很简单，实现的方法也比较清楚，但做起来相当复杂。8.2.2 故障类型和恢复方法在DBS引入事务概念以后，数据库的故障可以用事务的故障表示。也就是数据库的故障具体体现为事务执行的成功与失败。常见的故障可分成下面三类。1. 事务故障事务故障又可分为两种：（1）可以预期的事务故障，即在程序中可以预先估计到的错误，譬如存款余额透支,商品库存量达到最低量等，此时继续取款或发货就会出现问题。这种情况可以在事务的代码中加入判断和 ROLLBACK语句。当事务执行到 RO
11、LLBACK语句时，由系统对事务进行回退操作，即执行UNDO操作。（2）非预期的事务故障，即在程序中发生的未估计到的错误，譬如运算溢出、数据错误、 并发事务发生死锁而被选中撤消该事务等。此时由系统直接对该事务执行UNDO处理。 2系统故障引起系统停止运转随之要求重新启动的事件称为“系统故障”。例如硬件故障、软件故障（DBMS、OS或应用程序）错误或掉电等几种情况，都称为系统故障。系统故障要影响正在运行的所有事务，并且主存内容丢失，但不破坏数据库。由于故障发生时正在运行的事务都非正常终止，从而造成数据库中某些数据不正确。DBMS的恢复子系统必须在系统重新启动时，对这些非正常终止的事务进行处理，把
12、数据库恢复到正确的状态。 重新启动时，具体处理分两种情况考虑。（1）对未完成事务作UNDO处理。（2）对已提交事务但更新还留在缓冲区的事务进行REDO处理。3介质地障在发生介质故障和遭受病毒破坏时，磁盘上的物理数据库遭到毁灭性破坏。此时恢复过程则下：（1）重装转储的后备副本到新的磁盘使数据库恢复到转储时的一致状态。 （2）在日志中找出转储以后所有已提交的事务。（3）对这些已提交的事务进行 REDO处理，将数据库恢复到故障前某一时刻的一致状态。事务故障和系统故障的恢复由系统自动进行，而介质故障的恢复需要DBA配合执行。在实际中，系统故障通常称为软故障（Soft Crash），介质故障通常称为硬故
13、障(Hard Crash)。8.2.3 检 查 点 机 制1. 检查点方法前面多次提到REDO（重做）和UNDO（撤消）处理，具体实现是一件比较复杂的工作。现在许多 DBMS产品提供一种检查点（Checkpoint）方法实现数据库的恢复。DBMS定时设置检查点。在检查点时刻才真正做到把对DB的修改写到磁盘，并在日志文件写入一条检查点记录（以便恢复时使用）。当DB需要恢复时，只有那些在检查点后面的事务需要恢复。若每小时进行34次检查，则只有不超过1520分钟的处理需要恢复。这种检查点机制大大减少了DB恢复的时间。一 般DBMS产品自动实行检查点操作，无须人工干预。 此方法如图9l所示。设DBS运
14、行时，在tc时刻产生了一个检查点，而在 下一个检查点来临之前的tf时刻系统发生故障。我们把这一阶段运行的事务分成五类（T1T5）（1）事务T1不必恢复。因为它们的更新已在检查点tc时写到数据库中去了。 （2）事务T2和事务T4必须重做（REDO）。因为它们结束在下一个检查点之前，它们对DB的修改仍在内 存缓冲区，还未写到磁盘。事务T3和事务T5必须撤消（UNDO）。因为它们还 未做完，必须撤消事务已对DB作的修改。2检查点方法的恢复算法采用检查点方法的基本恢复算法分成两步。（1）根据日志文件建立事务重做队列和事务撤消队列。此时，从头扫描日志文件（正向扫描），找出在故障发生前已经提交的事务（这些
15、事务执行了COMMIT），将其事务标识记入重做队列。同时，还要找出故障发生时尚未完成的事务（这些事务还未执行COMMIT），将其事务标识记入撤消队列。（2）对重做队列中的事务进行REDO处理，对撤消队列中的事务进行UNDO处理。进行REDO处理的方法是：正向扫描日志文件，根据重做队列的记录对每一个重做事务重新实施对数据库的更新操作。进行UNDO处理的方法是：反向扫描日志文件，根据撤消队列的记录对每一个撤消事务的更新操作执行逆操作（对插入操作执行删除操作，对删除操作执行插入操作，对修改操作则用修改前的值代替修改后的值）。8.2.4 运行记录优先原则从前面的恢复处理可以看出，写一个修改到数据库中和
16、写一个表示这个修改的运行记录到日志中是两个不同的操作。这样就有可能在这两个操作之间发生故障。那么先写入的一个得以保留下来，而另一个就丢失了。如果保留下来的是数据库的修改，而在运行日志中没有记录下这个修改，那么以后就无法撤消这个修改了。因此，为了安全，运行记录应该先写下来，这就是“运行记录优先原则”，具体有两点： （1）至少要等相应运行记录已经写入运行日志后，才能允许事务往数据库中写记录；（2）直至事务的所有运行记录都已经写入到运行日志后，才能允许事务完成COMMIT处理。这样，如果出现故障，则可能在运行日志中而不是在数据库中记录了一个修改。在重启动时，就有可能请求UNDOREDO处理原先根本没有对数据库做过的修改。8.2.5 SQL对事务的支持SQL语言对事务的支持以及对基于事务的恢复的支持都遵循前面的概念。SQL支持通常的COMMIT和ROLLBACK语句。但这语句将强制每个打
