|
|
|
在数据库的运行过程中，难免会出现计算机系统的软、硬件故障，这些故障会影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失。因此，数据库的关键技术在于建立冗余数据，即备份数据。如何在系统出现故障后及时使数据库恢复到故障前的正确状态，就是数据库恢复技术。
|
|
|
|
|
|
数据库系统中可能发生的故障有很多种，本小节只讨论事务故障、系统故障和介质故障。
|
|
|
|
|
|
事务故障（transaction failure）是由于程序执行错误而引起事务非预期的、异常终止的故障。通常有如下两类错误引起事务执行失败。
|
|
|
|
（1）逻辑错误。如非法输入、找不到数据、溢出、超出资源限制等原因引起的事务执行失败。
|
|
|
|
（2）系统错误。系统进入一种不良状态（如死锁），导致事务无法继续执行。
|
|
|
|
对于不可以预期的错误应用程序无法处理，是由DBMS系统实现故障恢复的。如非法输入、运算溢出等。非预期的故障如非法输入是由约束机制检查并恢复的。事务故障通常指非预期的故障。
|
|
|
|
事务故障意味着事务没有达到预期的终点（COMMIT或者显示ROLLBACK），因此数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚该事务，即撤销该事务已经做出的任何对数据库的修改，这类恢复操作称为事务撤销（UNDO）。
|
|
|
|
|
|
系统故障是指硬件故障、软件（如DBMS、OS或应用程序）漏洞的影响，导致丢失了内存中的信息，影响正在执行的事务，但未破坏存储在外存上的信息。这种情况称为故障-停止假设（fail-stop assumption）。
|
|
|
|
系统故障中止了事务的执行过程，破坏了事务的原子性，由于缓冲区中的内容可能部分已写入数据库，系统重启后数据库可能处于不一致状态。
|
|
|
|
|
|
介质故障是指数据库的存储介质发生故障，如磁盘损坏、瞬间强磁场干扰等。这种故障直接破坏了数据库，会影响到所有正在读取这部分数据的事务。
|
|
|
|
|
|
事实上，在当今信息社会，最珍贵的财产并不是计算机软件，更不是计算机硬件，而是企业在长期发展过程中所积累下来的业务数据。建立网络最根本的用途是要更加方便地传递与使用数据，但人为错误、硬盘损坏、电脑病毒、断电或是天灾人祸等等都有可能造成数据的丢失。所以应该强调指出：“数据是资产，备份最重要。”应当理解备份意识实际上就是数据的保护意识，在危机四伏的网络环境中，数据随时有被毁灭的可能。系统灾难的发生，不是是否会，而是迟早的问题。造成系统数据破坏、丢失的原因很多，有些还往往被人们忽视。正确分析威胁数据安全的因素，及时地备份数据，能使系统的安全防护更有针对性。
|
|
|
|
数据转储是将数据库自制到另一个磁盘或磁带上保存起来的过程，又称为数据备份。数据的备份分为静态转储和动态转储、海量转储和增量转储。
|
|
|
|
（1）静态转储和动态转储。静态转储是指在转储期间不允许对数据库进行任何存取、修改操作；动态转储是在转储期间允许对数据库进行存取、修改操作，因此，转储和用户事务可并发执行。数据转储可以由系统管理员（DBA）来操作，如静态转储，可以设定时间计划由DBMS定时执行，可以在事务程序中增加功能实现动态转储，也可以通过硬件系统的冗余磁盘阵列来实现。
|
|
|
|
（2）海量转储和增量转储。海量转储是指每次转储全部数据；增量转储是指每次只转储上次转储后更新过的数据。
|
|
|
|
（3）日志文件。在事务处理的过程中，DBMS把事务开始、事务结束以及对数据库的插入、删除和修改的每一次操作写入日志文件。每条记录包括的主要内容有执行操作的事务标识、操作类型、更新前数据的旧值（插入操作此项为空）、更新后的数据值（删除操作此项为空）、更新日期和更新时间。一旦发生故障，DBMS的恢复子系统利用日志文件撤销事务对数据库的改变，回退到事务的初始状态。因此，DBMS利用日志文件来进行事务故障恢复和系统故障恢复，并可协助后备副本进行介质故障恢复。
|
|
|
|
（4）数据库镜像。为了避免磁盘介质出现故障影响数据库的可用性，许多DBMS提供数据库镜像功能用于数据库恢复。需要说明的是，数据库镜像是通过复制数据实现的，但频繁地复制数据会降低系统的运行效果。因此实际应用中往往对关键的数据和日志文件镜像。
|
|
|
|
|
|
要使数据库在发生故障后能够恢复，必须建立冗余数据，在故障发生后利用这些冗余数据实施数据库恢复。建立冗余数据常用的技术是数据转储和建立日志文件。在一个数据库系统中，这两种方法一般是同时被采用的。
|
|
|
|
|
|
有了数据转储和日志文件，就可以在系统发生故障时进行恢复。故障恢复有撤销事务（UNDO）和重做事务（REDO）两个操作。
|
|
|
|
|
|
所谓撤销事务是将未完成的事务撤销，使数据库恢复到事务执行前的正确状态。
|
|
|
|
撤销事务的过程：反向扫描未完成的事务日志（由后向前扫描），查找事务的更新操作；对该事务的更新操作执行逆操作，用日志文件记录中更新前的值写入数据库，插入的记录从数据库中删除，删除的记录重新插入数据库中；继续反向扫描日志文件，查找该事务的其他更新操作并执行逆操作直至事务开始标志。
|
|
|
|
|
|
所谓重做事务（REDO）是将已经提交的事务重新执行。
|
|
|
|
重做事务的过程：从事务的开始标识起，正向扫描日志文件，重新执行日志文件登记的该事务对数据库的所有操作，直至事务结束标识。
|
|
|
|
|
|
|
|
|
|
事务故障是事务在运行至正常终止点（SUMMIT或ROLLBACK）前终止，日志文件只有该事务的开始标识而没有结束标识。对这类故障的恢复是通过撤销（UNDO）产生故障的事务，使数据库恢复到该事务执行前的正确状态来完成的。事务恢复有如下三个步骤：
|
|
|
|
步骤1：反向扫描日志文件（即从最后向前扫描日志文件），查找该事务的更新操作。
|
|
|
|
|
|
步骤3：继续反向扫描日志文件，查找该事务的其他更新操作，并做同样的处理，直到事务的开始标志。
|
|
|
|
注意：事务故障的恢复由系统自动完成，对用户是透明的。
|
|
|
|
|
|
系统故障会使数据库的数据不一致，原因有两个：一是未完成的事务对数据库的更新可能已写入数据库；二是已提交的事务对数据库的更新可能还在缓冲区中没来得及写入数据库。因此恢复操作就是要撤销故障发生时未完成的事务，重做（REDO）已提交的事务。
|
|
|
|
|
|
|
|
介质故障时数据库遭到破坏，需要重装数据库，装载故障前最近一次的备份和故障前的日志文件副本，再按照系统故障的恢复过程执行撤销和重做来恢复。
|
|
|
|
注意：介质故障要有系统管理员（DBA）的参与，装入数据库的副本和日记文件的副本，再由系统执行撤销和重做操作。
|
|
|
