第六章 数据库恢复技术
- 格式:doc
- 大小:88.00 KB
- 文档页数:17
数据库恢复技术及其实现方法数据库恢复技术是数据库管理系统中的核心功能之一,它负责将数据库从故障或者错误中恢复并使其重新可用。
在现代社会中,数据库的重要性不言而喻,因此数据库恢复技术的研究和实践显得尤为重要。
本文将介绍数据库恢复技术的一些常见方法及其实现方式,以期对读者有所帮助。
一、日志恢复技术日志恢复技术是一种常见的数据库恢复方法,它通过事务日志(transaction log)记录以及回滚操作,实现数据库的恢复。
在数据库系统中,事务日志记录了每个事务所执行的操作,包括数据的插入、修改和删除等。
通过事务日志,可以回溯到数据库发生错误前的状态,从而进行恢复。
实现方式:1. 重做(Redo)恢复:该方法是通过重新执行已经提交的事务日志来进行恢复。
当数据库发生故障时,系统会检查事务日志中未提交的事务并将其重新执行,以保证数据库的一致性和完整性。
2. 撤销(Undo)恢复:与重做恢复相反,撤销恢复是对未提交的事务进行回滚操作,将其撤回到故障发生前的状态。
通过撤销恢复,数据库可以回滚到一个更稳定的状态。
二、快照(Snapshot)恢复技术快照恢复技术是另一种常见的数据库恢复方法,它通过保存数据库的快照(即某个时间点的数据库状态)来实现恢复。
当数据库发生故障时,可以将数据库恢复到之前某个时间点的快照状态,从而达到修复的目的。
实现方式:1. 冷备份(Cold Backup):该方法是在数据库关闭的情况下进行备份,通过将数据库文件复制到其他位置来保存数据库的快照。
当数据库发生故障时,可以使用备份文件来还原数据库。
2. 热备份(Hot Backup):与冷备份不同,热备份是在数据库运行期间进行备份,而不需要关闭数据库。
通过使用特殊的备份工具,可以在数据库运行的同时备份数据库文件,并保持数据库的一致性。
三、镜像(Mirroring)恢复技术镜像恢复技术是一种高可用性的数据库恢复方法,它通过实时复制数据库到备份服务器中,以实现快速恢复。
数据库恢复技术---恢复内容开始---数据库恢复技术事务:是⽤户定义的⼀个数据库操作序列,这些操作要么全做,要么全不做,是⼀个不可分割的⼯作单位。
事物的 ACID 特性:原⼦性、⼀致性、隔离性、持续性。
恢复的实现技术:建⽴冗余数据 -> 利⽤冗余数据实施数据库恢复。
建⽴冗余数据常⽤技术:数据转储(动态海量转储、动态增量转储、静态海量转储、静态增量转储)、登记⽇志⽂件。
ACID特性1. 原⼦性(Atomicity)⼀个原⼦事务要么完整执⾏,要么⼲脆不执⾏。
这意味着,⼯作单元中的每项任务都必须正确执⾏。
如果有任⼀任务执⾏失败,则整个⼯作单元或事务就会被终⽌。
即此前对数据所作的任何修改都将被撤销。
如果所有任务都被成功执⾏,事务就会被提交,即对数据所作的修改将会是永久性的。
2. ⼀致性(Consistency)⼀致性代表了底层数据存储的完整性。
它必须由事务系统和应⽤开发⼈员共同来保证。
事务系统通过保证事务的原⼦性,隔离性和持久性来满⾜这⼀要求; 应⽤开发⼈员则需要保证数据库有适当的约束(主键,引⽤完整性等),并且⼯作单元中所实现的业务逻辑不会导致数据的不⼀致(即,数据预期所表达的现实业务情况不相⼀致)。
例如,在⼀次转账过程中,从某⼀账户中扣除的⾦额必须与另⼀账户中存⼊的⾦额相等。
3. 隔离性(Isolation)隔离性意味着事务必须在不⼲扰其他进程或事务的前提下独⽴执⾏。
换⾔之,在事务或⼯作单元执⾏完毕之前,其所访问的数据不能受系统其他部分的影响。
当我们编写了⼀条 update 语句,提交到数据库的⼀刹那间,有可能别⼈也提交了⼀条 delete 语句到数据库中。
也许我们都是对同⼀条记录进⾏操作,可以想象,如果不稍加控制,就会出⼤⿇烦来。
我们必须保证数据库操作之间是“隔离”的(线程之间有时也要做到隔离),彼此之间没有任何⼲扰。
4. 持久性(Durability)持久性表⽰在某个事务的执⾏过程中,对数据所作的所有改动都必须在事务成功结束前保存⾄某种物理存储设备。
数据库恢复的基本技术数据库恢复是指在数据库发生故障或损坏后,通过一系列的技术手段将数据库恢复到正常运行状态的过程。
数据库恢复技术主要包括备份和恢复、事务日志恢复以及物理和逻辑恢复等。
本文将分别介绍这些基本的数据库恢复技术。
1.备份和恢复技术备份和恢复是数据库恢复的最基本方法。
备份指将数据库的原始数据或者副本复制到其他存储介质中,以防止原始数据丢失或损坏。
常见的备份方式包括完全备份和增量备份。
完全备份是将整个数据库完全复制到备份介质,而增量备份则是只备份自上次备份以来发生变化的数据。
当数据库发生故障时,可以通过还原备份数据来恢复数据库。
2.事务日志恢复技术事务日志是数据库中记录每一次事务操作的日志,包括事务开始、事务结束和对数据库进行的修改操作。
事务日志恢复技术是通过分析事务日志记录来实现数据库的恢复。
当数据库发生故障时,可以通过重放事务日志中的操作来恢复数据库到故障发生前的状态。
事务日志恢复主要包括正向恢复和反向恢复两种方式。
正向恢复是从备份数据开始,按照日志记录的顺序逐步重放操作,直到故障点之后的操作。
反向恢复则是从故障点开始,按照日志记录的顺序逐步撤销操作,直到备份数据的状态。
3.物理恢复技术物理恢复是指将数据库的物理文件从损坏或错误状态恢复到正常状态的过程。
常见的物理恢复技术包括点备份和增量备份恢复、崩溃恢复以及校验和恢复等。
点备份和增量备份恢复是通过使用备份数据和增量备份数据来恢复数据库。
崩溃恢复是指在数据库崩溃、主机断电等突发情况下,通过恢复到最后一次一致状态来保护数据的完整性。
校验和恢复是通过校验和验证来检测和纠正物理文件的错误,以保证数据的一致性和完整性。
4.逻辑恢复技术逻辑恢复是指通过使用数据库的逻辑结构和操作来恢复数据库。
常见的逻辑恢复技术包括数据导入和导出、数据转换以及数据修复等。
数据导入和导出是将数据库中的数据导出为文本文件或其他格式,然后再将导出的数据导入到数据库中。
数据转换是指将数据库中的数据转换为其他数据库或应用程序所需的格式。
数据库恢复技术随着信息技术的不断发展,数据库已经成为了现代企业管理的重要工具。
然而,在日常使用过程中,数据库可能会遭受各种各样的损坏,导致数据丢失或者无法访问。
为了保障数据的安全,数据库恢复技术变得越来越重要。
本文将介绍数据库恢复技术的基本概念、常见故障类型和恢复方法,希望能够为读者提供帮助。
一、基本概念1.1 数据库恢复数据库恢复是指在数据库发生故障或者出现数据丢失的情况下,通过一系列的操作和技术手段,将数据库恢复到之前的状态或者尽可能地恢复数据。
数据库恢复是保障数据安全的重要手段,也是数据库管理人员必须掌握的技能之一。
1.2 数据库故障数据库故障是指数据库的硬件或者软件出现了问题,导致数据库无法正常工作或者数据丢失。
常见的数据库故障包括硬件故障、软件故障、人为错误等。
1.3 数据库备份数据库备份是指将数据库的数据和日志文件复制到另一个存储介质中,以便在数据库损坏或者数据丢失的情况下进行数据恢复。
数据库备份是数据库恢复的重要前提,也是保障数据安全的有效手段。
二、常见故障类型2.1 硬件故障硬件故障是指数据库服务器的硬件设备出现了问题,导致数据库无法正常工作。
常见的硬件故障包括硬盘故障、电源故障、内存故障等。
硬件故障可能导致数据丢失或者无法访问,需要通过数据库恢复技术进行修复。
2.2 软件故障软件故障是指数据库管理系统出现了问题,导致数据库无法正常工作。
常见的软件故障包括操作系统崩溃、数据库软件崩溃、网络故障等。
软件故障可能导致数据丢失或者无法访问,需要通过数据库恢复技术进行修复。
2.3 人为错误人为错误是指数据库管理人员或者用户在使用数据库的过程中出现了错误,导致数据丢失或者无法访问。
常见的人为错误包括误删除数据、误修改数据等。
人为错误可能导致数据丢失或者无法访问,需要通过数据库恢复技术进行修复。
三、恢复方法3.1 数据库备份恢复数据库备份恢复是指通过已经备份的数据库数据和日志文件,将数据库恢复到之前的状态。
一、数据库恢复理论知识1、数据库恢复:DBMS必须具有把数据库从错误状态恢复到某一已知的正确状态的功能。
2、数据库恢复机制包括“一个数据库恢复子系统”和“一套特定的数据结构”。
而其基本原理是重复存储数据,即“数据冗余(data redundancy)”3、恢复机制涉及两个关键的问题①如何建立冗余数据。
②如何利用这些冗余数据实施数据库恢复。
4、建立冗余数据最常用(也是最基本)的技术就是:数据转储和登陆日志文件。
(一般两种技术一起使用)5、基本概念①数据转储:DBA(Database Administrator)定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。
这些备用的数据文本称为后备副本或后援副本举例子:假定有三个瞬时时间t1<t2<t3。
其中t1时刻DBMS停止事务的运行而开始进行数据的转储,在到达时间t2的时候转储完毕,当到达t3的时候数据库发生故障,因此为了恢复到数据库发生故障的前一刻t(即t2<t<t3),DBA就要重装数据库后备副本,将数据库恢复到t2时刻的状态,然后重新运行自t2时刻到t3时刻的所有更新事务,这样子就可以完成数据库的恢复。
值得注意的是:转储是十分消耗时间和资源的,所以一般不会频繁运行,一般转储周期(为几小时、几天、也可以是几个月)还得选择适合你当前数据库的那个时间。
从上面中的介绍可以看出:转储需要在停止了所有事务时才可以进行,这种情况我们称之为“静态转储”,为了克服这种转储,数据库另有一种方式为“动态转储”,即转储和用户事务可以并发执行,而且能够恢复到用户事务更新到故障的前一刻。
转储的时候会涉及数据的多少问题:因此会有“海量转储”和“增量转储”两种方式。
海量:即每一次转储全部的数据,而增量:每一次只转储上一次转储后的更新过的数据。
用一张表来简单描述为:②登录日志文件(可以协助或备副本进行介质故障恢复)基本概念:日志文件:是用来记录事务对数据库的更新操作的文件。
第六章数据库恢复技术第六章数据库恢复技术6.1 事务的基本概念6.2 数据库恢复概述6.3 故障的种类6.4 恢复的实现技术6.5 恢复策略6.6 具有检查点的恢复技术6.7 数据库镜像6.8 小结6.1 事务的基本概念一、什么是事务二、如何定义事务三、事务的特性一、什么是事务•事务(Transaction)是数据库的逻辑工作单位,是用户定义的一组操作序列。
•事务和程序是两个概念–在关系数据库中,一个事务可以是一条SQL语句,一组SQL语句或整个程序–一个应用程序通常包含多个事务•事务是恢复和并发控制的基本单位二、如何定义事务•显式定义方式BEGIN TRANSACTION BEGIN TRANSACTIONSQL 语句1 SQL 语句1SQL 语句2 SQL 语句2。
COMMIT ROLLBACK•隐式方式当用户没有显式地定义事务时,DBMS 按缺省规定自动划分事务事务结束COMMIT事务正常结束提交事务的所有操作(读+更新)事务中所有对数据库的更新永久生效ROLLBACK事务异常终止–事务运行的过程中发生了故障,不能继续执行回滚事务的所有更新操作–事务滚回到开始时的状态三、事务的特性(ACID特性) 事务的ACID特性:•原子性(Atomicity)•一致性(Consistency)•隔离性(Isolation)•持续性(Durability )1. 原子性•事务是数据库的逻辑工作单位–事务中包括的诸操作要么都做,要么都不做2. 一致性事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
一致性与原子性银行转帐:从帐号A中取出一万元,存入帐号B。
–定义一个事务,该事务包括两个操作–这两个操作要么全做,要么全不做•全做或者全不做,数据库都处于一致性状态。
•如果只做一个操作,数据库就处于不一致性状态。
3. 隔离性对并发执行而言一个事务的执行不能被其他事务干扰•一个事务内部的操作及使用的数据对其他并发事务是隔离的•并发执行的各个事务之间不能互相干扰T1的修改被T2覆盖了!4. 持续性•持续性也称永久性(Permanence)–一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。
–接下来的其他操作或故障不应该对其执行结果有任何影响。
事务的特性•保证事务ACID特性是事务处理的任务•破坏事务ACID特性的因素–多个事务并行运行时,不同事务的操作交叉执行–事务在运行过程中被强行停止第六章数据库恢复技术6.1 事务的基本概念6.2 数据库恢复概述6.3 故障的种类6.4 恢复的实现技术6.5 恢复策略6.6 具有检查点的恢复技术6.7 数据库镜像6.8 小结6.2 数据库恢复概述故障是不可避免的–计算机硬件故障–系统软件和应用软件的错误–操作员的失误–恶意的破坏等因素均可能使数据库中的数据受到破坏数据库恢复概述(续)•数据库管理系统对故障的对策DBMS提供恢复子系统。
保证故障发生后,能把数据库中的数据从错误状态恢复到某种逻辑一致的状态,从而保证事务ACID特性。
•恢复技术是衡量系统优劣的重要指标第六章数据库恢复技术6.1 事务的基本概念6.2 数据库恢复概述6.3 故障的种类6.4 恢复的实现技术6.5 恢复策略6.6 具有检查点的恢复技术6.7 数据库镜像6.8 小结6.3 故障的种类•事务故障•系统故障•介质故障一、事务故障•什么是事务故障事务在运行过程中由于种种原因未运行至正常终止点就夭折了。
•事务故障的常见原因–输入数据有误–运算溢出–违反了某些完整性限制–某些应用程序出错–并行事务发生死锁–。
事务故障的恢复•发生事务故障时,夭折的事务可能已把对数据库的部分修改写回磁盘•通常用调用ROLLBACK 来回滚该事务,使得这个事务象根本没有启动过一样,通常把这类恢复操作称为撤消事务(UNDO)二、系统故障什么是系统故障系统在运行过程中,由于某种原因使系统停止运行,致使所有正在运行的事务以非正常方式终止。
系统故障的常见原因•操作系统或DBMS 代码错误•操作员操作失误•特定类型的硬件错误(如CPU 故障)•突然停电补充知识点补充知识点系统故障的恢复三、介质故障•硬件故障使存储在外存中的数据部分丢失或全部丢失•介质故障比前两类故障的可能性小得多,但破坏性大得多介质故障的常见原因•硬件故障–磁盘损坏–磁头碰撞–操作系统的某种潜在错误–瞬时强磁场干扰介质故障的恢复•装入数据库发生介质故障前某个时刻的数据副本•重做自此时始的所有成功事务,将这些事务已提交的结果重新记入数据库恢复操作的基本原理•恢复操作的基本原理:建立冗余数据–利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据•恢复的实现技术:复杂–一个大型数据库产品,恢复子系统的代码要占全部代码的10% 以上第六章数据库恢复技术6.1 事务的基本概念6.2 数据库恢复概述6.3 故障的种类6.4 恢复的实现技术6.5 恢复策略6.6 具有检查点的恢复技术6.7 数据库镜像6.8 小结6.4 恢复的实现技术恢复机制涉及的关键问题1. 如何建立冗余数据•数据转储(backup)•登录日志文件(logging)2. 如何利用这些冗余数据实施数据库恢复6.4 恢复的实现技术6.4.1 数据转储6.4.2 登记日志文件6.4.1 数据转储一、什么是转储二、转储的用途三、转储方法一、什么是转储•转储是指DBA将整个数据库复制到另一个磁盘上保存起来的过程。
•这些备用的数据文本称为后备副本或后援副本。
二、转储的用途三、转储方法1.静态转储与动态转储2.海量转储与增量转储3.转储方法小结1.静态转储•在系统中无运行事务时进行转储•转储开始时数据库处于一致性状态,转储期间不允许对数据库的任何存取、修改活动•优点:实现简单•缺点:降低了数据库的可用性–转储必须等用户事务结束–新的事务必须等转储结束动态转储•转储操作与用户事务并发进行•转储期间允许对数据库进行存取或修改•优点–不用等待正在运行的用户事务结束–不会影响新事务的运行•动态转储的缺点–不能保证副本中的数据正确有效动态转储•利用动态转储得到的副本进行故障恢复–需要把动态转储期间各事务对数据库的修改活动登记下来,建立日志文件–后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态2.海量转储与增量转储•海量转储: 每次转储全部数据库•增量转储: 只转储上次转储后更新过的数据•海量转储与增量转储比较–从恢复角度看,使用海量转储得到的后备副本进行恢复往往更方便–但如果数据库很大,事务处理又十分频繁,则增量转储方式更实用更有效3.转储方法小结•转储方法分类转储策略•应定期进行数据转储,制作后备副本。
•但转储又是十分耗费时间和资源的,不能频繁进行。
•DBA应该根据数据库使用情况确定适当的转储周期和转储方法。
例:–每天晚上进行动态增量转储–每周进行一次动态海量转储–每月进行一次静态海量转储6.4.2 登记日志文件一、日志文件的内容二、日志文件的用途三、登记日志文件的原则一、日志文件的内容1. 什么是日志文件日志文件(log)是用来记录事务对数据库的更新操作的文件2. 日志文件的格式以记录为单位的日志文件以数据块为单位的日志文件一、日志文件的内容(续)3. 在登录日志时,对每一个事务会产生3个日志记录。
–事务的开始(BEGIN TRANSACTION)–事务的所有更新操作–事务的结束(COMMIT 或ROLLBACK)一、日志文件的内容(续)4.每个日志记录的内容–事务标识–操作类型(插入、删除或修改)–操作对象(记录ID、Block NO.)–更新前数据的旧值(对插入操作而言,此项为空值)–更新后数据的新值(对删除操作而言, 此项为空值)–用户名–。
二、日志文件的用途1.用途–进行事务故障恢复–进行系统故障恢复–协助后备副本进行介质故障恢复三、登记日志文件的原则•为保证数据库是可恢复的,登记日志文件时必须遵循两条原则–登记的次序严格按并行事务执行的时间次序–必须先写日志文件,后写数据库登记日志文件的原则(续)•为什么要先写日志文件–写数据库和写日志文件是两个不同的操作–在这两个操作之间可能发生故障–如果先写了数据库修改,而在日志文件中没有登记下这个修改,则以后就无法恢复这个修改了–如果先写日志,但没有修改数据库,按日志文件恢复时只不过是多执行一次不必要的UNDO操作,并不会影响数据库的正确性第六章数据库恢复技术6.1 事务的基本概念6.2 数据库恢复概述6.3 故障的种类6.4 恢复的实现技术6.5 恢复策略6.6 具有检查点的恢复技术6.7 数据库镜像6.8 小结6.5 恢复策略6.5.1 事务故障的恢复6.5.2 系统故障的恢复6.5.3 介质故障的恢复6.5.1 事务故障的恢复•事务故障:事务在运行至正常终止点前被中止•恢复方法由恢复子系统利用日志文件撤消(UNDO)此事务已对数据库进行的修改•事务故障的恢复由系统自动完成,不需要用户干预事务故障的恢复步骤1. 反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。
即将日志记录中“更新前的旧值”写入数据库。
–插入操作,“更新前的值”为空,则相当于做删除操作–删除操作,“更新后的值”为空,则相当于做插入操作–若是修改操作,则用旧值代替新值事务故障的恢复步骤3. 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
4. 如此处理下去,直至读到此事务的开始标记,事务故障恢复就完成了。
6.5.2 系统故障的恢复•系统故障造成数据库不一致状态的原因–一些未完成事务对数据库的更新已写入数据库–一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库•恢复方法–1. Undo 故障发生时未完成的事务–2. Redo 故障发生时已完成的事务•系统故障的恢复由系统在重新启动时自动完成,不需要用户干预系统故障的恢复步骤1. 正向扫描日志文件(即从头扫描日志文件)–在故障发生前已经提交的事务放入Redo 队列–故障发生时尚未完成的事务放入Undo 队列系统故障的恢复步骤2. 对Undo队列事务进行UNDO处理反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作3. 对Redo队列事务进行REDO处理正向扫描日志文件,对每个REDO事务重新执行登记的操作6.5.3 介质故障的恢复恢复方法:1. 重装数据库,使数据库恢复到一致性状态2. 重做已完成的事务6.5.3 介质故障的恢复恢复步骤1. 装入最新的后备数据库副本,使数据库恢复到最近一次转储时的一致性状态。
对于静态转储的数据库副本,装入后数据库即处于一致性状态对于动态转储的数据库副本,还须同时装入转储时刻的日志文件副本,利用与恢复系统故障相同的方法(即REDO+UNDO ),才能将数据库恢复到一致性状态。