搜索
第5章数据库的安全与保护数据库的安全与保护5.1安全与保护概述5.2数据库的安全性保护5.3数据库的完整性保护5.4数据库的并发控制技术5.5数据库的恢复技术5.6数据库的复制与相关技术5.5数据库的恢复技术什么是数据库的恢复故障的种类故障对数据库的破坏性恢复技术5.5数据库的恢复技术计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏等不可避免。轻者造成运行事务非正常中断，影响数据库中数据的正确性和一致性，重者使数据库中全部或部分数据丢失。数据库的恢复:把数据库从错误(不一致)状态恢复到某一已知的正确(一致)状态的过程。5.5数据库的恢复技术数据库恢复子系统：DBMS中的一个重要组成部分，且相当庞大，常常占整个系统代码的百分之十以上。各种现有数据库系统运行情况表明，数据库系统所采用的恢复技术是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大影响，是衡量系统性能优劣的重要指标。5.1.1故障的种类1)事务故障2)系统故障3)介质故障4)病毒破坏5)故障对数据库的破坏性1)事务故障事务在运行过程中由于某种原因，如输入错误、运算溢出、违反了某些完整性约束条件、某些应用程序出错、并行事务发生死锁等等，使事务尚未运行完成或提交就中断了，这种情况称为事务故障。2)系统故障系统在运行过程中，由于某种原因，如操作系统或DBMS代码错误、操作员操作失误、特定类型的硬件错误(如CPU故障)、突然停电等造成系统停止运行，致使所有正在运行的事务都以非正常的方式终止.问题：内存中数据库区的信息全部丢失，但存储在外部设备上的原有数据并未受到影响，但数据库可能处于不一致状态，这种情况称为系统故障。3)介质故障系统在运行过程中，由于某种原因，如磁盘损坏、瞬时强磁场干扰、操作系统的某种潜在错误，使存储在外存储器中的数据部分丢失或全部丢失。这种情况称为介质故障。这种故障比前两类故障发生的可能性要小的多，但所造成的破坏最大。4)病毒破坏计算机病毒是一种人为编制的、能引起计算机系统故障、甚至破坏整个计算机系统的程序。这种程序与其它程序不同之处是，它能象微生物学所称的病毒一样繁殖和传播，并造成对计算机系统包括数据库的危害。计算机病毒对数据库的破坏本质上是一种人为的破坏。5)故障对数据库的破坏性数据库系统中的各类故障对数据库的影响概括起来主要有两类：(1)数据库结构被破坏:一般病毒故障及介质故障引起，比较严重。(2)数据库结构没有被破坏,但数据库中数据的一致性遭到破坏，一般由系统故障及事务故障引起。5.5.2恢复技术数据恢复：利用存储在系统其它地方的冗余数据来修复数据库中被破坏的不正确或不一致的数据。恢复机制涉及两个关键问题：1）如何建立冗余数据？最常用方法：数据转储和日志文件。2）如何利用冗余数据实施数据库恢复？这是数据恢复策略和方法问题。5.5.2恢复技术1、数据转储(1)数据转储的定义(2)数据转储的分类(3)怎样确定适当的转储周期与转储方法(1)数据转储的定义数据转储：由DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来形成备用数据文件的过程。备用的数据文件也称为后备副本或后援副本。数据转储是数据库恢复中最常用的基本技术。当数据库遭到破坏后就可以利用后备副本把数据库恢复到某个一致性状态。(2)数据转储的分类静态转储和动态转储。——数据库状态海量转储与增量转储。——转储数据量静态转储和动态转储静态转储：转储期间不允许对数据库有任何操作(包括存取、修改等)活动。静态转储比较简单，但降低了数据库的可用性。因为转储要等到用户事务全部结束后才能进行，且新的事务必须等待转储结束后才能执行。动态转储：在转储期间允许对数据库进行存取等操作，即数据转储和用户事务可并发执行。动态转储可以克服静态转储的缺点，转储工作可随时进行，但实现技术要求较高。因为转储操作与用户事务并行执行，不容易保证转储结束时后备副本上数据的一致性。海量转储与增量转储海量转储：每次转储数据库的全部数据。增量转储：每次只转储数据库中上次转储以来所产生变化的那些数据，即数据库中的数据只转储其修改过的物理块。这样转储的数据量少，也不必花很多时间，但为减少事故发生时更新丢失，需经常转储。比较：海量转储数据量大，不易进行。增量转储数据量少，但要经常转储。怎样确定适当的转储周期与转储方法当数据库遭破坏时时，最简单的方法就是以后备副本来恢复数据库。要经常地进行数据转储，因为后备副本越接近故障发生点，恢复起来越方便、越省时。但数据转储十分耗费时间和资源的，不可能频繁进行。DBA应该根据数据库的使用情况确定适当的转储周期和转储方法。例如，每天晚上或每周进行动态增量转储，每月进行一次海量转储等。5.5.2恢复技术2、日志文件(1)日志文件的作用(2)日志文件的分类(3)日志文件的登记原则(1)日志文件的作用建立日志文件是数据库系统采取的另一种数据冗余措施。日志文件是记录每一次对数据库进行更新操作的文件，该文件由DBMS自动建立和记录。文件中包括的内容有：事务名称、操作的时间、操作类型、修改前数据值以及修改后数据值等等；还有事务的开始，提交(COMMIT)及回滚(ROLLBACK)等执行情况记录。(1)日志文件的作用在动态转储方式中必须建立日志文件，后备副本和日志文件综合起来才能有效地恢复数据库。在静态转储方式中也可以建立日志文件。当数据库毁坏后可重新装入后备副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件，把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤消处理。这样不必重新运行那些在转储前已完成的事务程序就可把数据库恢复到故障前某一时刻。利用静态转储副本和日志文件进行恢复静态转储运行事务正常运行─┼───────┼─────────────TaTbTf└────────────重装后备副本利用日志文件恢复继续运行恢复─┼───────┼┈┈┈┈┈┈┈┈┼────(2)日志文件的分类日志文件主要有两种格式：1)以记录为单位的日志文件2)以数据块为单位的日志文件1)以记录为单位的日志文件以记录为单位的日志文件，需要登记如下内容：各个事务的开始(BEGINTRANSATION)标记；各个事务的结束(COMMIT或ROLLBACK)标记；各个事务的所有更新操作；以上信息作为日志文件中的一个日志记录登记在日志文件中。日志记录一个日志记录的主要内容为：事务标识（标明是那一个事务）；操作的类型（插入、删除、修改）；操作对象；更新前数据的旧值（对插入操作，此项为空值）；更新后数据的新值（对删除操作，此项为空值）；2）以数据块为单位的日志文件以数据块为单位的日志文件，只要某个数据块中有数据被更新，就要将整个块更新前和更新后的内容放入日志文件中。（3）日志文件的登记原则日志文件登记时必须遵循两条原则：严格按照并行事务执行的时间次序登记；必须先写日志文件，后写数据库；下面将说明为什么必须这样。（3）日志文件的登记原则把对数据的修改写到数据库中和把登记这个修改的日志记录写到日志文件中是两个不同的操作。计算机有可能在这两个操作之间发生故障，即这两个操作只完成了一个。如果先写了数据库修改，而日志文件中没有登记下这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的REDO操作，并不会影响数据库的正确性。为了安全起见，一定要先写日志文件，即首先把操作记录写到日志文件中，然后才把操作结果写到数据库中。5.5.2恢复技术3、恢复策略利用数据库后备副本和日志文件可将数据库恢复到故障前的某个一致性状态，但不同的故障其恢复策略和恢复技术通常是不一样的。（1）事务故障的恢复（2）系统故障的恢复（3）介质故障的恢复（4）病毒故障的恢复（5）数据恢复的一般过程（1）事务故障的恢复发生事务故障时，夭折的事务可能已把对数据库的部分修改写回磁盘。恢复程序要在不影响其它事务运行的情况下，强行回滚该事务，即清除该事务对数据库的所有修改，使得这个事务像根本没有启动一样。这类恢复操作称为事务撤消(UNDO)。（1）事务故障的恢复1）反向扫描日志文件(从日志文件末尾开始扫描)，查找该事务的更新操作。2）对该事务的更新执行逆向操作，即将日志文件记录中“更新前的值”写入数据库。3）继续反向扫描日志文件，查找该事务的其它更新操作，并做同样处理。4）如此处理下去，直至读到此事务的开始标记，事务故障恢复就算完成了。事务故障的恢复是系统重新启动后由DBMS自动完成的，不需要用户干涉。（2）系统故障的恢复系统故障造成数据库不一致状态的原因未完成事务对数据库的更新已写入数据库已提交事务对数据库的更新还留在缓冲区没来得及写入数据库恢复方法1.Undo故障发生时未完成的事务2.Redo已完成的事务系统故障的恢复由系统在重新启动时自动完成，不需要用户干预（2）系统故障的恢复步骤1)正向扫描日志文件，找出在故障发生前已经提交的事务，并将这些事务标记记入重做队列。同时还要找出故障发生时尚未完成的事务(只有BEGINTRANSACTION记录，没有相应的COMMIT记录)，并将这些事务标记记入撤消队列。2)对撤消队列中的各个事务进行撤消(UNDO)处理：反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作。3)对重做队列中的各个事务进行重做(REDO)处理：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。（3）介质故障的恢复(1)重装数据库装入数据库发生介质故障前某个时刻的数据库后备副本(2)重做已完成的事务重新执行自此时开始的所有成功事务，将这些事务已提交的结果重新记入数据库。介质故障的恢复需要DBA介入但DBA只需要重新装入最近转储的数据库后备副本和有关的日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由DBMS自动完成。（3）介质故障的恢复步骤1）装入最新的数据库后备副本，使数据库恢复到最近一次转储时刻的一致性状态。对于静态转储的数据库副本，装入后数据库即处于一致性状态对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与系统故障恢复相同的方法(即REDO+UNDO)，将数据库恢复到一致性状态。2）装入转储结束时刻的日志文件副本，重做已经完成的事务。即扫描日志文件，找出故障发生时已提交的事务的标记，将其记入重做对列；然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。这样就可以将数据库恢复到故障前某一时刻的一致状态。（4）病毒故障的恢复计算机病毒对数据库可能造成的破坏，其破坏的结果不会超过事务故障、系统故障和介质故障的范畴。当数据库被计算机病毒破坏后，恢复方法除了重新启动之前要先杀毒以外，其它恢复步骤与前面介绍的三种方法之一相同。数据恢复的一般过程1）做数据拷贝工作：将数据库后备副本拷贝到数据库系统中。2）做事务恢复第1步：检查日志文件，确定哪些事务已执行结束，哪些尚未结束。3、做事务恢复第2步：对尚未结束的事务作撤消处理，对已执行结束的事务按日志的记录重做。经以上三步即可完成恢复工作，有些工作要由DBA负责参与完成。5.5.3检查点机制上节介绍事务故障和系统故障的恢复都必须搜索日志，确定需要REDO和UNDO的事务。而对于一个运行较长时间的数据库系统来说，势必需要检查所有日志记录，产生如下问题：（1）搜索整个日志将耗费大量的时间；（2）很多需要REDO的事务实际上早已将它们的更新操作结果写到数据库中，如果恢复子系统再重新执行这些操作会浪费大量时间。5.5.3检查点机制检查点机制：通过设置日志文件的检查点，来最大限度地减少数据库完全恢复时需要扫描日志文件的时间。检查点(checkpoint)：日志文件中一条特殊的日志记录(也称为检查点记录)，该记录由数据库恢复子系统定期地自动生成和维护。系统故障发生后实施数据库恢复时，将系统失败时刻之前的第一个检查点作为扫描日志文件的开始位置，就可避免扫描整个日志文件。5.5.3检查点机制检查点记录的内容包括：1)建立检查点时刻所有正在执行的事务清单