资源预览内容
第1页 / 共45页
第2页 / 共45页
第3页 / 共45页
第4页 / 共45页
第5页 / 共45页
第6页 / 共45页
第7页 / 共45页
第8页 / 共45页
第9页 / 共45页
第10页 / 共45页
亲,该文档总共45页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
第11章 数据库恢复技术与SQL Server的数据恢复机制 11.1 故障的种类 11.2 数据恢复的实现技术 11.3 数据库恢复策略 11.4 SQL Server的数据备份和数据恢复机制 Date第11章 数据库恢复技术与SQL Server的数据恢复机制 11.1故障的种类数据库系统中发生的故障是多种多样的,大致可以归结为以 下几类: v 事务内部故障事务内部故障有的可以通过事务程序本身发现,但是更多的 则是非预期的,它们不能由事务处理程序处理。例如运算溢出、 并发事务发生死锁而被选中撤消该事务、违反了某些完整性限制 等。事务故障意味着事务没有达到预期的终点(COMMIT或显式的 ROLLBACK),因此数据库可能处于不正确状态。恢复程序的任务就 是在不影响其他事务运行的情况下,强行回滚 (ROLLBACK)该事务 ,即撤消该事务已经作出的任何对数据库的修改,使得该事务好 像根本没有启动一样。这类恢复操作称为事务撤消(UNDO)。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 系统故障系统故障是指造成系统停止运转,必须重新启动系统的任何 事件。例如,特定类型的硬件故障、操作系统故障、DBMS代码 错误、数据库服务器出错以及其他自然原因等。系统故障主要有两种情况: 发生故障时,一些尚未完成的事务的部分结果已送入物理数 据库,从而造成数据库可能处于不正确的状态。为保证数据一致性,需要清除这些事务对数据库的所有修改。 在这种情况下,恢复子系统必须在系统重新启动时让所有非正常终 止的事务回滚,强行撤消(UNDO)所有未完成的事务。 发生系统故障时,有些已完成的事务有一部分甚至全部留在 缓冲区,尚未写回到磁盘上的物理数据库中。系统故障使得这些事务对数据库的修改部分或全部丢失,这也 会使数据库处于不一致状态,因此应将这些事务已提交的结果重新 写人数据库。这种情况下,系统重新启动后,恢复子系统除了需要 撤消所有未完成的事务外,还需要重做(REDO)所有已提交的事务, 以使数据库真正恢复到一致状态。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 介质故障介质故障指外存故障,例如磁盘损坏、磁头碰撞、瞬时磁场干 扰等。这类故障会破坏数据库或部分数据,并影响正在存取这部分 数据的所有事务。介质故障虽然发生的可能性较小,但是它的破坏 性却是最大的,有时会造成数据的无法恢复。 v 计算机病毒计算机病毒是一种人为的故障或破坏,它是由一些人恶意的编 制的计算机程序。这种程序与其他程序不同,它可以像微生物学所 称的病毒一样进行繁殖和传播,并造成对计算机系统包括数据库系 统的破坏。 v 用户操作错误在某些情况下,由于用户有意或无意的操作也可能删除数据库 中的有用的数据或加入错误的数据,这同样会造成一些潜在的故障 。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 11.2 数据恢复的实现技术数据恢复涉及两个关键问题:建立备份数据、利用这些备份 数据实施数据库恢复。数据恢复最常用的技术是建立数据转储和 利用日志文件。 11.2.1 数据转储数据转储是数据库恢复中采用的基本技术。数据转储就是数 据库管理员(DBA)定期地将整个数据库复制到其他存储介质(如 磁带或非数据库所在的另外磁盘)上保存形成备用文件的过程。 这些备用的数据文件称为后备副本或后援副本。当数据库遭到破 坏后可以将后备副本重新装入,并重新执行自转储以后的所有更 新事务。数据转储是十分耗费时间和资源的,不能频繁进行。数据库 管理员(DBA)应该根据数据库使用情况确定一个适当的转储周期 和转储策略。数据转储有以下几类。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 静态转储和动态转储 静态转储 静态转储是指在转储过程中,系统不运行其他事务,专门 进行数据转储工作。 动态转储 动态转储是指在转储过程中,允许其他事务对数据库进行 存取或修改操作的转储方式。由于动态转储是动态地进行的,这样后备副本中存储的就可 能是过时的数据。因此,有必要把转储期间各事务对数据库的修 改活动登记下来,建立日志文件(Log File),使得后援副本加上 日志文件能够把数据库恢复到某一时刻的正确状态。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 海量转储和增量转储 海量转储 海量转储是指每次转储全部数据库。海量转储能够得到后备 副本,利用后备副本能够比较方便地进行数据恢复工作。但对 于数据量大和更新频率高的数据库,不适合频繁地进行海量转 储。 增量转储增量转储是指每次只转储上一次转储后更新过的数据。增量 转储适用于数据库较大、但是事务处理又十分频繁的数据库系 统。由于数据转储可在动态和静态两种状态下进行,因此数据转储方 法可以分为4类:动态海量转储、动态增量转储、静态海量转储和静 态增量转储。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 11.2.2 登记日志文件v 日志文件的格式和内容日志文件是用来记录对数据库的更新操作的文件。不同的数据 库系统采用的日志文件格式不完全相同。日志文件主要有以记录 为单位的日志文件和以数据块为单位的日志文件。以记录为单位的日志文件中需要登记的内容包括:每个事务的 开始(BEGIN TRANSACTION)标记、结束(COMMIT或ROLLBACK)标记和 所有更新操作,这些内容均作为日志文件中的一个日志记录(Log Record)。对于更新操作的日志记录,其内容主要包括:事务标识 (表明是哪个事务)、操作的类型(插入、删除或修改)、操作对象( 记录内部标识)、更新前数据的旧值(插入操作,该项为空)及更新 后数据的新值(删除操作,该项为空)。以数据块为单位的日志文件内容包括事务标识和更新的数据块 。由于更新前后的各数据块都放入了日志文件,所以操作的类型 和操作对象等信息就不必放入日志记录。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 日志文件的作用日志文件能够用来进行事务故障恢复、系统故障恢复,并能够 协助后备副本进行介质故障恢复。当数据库文件毁坏后,可重新 装入后援副本把数据库恢复到转储结束时刻的正确状态,再利用 建立的日志文件,可以把已完成的事务进行重做处理,而对于故 障发生时尚未完成的事务则进行撤消处理,这样不用运行应用程 序就可把数据库恢复到故障前某一时刻的正确状态。v 登记日志文件(Logging)为保证数据库的可恢复性,登记日志文件时必须遵循两条原则 :一是登记的次序严格按事务执行的时间次序;二是必须先写日 志文件,后写数据库。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 11.3 数据库恢复策略 当系统运行过程中发生故障时,利用数据库后备副本和日志文件就可 以将数据库恢复到故障前的某个一致性状态。不同故障其恢复策略和方 法也不一样。 v 事务故障的恢复当发生事务故障时,恢复子系统应利用日志文件撤消(UNDO)此事务已 对数据库进行的修改。事务故障的恢复通常是由系统自动完成的,用户 并不知道系统是如何进行事务恢复的。系统的恢复步骤是:(1)反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新 操作。(2)对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写 人数据库。如果记录中是插入操作,则相当于做删除操作;若记录中是 删除操作,则做插入操作;若是修改操作,则相当于用修改前的值代替 修改后的值。 (3)重复执行(1)和(2),恢复该事务的其他更新操作,直至读到该事务的 开始标记,事务故障恢复就完成了。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 系统故障的恢复系统故障恢复操作要撤消故障发生时未完成的事务,重做已完 成的事务。系统故障的恢复是由系统在重新启动时自动完成的, 不需要用户干预。系统的恢复步骤是:(1)正向扫描日志文件(即从头扫描日志文件),找出在故障发生前已经提 交的事务(这些事务既有BEGIN TRANSACTION记录,也有COMMIT或 ROLLBACK记录),将其事务标记记入重做(REDO)队列。同时找出故障发生 时尚未完成的事务(这些事务只有BEGIN TRANSACTION记录,无相应的 COMMIT或ROLLBACK记录),将其事务标记记入撤消(UNDO)队列。(2)对撤消队列中的各个事务进行撤消(UNDO)处理。进行撤消处理的方法是:反向扫描日志文件,对每个事务的更新操作执行 逆操作,即将日志记录中“更新前的值”写入数据库。(3)对重做队列中的各个事务进行重做(REDO)处理。进行重做处理的方法是:正向扫描日志文件,对每个重做事务重新执行日 志文件登记的操作。即将日志记录中“更新后的值”写入数据库。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 介质故障的恢复介质故障会破坏磁盘上的物理数据库和日志文件,这是最严 重的一种故障。恢复方法是重装数据库后备副本,然后重做已 完成的事务。具体恢复步骤是:(1)装入最新的数据库后备副本,使数据库恢复到最近一次转储 时的一致性状态。对于动态转储的数据库副本,还需要同时装 入转储开始时刻的日志文件副本。利用恢复系统故障的方法(即 重做+撤消的方法),才能将数据库恢复到一致性状态。(2)装入相应的日志文件副本(转储结束时刻的日志文件副本), 重做已完成的事务。利用日志技术进行数据库恢复时,恢复子系统必须搜索所有 的日志,确定哪些事务需要重做。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 11.4 SQL Server的数据备份和数据恢复机制 v 完全备份 完全备份就是通过海量转储形成的备份。其最大优点是恢复 数据库的操作简便,它只需要将最近一次的备份恢复。完全备份 所占的存储空间很大且备份的时间较长,只能在一个较长的时间 间隔上进行完全备份。其缺点是当根据最近的完全备份进行数据 恢复时,完全备份之后对数据所作的任何修改都将无法恢复。当 数据库较小、数据不是很重要或数据操作频率较低时,可采用完 全备份的策略进行数据备份和恢复。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 完全备份加事务日志备份事务日志备份必须与数据库的完全备份联合使用,才能实现 数据备份和恢复功能。将完全备份和事务日志备份联用进行数 据备份和恢复时,备份步骤是:(1)定期进行完全备份,例如一天一次或两天一次。(2)更频繁地进行事务日志备份,如一小时一次或两小时一次等 。当需要数据库恢复时,首先用最近一次完全备份恢复数据库 ,然后用最近一次完全备份之后创建的所有事务日志备份,按 顺序恢复完全备份之后发生在数据库上的所有操作。完全备份和事务日志备份相结合的方法,能够完成许多数据 库的恢复工作。但它对那些不在事务日志中留下记录的操作, 仍无法恢复数据。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 v 同时使用3种备份 在同时使用数据库完全备份和事务日志备份的基础上,再以增 量备份(即增量转储)作为补充,可以在发生数据丢失时将损失 减到最小。同时使用3种备份恢复数据时,要求数据备份操作按以下顺序进行 :(1)定期执行完全备份,例如一天一次或两天一次等。(2)进行增量备份,如4小时一次或六小时一次等。(3)进行事务日志备份,如一小时一次或两小时一次等。在发生数据丢失或操作失败时,按下列顺序恢复数据库:(1)用最近一次的完全备份恢复数据库;(2)用最近一次的增量备份恢复数据库;(3)用在最近一次的完全备份之后创建的所有事务日志备份,按顺 序恢复最近一次完全备份之后发生在数据库上的所有操作。Date第11章 数据库恢复技术与SQL Server的数据恢复机制 11.4.1 数据库的备份数据库的备份和恢复工作不仅对用户数据库是重要的
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号