|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。数据库故障主要分为事务故障、系统故障和介质故障，不同故障的恢复方法也不同。
|
|
|
|
|
|
事务故障是指事务在运行至正常终点前被终止，此时数据库可能处于不正确的状态，恢复程序要在不影响其他事务运行的情况下强行回滚（rollback）该事务，即撤销该事务已经做出的任何对数据库的修改，使得事务好像完全没有启动一样。事务故障的恢复由系统自动完成。恢复的步骤是：
|
|
|
|
（1）反向（从后向前）扫描日志文件，查找该事务的更新操作。
|
|
|
|
（2）对该事务的更新操作执行逆操作，也就是将日志记录更新前的值写入数据库。如果记录中是插入操作，则相当于做删除操作，如果记录中是删除操作则做插入操作，若是修改操作则相当于用修改前的值代替修改后的值。
|
|
|
|
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
|
|
|
|
（4）如此处理下去，直到读到了此事务的开始标记，事务故障恢复就完成了。
|
|
|
|
|
|
系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误、操作系统故障、DBMS代码错误、突然停电等。这类故障影响正在运行的所有事务，但不会破坏数据库。此时主存内容（尤其是缓冲区中的内容）都将被丢失，所有运行事务都被非正常终止，有些已完成的事务可能有部分甚至全部留在缓冲区中尚未被写入磁盘，为了保证一致性，应将这些事务已提交的结果重新写入数据库；此外，一些尚未完成的事务结果可能已经被送入物理数据库，为了保证一致性，需要清除这些事务对数据库的所有修改。系统故障的恢复是由系统在重新启动时自动完成的，此时恢复子系统撤销所有未完成的事务并重做（redo）所有已提交的事务。具体的步骤是：
|
|
|
|
（1）正向（从头到尾）扫描日志文件，找出故障发生前已经提交的事务（这些事务既有Begin Transaction记录，也有commit记录），将其事务标识记入重做（redo）队列。同时找出故障发生时尚未完成的事务（这些事务只有Begin Transaction记录，无相应的commit记录），将其事务标识记入撤销（undo）队列。
|
|
|
|
（2）反向扫描日志文件，对每个undo事务的更新操作执行逆操作，也就是将日志记录中更新前的值写入数据库。
|
|
|
|
（3）正向扫描日志文件，对每个redo事务重新执行日志文件登记的操作，也就是将日志记录中更新后的值写入数据库。
|
|
|
|
|
|
系统故障常被称为软故障，介质故障常被称为硬故障。硬故障是指外存故障，例如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务，日志文件也将被破坏。这类故障比前两类故障发生的可能性要小，但是破坏性最大。恢复方法是重装数据库，然后重做已完成的事务，具体的步骤是：
|
|
|
|
（1）装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
|
|
|
|
|
|
介质故障的恢复需要DBA的介入，DBA只需重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令，具体的恢复操作仍由DBMS完成。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
顺序查找又称线性查找，顺序查找的过程是从线性表的一端开始，依次逐个与表中元素的关键字值进行比较，如果找到其关键字与给定值相等的元素，则查找成功；若表中所有元素的关键字与给定值比较都不成功，则查找失败。
|
|
|
|
|
|
折半查找的过程是先将给定值与有序线性表中间位置上元素的关键字进行比较，若两者相等，则查找成功；若给定值小于该元素的关键字，那么选取中间位置元素关键字值小的那部分元素作为新的查找范围，然后继续进行折半查找；如果给定值大于该元素的关键字，那么选取比中间位置元素关键字值大的那部分元素作为新的查找范围，然后继续进行折半查找，直到找到关键字与给定值相等的元素或查找范围中的元素数量为零时结束。
|
|
|
|
|
|
在分块查找过程中，首先将表分成若干块，每一块中关键字不一定有序，但块之间是有序的。此外，还建立了一个索引表，索引表按关键字有序。分块查找过程需分两步进行：先确定待查记录所在的块；然后在块中顺序查找。
|
|
|
|
|
|
根据设定的哈希函数H（key）和处理冲突的方法，将一组关键字映射到一个有限的连续地址集上，并以关键字在地址集中的像作为记录在表中的存储位置，这种表称为哈希表，也称散列表。这一过程所得到的存储位置称为散列地址，由此形成的查找方法称为散列查找。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样的处理，直到事务的开始标志。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事务日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中，这种文件就称为日志文件。对于任何一个事务，事务日志都有非常全面的记录，根据这些记录可以将数据文件恢复成事务前的状态。从事务动作开始，事务日志就处于记录状态，事务执行过程中对数据库的任何操作都记录在内，直到用户提交或回滚后才结束记录。
|
|
|
|
日志文件是用来记录对数据库每一次更新活动的文件，在动态备份方式中，必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库；在静态备份方式中，也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到备份结束时刻的正确状态，然后利用日志文件，把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态。
|
|
|
|
例如，在热备份期间的某时刻t1，系统把数据A=100备份到了磁带上，而在时刻t2，某一事务对A进行了修改使A=200。备份结束，后备副本上的A已是过时的数据了。为此，必须把备份期间各事务对数据库的修改活动登记下来，建立日志文件。这样，后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态。
|
|
|
|
事务在运行过程中，系统把事务开始、事务结束（包括COMMIT和ROLLBACK），以及对数据库的插入、删除、修改等每一个操作作为一个登记记录存放到日志文件中。每个记录包括的主要内容有：执行操作的事务标识、操作类型、更新前数据的旧值（对插入操作而言此项为空值）、更新后的新值（对删除操作而言此项为空值）。登记的次序严格按并行事务操作执行的时间次序，同时遵循“先写日志文件”的规则。写一个修改到数据库中和写一个表示这个修改的日志记录到日志文件中是两个不同的操作，有可能在这两个操作之间发生故障，即这两个写操作只完成了一个，如果先写了数据库修改，而在日志记录中没有登记这个修改，则以后就无法恢复这个修改了。因此，为了安全，应该先写日志文件，即首先把修改记录写到日志文件上，然后再写数据库的修改。这就是“先写日志文件”的原则。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事务（Transaction）是一系列的数据库操作，是数据库应用程序的基本逻辑单位，即应用程序对数据库的操作都应该以事务的方式进行。
|
|
|
|
事务是一个操作序列，这些操作“要么都做，要么都不做”，是数据库环境中不可分割的逻辑工作单位。事务和程序是两个不同的概念，一般一个程序可包含多个事务。
|
|
|
|
事务通常由数据库操纵语言或其他高级语言（如SQL、CoBOL、C、C++、Java等）书写的用户程序来实现。一个事务由应用程序的一组操作序列组成，它以BEGIN TRANSACTION语句开始，以END TRANSACTION结束语句。
|
|
|
|
|
|
（1）BEGIN TRANSACTION：事务开始。
|
|
|
|
|
|
（3）COMMIT：事务提交。该操作表示事务成功地结束，它将通知事务管理器该事务的所有更新操作现在可以被提交或永久地保留。
|
|
|
|
（4）ROLLBACK：事务回滚。该操作表示事务非成功地结束，它将通知事务管理器出故障了，数据库可能处于不一致状态，该事务的所有更新操作必须回滚或撤销。
|
|
|
|
典型的例子是银行转账业务。对“从账户A转入账户B金额x元”业务，站在顾客角度来看，转账是一次单独操作；而站在数据库系统的角度它至少是由两个操作组成的，第一步从账户A减去x元，第二步给账户B加上x元。下面是银行转账事务的伪代码：
|
|
|
|
|
|
|
|
SQL标准规定当一条SQL语句被执行，就隐式地开始了一个事务，SQL中的Commit work和Rollback work语句之一会结束一个事务。
|
|
|
|
（1）Commit work：提交当前事务。这意味着将该事务所做的更新在数据库中永久保存。一旦事务被提交后，一个新的事务自动开始。
|
|
|
|
（2）Rollback work：回滚当前事务。这意味着将撤销该事务对数据库的更新。这样，数据库恢复到该事务执行第一条语句之前的状态。
|
|
|
|
需要注意的是，若事务已执行了Commit work，就不能用Rollback work来撤销。数据库系统能保证在发生诸如某条SQL语句错误、断电、系统崩溃的情况下，若事务还没有执行Commit work，则所造成的影响将被回滚。对断电、系统崩溃的情况，回滚是在系统重新启动时进行。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事务故障（transaction failure）是由于程序执行错误而引起事务非预期的、异常终止的故障。通常有如下两类错误引起事务执行失败。
|
|
|
|
（1）逻辑错误。如非法输入、找不到数据、溢出、超出资源限制等原因引起的事务执行失败。
|
|
|
|
（2）系统错误。系统进入一种不良状态（如死锁），导致事务无法继续执行。
|
|
|
|
对于不可以预期的错误应用程序无法处理，是由DBMS系统实现故障恢复的。如非法输入、运算溢出等。非预期的故障如非法输入是由约束机制检查并恢复的。事务故障通常指非预期的故障。
|
|
|
|
事务故障意味着事务没有达到预期的终点（COMMIT或者显示ROLLBACK），因此数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚该事务，即撤销该事务已经做出的任何对数据库的修改，这类恢复操作称为事务撤销（UNDO）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
数据库（DataBase，DB）是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
