第7章 数据库维护,7.1 概述,数据库维护的定义 当数据库投入正式运行后，为保障数据库正常、平稳和高效地运行，针对数据库的安装、备份、恢复、压缩、故障排除等的工作就是数据库维护,7.1 概述,数据库维护的任务 日常维护 对数据库中的数据随时按需要进行增加、删除、插入、修改或更新等操作 定期维护 周期性地对数据库中的数据和日志文件进行备份、监测、组织和重构等操作 故障维护 当数据库遭到意外破坏时，把它恢复到破坏前的状态,7.1 概述,数据库维护的原则 DBA随时监控数据库系统（包括服务器等）各部分基本软件、硬件的正常运行。 DBA根据不同应用要求定期对数据库进行备份、重组织和重构。 当数据库出现故障时，尽快采取正确措施排除故障，必要时进行数据库恢复。 数据库的定期维护应尽量在运行事务数量最少的情况下进行。 数据库的维护应该根据其运行的状况来定，只做必要的维护。,7.1 概述,数据库维护的方法 随时监视系统运行状况，及时处理系统错误。 定期压缩数据库。 定期清理废旧无用的数据。 定期检查数据是否存在损坏，如发生损坏应及时修复。 定期进行数据备份。 定期备份日志文件。 当数据库发生故障或崩溃时，恢复数据库。 保证系统数据安全，周期更改用户口令。,数据库维护的步骤 重建索引。 更新统计。 删除不使用的文件、释放一些空间。 完全备份。 产生用户信息表，并为信息表授权。 随时监控系统运行状况 监控的主要对象有：用户数据库、数据库日志表（SYSLOGS）以及计费原始数据表等。如果发现占用空间过大，对日志表要进行备份，对其他目标则应扩充空间或清除垃圾数据。 保证系统数据安全，周期更改用户口令 为保证系统数据的安全，系统管理员必须依据系统的实际情况，执行一系列的安全保障措施。其中，周期性的更改用户口令是比较常用且十分有效的措施。 将上述步骤应用到所有系统和用户数据库。,7.1 概述,7.2 运行日志,日志文件的格式和内容 日志文件是记录每一次对数据库进行更新操作的文件，该文件由DBMS自动建立和记录。 文件中包括的内容有 事务名称 操作时间 操作类型 修改前数据值以及修改后数据值等 还有事务的开始(BEGIN)，提交(COMMIT)及回滚(ROLLBACK)等执行情况记录。,日志文件的格式和内容 不同数据库系统采用的日志文件格式并不完全一样 概括起来日志文件主要有两种格式 以记录为单位的日志文件 以数据块为单位的日志文件,7.2 运行日志,以记录为单位的日志文件，由多个日志记录构成，主要记载事务的开始(BEGIN TRANSACTION)标记、结束(COMMIT或ROLLBACK)标记和事务的所有更新操作。其中每一个日志记录(LOG RECORD)包括以下内容： 事务标识（标明是哪个事务）。 操作的类型（插入、删除或修改）。 操作对象(记录内部标识)。 更新前数据的旧值（对插入操作而言，此项为空值）。 更新后数据的新值（对删除操作而言, 此项为空值）。,7.2 运行日志,以数据块为单位的日志文件，只要某个数据块中有数据被更新，就要将整个块更新前和更新后的内容放入日志文件中。,7.2 运行日志,日志文件的使用 登记日志文件时必须遵循两条原则： 登记的次序严格按并发事务执行的时间次序。 必须先写日志文件，后写数据库。,7.2 运行日志,日志文件的维护 日志文件的维护工作主要包括周期地更新日志文件、定期备份日志文件、定期删除旧的日志文件。 周期地更新日志文件 日志文件可能很庞大，而且不可能无休止的被保存下来，所以需要周期性地用新的日志文件覆盖旧的日志文件。 定期备份日志文件 利用日志文件，恢复出现故障的数据库。 定期删除旧的日志文件 旧的日志文件保存到一段时间后应当予以清除，以节省磁盘空间。,7.2 运行日志,7.3 数据库故障及其排除,故障的种类 数据库主要会遇到4种故障 事务故障 系统故障 介质故障 计算机病毒。,事务故障 事务故障指事务的运行没有达到预期的终点就被终止，有两种错误可能造成事务执行失败。 非预期故障 非预期故障指不能由应用程序处理的故障，例如，运算溢出、与其他事务形成死锁而被选中撤销事务、违反了某些完整性约束等，但该事务可以在以后的某个时间重新执行。 可预期故障 可预期故障指应用程序可以发现事务的故障，并且应用程序可以控制让事务回滚。例如，输入错误等。 可预期故障由应用程序处理，非预期故障是不能由应用程序处理的,7.3 数据库故障及其排除,系统故障 系统故障常称为软故障(Soft Crash)，是指造成系统停止运转的任何事件，使得系统要重新启动。 例如，特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误、突然停电等。 这类故障影响正在运行的所有事务，但不破坏数据库。这时主存内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，从而造成数据库可能处于不一致性的状态。,7.3 数据库故障及其排除,介质故障 介质故障被称为硬故障(Hard Crash)，主要是指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。 这类故障将破坏部分甚至整个数据库，并影响正在存取数据的所有事务。 这类故障比前两类故障发生的可能性小得多，但破坏性最大,7.3 数据库故障及其排除,计算机病毒 计算机病毒是具有破坏性、可以自我复制的计算机程序。 计算机病毒可能引起的数据库故障属于系统故障或者是介质故障的范畴，因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。,7.3 数据库故障及其排除,故障的排除方法 数据库的故障排除方法包括以下几个关键步骤： 收集故障信息 当数据库发生故障时，通过检查日志文件和相关数 据获取故障信息。 确定故障原因和故障种类 故障原因和种类的确定是整个系统故障处理的关键，应该按照以下三个方面进行： 是硬件问题还是软件问题？ 数据库本身是否被破坏？ 单一问题？多方面问题？综合问题？ 故障处理方案 根据故障种类和原因确定故障处理的具体方式，例如，修改应用程序、修复或更换硬件设备，必要时进行数据库的恢复工作。,7.3 数据库故障及其排除,7.4 数据库备份与恢复,备份数据库就是将数据库中的数据和与数据库的正常运行有关的信息保存起来，以备恢复数据库时使用。,数据库备份的原则 在数据库系统处于空闲的时候做海量备份 备份时间的间隔设置可以根据系统本身的数据量和数据重要的程度来设置，比如一个月做一次海量备份。然后在数据库系统处于比较空闲的时候做增量备份，比如一周备份一次。 定期执行备份 设置一个备份时间表并严格执行，同时更新日志。 经常做日志备份 如果数据很重要，而且数据的变化频度又非常快，可以设置较短的时间备份一次，这个主要由数据重要的程度和允许丢失数据的时间长短来确定。 备份文件保存到多种介质和多个地点 对于重要的数据，要将备份文件保存到多种介质和多个地点。这样，某一处备份文件损坏了的话，还可以有其他的备份文件可用。,7.4 数据库备份与恢复,数据库备份的方式 数据库备份的方式按备份期间有无事务的运行可分为静态备份和动态备份: 静态备份是在系统中无运行事务时进行的备份操作。即备份开始的时刻，数据库处于一致性状态，而备份期间不允许（或不存在）对数据库的任何存取、修改活动。静态备份得到的是一个数据一致性的副本。 动态备份是指备份期间允许对数据库进行存取或修改，即备份和用户事务可以并发执行。 动态备份和静态备份各有优劣。静态备份能够保证副本上的数据的一致性。动态备份不用等待正在运行的用户事务结束，也不会影响新事务的运行。,7.4 数据库备份与恢复,数据库备份的方式 数据库备份的方式按所备份的内容则可分为海量备份和增量备份: 海量备份是将数据库中的全部信息进行备份，它是恢复的基线。在进行海量备份时，不但备份数据库的数据文件、日志文件，而且还备份文件的存储位置信息以及数据库中的全部对象。 增量备份是备份从最近的海量备份之后对数据所做的修改。它以海量备份为基准点，备份海量备份之后发生变化了的数据文件、日志文件以及数据库中其他被修改了的对象。增量备份也备份其过程中用户对数据库进行的操作。 从数据备份的角度看，增量备份比海量备份需要的时间短，备份的数据量小。从恢复角度看，使用海量备份得到的后备副本进行恢复一般来说会方便些。但如果数据库很大，事务处理又十分频繁，则增量备份方式更实用更有效。,7.4 数据库备份与恢复,数据库恢复策略 数据库恢复的任务是把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）。,7.4 数据库备份与恢复,数据库恢复的一般过程 为实现数据库中的数据恢复，必须将数据备份和日志文件相结合才能完成。一般情况下，当数据库遭到破坏后，可以先用后备副本，将数据库恢复到复制次副本时的一致状态，再利用日志文件将复制后至破坏时刻所更改的数据全部恢复，其一般过程是： 做数据复制工作，将数据库后备副本复制到数据库系统中。 做事务恢复第一步，检查日志文件，确定哪些事务已经执行结束，哪些尚未结束。 做事务恢复第二步，对尚未结束的事务按照日志记录的时间顺序执行撤销处理，对已经执行结束的事务按日志的记录先后次序重做。,7.4 数据库备份与恢复,不同种类故障恢复的步骤 事务故障的恢复 事务故障是指事务在运行至正常终止点前被中止，这时恢复数据库应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。数据库的恢复步骤是： 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空）。若记录中是删除操作，则做插入操作，若是修改操作，则相当于用修改前值代替修改后值。 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。,7.4 数据库备份与恢复,不同种类故障恢复的步骤 系统故障的恢复 系统故障造成数据库不一致状态的原因有两个： 一是未完成事务对数据库的更新可能已写入数据库， 二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。 因此恢复操作就是要撤消故障发生时未完成的事务，重做已完成的事务。系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预。为保证数据一致性，恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销（UNDO）所有未完成事务。重做（REDO）所有已提交的事务，以将数据库真正恢复到一致状态。,7.4 数据库备份与恢复,7.4 数据库备份与恢复,不同种类故障恢复的步骤 系统的恢复步骤是： 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录），将其事务标识记入撤消队列。 对撤销队列中的各个事务进行撤销(UNDO)处理。 进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。 对重做队列中的各个事务进行重做(REDO)处理。进行REDO处理的方法是：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”写入数据库。,不同种类故障恢复的步骤 介质故障的恢复 发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。具体地说就是： 装入最新的数据库后备副本（离故障发生时刻最近的备份副本），使数据库恢复到最近一次备份时的一致