精华内容
下载资源
问答
  • 事务故障:事务在运行到正常终止前被终止 恢复方法     由恢复子系统利用日志文件撤销UNDO此事务已经对数据库进行的修改      事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预 事务故障的...

    关注公众号凡花花的小窝,收获更多的考研计算机专业编程相关的资料
    10.5恢复策略
    10.5.1事务故障的恢复
    事务故障:事务在运行到正常终止点前被终止
    恢复方法
        由恢复子系统利用日志文件撤销UNDO此事务已经对数据库进行的修改
         事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预
    事务故障的恢复步骤
        1.反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新操作
        2.对该事务的刚更新操作执行逆操作,即将日志记录中更新前的值写入数据库
             插入操作:“更新前的值”为空,则相当于做删除操作
             删除操作:“更新后的值”为空,则相当于做插入操作
             如果是修改操作,则相当于用修改前的值代替修改后的值
    3.继续反向扫描日志文件,查找该事务的其他更新操作,并作同样的处理
    4.如此处理下去了,知道读到此事务的开始标记,事务故障恢复就完成了

    10.6.2系统故障的恢复
    系统故障造成的数据库不一致的状态的原因:
        未完成事务对数据库的更新可能已经写入数据库
        已经提交的事务对数据库的更新可能还留在缓冲区没有来得及写入数据库中
    恢复方法
        1.UNDO故障发生的时候没有完成的事务
        2.REDO已经完成的事务
    系统故障的恢复由系统在重新启动的时候自动完成,不需要用户的干预
    1.正向扫描日志文件(即从头扫描日志文件)
         重做(REDO)队列,在故障发生前已经提交的事务
             这些事务既有BEGIN TRANSACTIO

    展开全文
  • 事务故障:事务在运行至正常终止前被中止 恢复方法:由恢复子系统应利用日志文件撤消(UNDO)此事务已对数据库进行的修改,事务故障的恢复由系统自动完成,不需要用户干预 系统故障造成数据库不一致状态的原因 ...

    数据库发生故障的原因

    1. 计算机硬件故障
    2. 软件的错误
    3. 操作员的失误 ‘
    4. 恶意的破坏

    数据库发生故障的影响

    1. 运行事务非正常中断,影响数据库中数据的正确性
    2. 破坏数据库,全部或部分丢失数据

    什么是数据库的恢复

    • 数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的功能,这就是数据库的恢复管理系统对故障的对策。
    • 恢复子系统是数据库管理系统的一个重要组成部分 。
    • 恢复技术是衡量系统优劣的重要指标。

    故障的介绍

    事务故障

    • 事务故障:事务在运行过程中未运行至正常终止点就夭折了。

    事务故障常见原因

    • (1)输入数据有误
    • (2)运算溢出
    • (3)违反了某些完整性限制
    • (4)某些应用程序出错
    • (5)并行事务发生死锁

    事务故障恢复

    • (1) 可预见错误:由事务程序来处理

    • (2) 不可预见错误:由DBMS强行回滚该事务

    系统故障

    1. 整个系统的正常运行突然被破坏
    2. 所有正在运行事务全部非正常终止
    3. 内存中缓冲区信息全部丢失,外存中数据未受影响

    系统故障的常见原因

    1. 操作系统、DBMS代码错误
    2. 硬件错误,如CPU故障
    3. 突然断电

    系统故障恢复

    • (1) 回滚非正常终止的事务
    • (2) 重做缓冲区中已提交的事务

    介质故障

    • 存储数据库的设备发生故障,使存储在其上的数据部分或全部受到破坏丢失,又称硬故障。

    介质故障的常见原因

    • (1)磁盘损坏
    • (2)磁头碰撞
    • (3)操作系统的潜在错误
    • (4)瞬时强磁场干扰

    介质故障恢复

    • (1) 装入发生介质故障前某个时刻的数据库副本

    • (2) 重做该时刻后的所有成功事务,提交结果记入数据库

    恢复的现实的技术(数据转储,登记日志文件)

    • (1) 建立冗余数据,数据转储(backup),登记日志文件(log)
    • (2) 利用冗余数据实施恢复

    数据转储(backup)

    • DBA将整个数据库复制到磁带或另一个磁盘上保存的过程 备用数据称为后备副本或后援副本

    数据转储(backup)的分类:静态转储和动态转储

    静态转储

    • 在系统中无运行事务时进行
    • 开始时数据库处于一致性状态,期间不允许对数据库的任何存取、修改
    • 优点:实现简单
    • 缺点:降低了数据库的可用性
    • 转储必须等用户事务结束 新的事务必须等转储结束

    动态转储

    • 操作与用户事务并发进行

    • 期间允许对数据库进行存取、修改

    • 优点:提高了数据库的可用性,不用等待正在运行的用户事务结束,不影响新事务的运行。

    • 缺点:不能保证副本中的数据正确有效

    转储的分类:海量存储和增量存储

    • 海量转储:每次转储全部数据库
    • 增量转储:只转储上次转储后更新过的数据

    海量转储与增量转储比较:

    • 使用海量转储的后备副本进行恢复较为方便
    • 当数据库很大,事务处理频繁时,增量转储更有效

    登记日志文件

    日志文件的格式及内容:以记录为单位的日志文件内容:

    • 事务开始标记(BEGIN TRANSACTION)
    • 事务结束标记(COMMIT或ROLLBACK)
    • 事务的所有更新操作

    日志记录包含:

    • 事务标识
    • 操作类型(插入、删除或修改)
    • 操作对象(记录ID)
    • 更新前数据的旧值(插入时为空)
    • 更新后数据的新值(删除时为空)

    在这里插入图片描述
    为保证数据库是可恢复的,必须遵循两条原则:

    • (1) 登记次序严格按并行事务执行的时间次序
    • (2) 先写日志文件,后写数据库
    • 写日志文件:把修改的日志记录写到日志文件
    • 写数据库操作:把对数据的修改写到数据库中

    为何先写日志文件?

    • 写数据库和写日志文件是两个不同的操作,两个操作之间可能发生故障
    • 如果先写数据库修改,而在日志文件中没有登记,则无法恢复该修改;
    • 如果先写日志,但没有修改数据库,恢复时只是多执行一次不必要的Undo操作,并不影响数据库的正确性;

    (事物,系统,介质)故障的恢复

    事务故障的恢复

    事务故障:

    • 事务在运行至正常终止点前被中止。

    恢复方法:

    • 恢复子系统利用日志文件撤消事务对数据库的修改,由系统自动完成,不需要用户干预。

    恢复步骤:

    • (1) 反向扫描文件日志(从后向前),查找该事务的更新操作;
    • (2) 对更新操作执行逆操作,将 “更新前的值” 写入数据库:对插入执行删除,对删除执行插入,对修改执行修改;
    • (3) 继续反向扫描,查找其他更新操作,执行2;
    • (4) 扫描到该事务的开始标记,事务故障恢复结束

    系统故障的恢复

    系统故障恢复需要解决两种情况:

    • (1) 未完成事务对数据库的更新可能已经写入数据库;
    • (2) 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。

    系统故障恢复恢复步骤:

    • (1) 正向扫描日志文件(从前向后)
      Redo队列:故障发生前已提交的事务T1,T3,T7,…,有BEGIN TRANSACTION和COMMIT记录;
      Undo队列:故障发生时未完成的事务T2,T4,T5,…,只有BEGIN TRANSACTION记录,无COMMIT记录;
    • (2) 对Undo队列事务进行Undo处理,反向扫描日志文件,对每个事务的更新操作执行逆操作;
    • (3) 对Redo队列事务进行Redo处理,正向扫描日志文件,重新执行对每个事务;

    介质故障的恢复

    介质恢复方法:

    • 重装数据库,使数据库恢复到一致性状态
    • 重做已完成的事务

    介质故障恢复步骤:

    • (1) 装入最新的后备数据库副本;
      装入静态转储的数据库副本,数据库即处于一致性状态
      装入动态转储的数据库副本,还须同时装入转储时刻的日志文件副本,利用与恢复系统故障相同的方法,数据库才能恢复到一致性状态

    • (2) 装入日志文件副本,重做已完成的事务
      扫描日志文件,找出故障发生时已提交的事务,记入Redo队列;
      正向扫描日志文件,重做Redo队列中的事务;

    具有检查点的恢复技术

    问题:

    • (1) 扫描日志:搜索整个日志耗费大量时间;
    • (2) Redo处理:重新执行浪费大量时间;

    解决方案:检查点

    • 在日志文件中增加检查点记录;

    • 增加重新开始文件保存检查点地址;

    • 恢复子系统动态维护日志;

    维护日志文件步骤:

    • (1) 将当前日志缓冲区的所有日志记录写入磁盘的日志文件;
    • (2) 在日志文件中写入一个检查点记录;
    • (3) 将当前数据缓冲区的所有数据记录写入磁盘的数据库中;
    • (4) 把检查点记录在日志文件中的地址写入重新开始文件。

    建立检查点时间:

    • 定期:按照预定的一个时间间隔;

    • 不定期:按照某种规则,如日志文件写满一半时;

    检查点恢复策略:

    • 在检查点之前提交的事务不需要Redo:当事务在一个检查点之前提交,对数据库所做的修改已写入数据库。

    在这里插入图片描述
    检查点恢复的步骤

    • (1) 在重新开始文件中找到最后一个检查点记录的地址,并在日志文件中找到该检查点记录;
    • (2)由该检查点记录得到检查点建立时刻所有正在执行的事务清单,建立Undo队列和Redo队列:正在执行的事务暂时放入Undo队列,Redo队列暂时为空;
    • (3) 从检查点开始正向扫描日志文件,直到日志文件结束; 新开始的事务:暂时放入Undo队列 提交的事务:从Undo队列移到Redo队列
    • (4) 对Undo队列中的事务执行Undo操作, 对Redo队列中的事务执行Redo操作。

    数据库镜像

    介质故障是对系统影响最为严重的一种故障。

    • 介质故障恢复比较费时;
    • 为预防介质故障,DBA必须周期性转储数据库,加重了DBA负担

    提高数据库可用性的解决方案:数据库镜像(Mirror)
    数据库镜像

    • DBMS自动利用镜像磁盘整个数据库或关健数据复制到另一个磁盘,主数据库更新时,DBMS自动把更新后的数据复制过去,保证镜像数据与主数据库的一致性。

    出现介质故障时

    • 镜像磁盘继续提供使用
    • DBMS自动利用镜像磁盘数据进行数据库恢复
    • 不需要关闭系统和重装数据库副本

    在这里插入图片描述

    没有故障时

    • 可用于并发操作
    • 一个用户对数据加排他锁修改数据时,其他用户可以读取镜像数据库的数据,不必等待用户释放锁

    在这里插入图片描述

    展开全文
  • 第10章 数据库恢复技术 了解 数据库的一致性状态 数据库运行中可能产生的故障类型,它们如何影响事务的正常执行...具有检查点恢复技术 恢复的基本原理 针对不同故障的恢复策略和方法 日志文件的使用 知识点 事...

    第10章 数据库恢复技术

    了解

    • 数据库的一致性状态
    • 数据库运行中可能产生的故障类型,它们如何影响事务的正常执行,如何破坏数据库数据
    • 数据转储的概念及分类
    • 数据库的镜像功能

    掌握

    • 事务的基本概念和事务的ACID性质
    • 数据库恢复的实现技术
    • 日志文件的内容及作用
    • 登记日志文件所要遵循的原则
    • 具有检查点的恢复技术
    • 恢复的基本原理
    • 针对不同故障的恢复策略和方法
    • 日志文件的使用

    知识点

    • 事务的概念及事务的4个特性。恢复技术能保证事务的哪些特性
      • 事务是用户定义的一个数据库操作序列,这些操作要么全做、要么全不,是一个不可分割的工作单位事务具有4个特性(也称ACID特性)
        • 原子性(Atomicity)
        • 一致性(Consistency)
        • 隔离性(Isolation)
        • 持续性(Durability)
      为什么事务非正常结束时会影响数据库数据的正确性,举例说明
      • 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障,有些事务尚未完成就被迫中断,这些未完成事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态,或者说是不一致的状态。
      • 例如某工厂的库存管理系统中,要把数量为Q的某种零件从仓库1移到仓库2存放。则可以定义一个事务T,T包括两个操作;Q1=Q1-Q,Q2=Q2+Q。如果T非正常终止时只做了第一个操作,则数据库就处于不一致性状态,库存量无缘无故少了Q。
      登记日志文件时为什么必须先写日志文件,后写数据库?
      • 把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障,即这两个写操作只完成了一个。
      • 如果先写了数据库修改,而在运行记录中没有登记这个修改,则以后就无法恢复这个修改了。如果先写日志,但没有修改数据库,在恢复时只不过是多执行一次UNDO操作,并不会影响数据库的正确性。所以一定要先写日志文件,即首先把日志记录写到日志文件中,然后写数据库的修改。
    • 针对不同的故障,试给出恢复的策略和方法(事务故障恢复/系统故障恢复/介质故障恢复)
      • 事务故障的恢复步骤
        • 反向扫描文件日志,查找该事务的更新操作。
        • 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。直至读到此事务的开始标记,该事务故障的恢复就完成了。
        系统故障的恢复步骤
        • 正向扫描日志文件,找出在故障发生前已经提交的事务队列(REDO队列)和未完成的事务队列(UNDO队列)。
        • 对未完成的事务队列中的各个事务进行UNDO处理。
        • 对已经提交的事务队列中的各个事务进行REDO处理
        介质故障的恢复步骤
        • 装入最新的数据库后备副本(离故障发生时刻最近的转储副本),使数据库恢复到转储时的一致性状态。
        • 装入转储结束时刻的日志文件副本
        • 启动系统恢复命令,由DBMS完成恢复功能,即重做已完成的事务。
      什么是检查点记录,包括哪些内容
      • 检查点记录是一类新的日志纪录。它的内容包括
        • 建立检查点时刻所有正在执行的事务清单,如下图中的T1、T2
        • 这些事务的最近一个日志记录的地址,如下图中的D1、D2
      具有检查点的恢复技术有什么优点?举例
      • 利用日志技术进行数据库恢复时,恢复子系统必须搜索整个日志,这将耗费大量的时间。此外,需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了,恢复子系统又重新执行了这些操作,浪费了大量时间。检查点技术就是为了解决这些问题。
      • 例如
      使用检查点方法进行恢复的步骤。
      • ① 从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录。② 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。
        • 这里建立两个事务队列:
          • UNDO-LIST: 需要执行undo操作的事务集合
          • REDO-LIST: 需要执行redo操作的事务集合
        • 把ACTIVE-LIST暂时放入UNDO-LIST队列,REDO队列暂为空。
        ③ 从检查点开始正向扫描日志文件
        • 如有新开始的事务Ti,把Ti暂时放入UNDO-LIST队列
        • 如有提交的事务Tj,把Tj从UNDO-LIST队列移到REDO-LIST队列,直到日志文件结束
      • ④ 对UNDO-LIST中的每个事务执行UNDO操作, 对REDO-LIST中的每个事务执行REDO操作
      什么是数据库镜像?它有什么用途?
      • 数据库镜像即根据DBA的要求,自动把整个数据库或者其中的部分关键数据复制到另一个磁盘上。每当主数据库更新时,DBMS自动把更新后的数据复制过去,即DBMS自动保证镜像数据与主数据的一致性。数据库镜像的用途
        • 用于数据库恢复。当出现介质故障时,镜像磁盘可继续使用,同时DBMS自动利用镜像磁盘数据进行数据库的恢复,不需要关闭系统和重装数据库副本。
        • 提高数据库的可用性。在没有出现故障时,当一个用户对某个数据加排它锁进行修改时,其他用户可以读镜像数据库上的数据,而不必等待该用户释放锁。

    补充

    在系统故障的恢复策略中,为什么UNDO处理反向扫描日志文件,REDO处理正向扫描日志文件

        • 如果存在同一个数据的多个UNDO操作,需要将数据恢复到第一个失败事务之前,如果正向扫描处理日志文件,无法实现这一目标,因此应该反向扫描日志文件。对于同一个数据的多个REDO操作,需要将数据恢复到最后一个成功事务之后,因此应该正向扫描日志文件
      • 说明恢复系统是否可以保证事务的原子性和持续性
        • 原子性是指操作要么都做,要么都不做,在恢复策略中UNDO可以保证将未成功提交的事务所有操作都取消,REDO可以保证将成功提交的事务所有操作都完成,因此需确保事务的原子性;
        • 持续性是指一旦事务提交,对数据库中数据的改变是永久性的,REDO可以保证事务只要提交,改变一定被永久实现,因此要确保事务的持续性
      • 综合题
      • 数据库中为什么要有恢复子系统?它的功能是什么?
        • 答: 因为计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏是不可避免的,这些故障轻则造成运行事务非正常中断,影响数据库中数据的正确性,重则破坏数据库,使数据库中全部或部分数据丢失,因此必须要有恢复子系统。
        • 恢复子系统的功能是:把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)。
      • 数据库运行中可能产生的故障有哪几类?哪些故障影响事务的正常执行?哪些故障破坏数据库数据?
        • 事务内部的故障
        • 系统故障
        • 介质故障
        • 计算机病毒
          事务故障、系统故障和介质故障影响事务的正常执行;介质故障和计算机病毒破坏数据
      • 数据库恢复的基本技术有哪些?
        • 数据转储和登录日志文件是数据库恢复的基本技术。
        • 当系统运行过程中发生故障,利用转储的数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。
      • 数据库转储的意义是什么? 试比较各种数据转储方法。
        • 数据转储是数据库恢复中采用的基本技术。所谓转储即DBA定期地将数据库复制到磁带或另一个磁盘上保存起来的过程。当数据库遭到破坏后可以将后备副本重新装入,将数据库恢复到转储时的状态。
          • 静态转储:在系统中无运行事务时进行的转储操作。静态转储简单,但必须等待正运行的用户事务结束才能进行。同样,新的事务必须等待转储结束才能执行。显然,这会降低数据库的可用性。
          • 动态转储:指转储期间允许对数据库进行存取或修改。动态转储可克服静态转储的缺点,它不用等待正在运行的用户事务结束,也不会影响新事务的运行。但是,转储结束时后援副本上的数据并不能保证正确有效。因为转储期间运行的事务可能修改了某些数据,使得后援副本上的数据不是数据库的一致版本。
          • 为此,必须把转储期间各事务对数据库的修改活动登记下来,建立日志文件(log file)。这样,后援副本加上日志文件就能得到数据库某一时刻的正确状态。
        • 转储还可以分为海量转储和增量转储两种方式。
          • 海量转储是指每次转储全部数据库。
          • 增量转储则指每次只转储上一次转储后更新过的数据。
          • 从恢复角度看,使用海量转储得到的后备副本进行恢复一般说来更简单些。但如果数据库很大,事务处理又十分频繁,则增量转储方式更实用更有效。
      • 什么是日志文件?为什么要设立日志文件?
        • 日志文件是用来记录事务对数据库的更新操作的文件。
        • 设立日志文件的目的是: 进行事务故障恢复;进行系统故障恢复;协助后备副本进行介质故障恢复。
      • 登记日志文件时为什么必须先写日志文件,后写数据库?
        • 把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障,即这两个写操作只完成了一个。
        • 如果先写了数据库修改,而在运行记录中没有登记这个修改,则以后就无法恢复这个修改了。如果先写日志,但没有修改数据库,在恢复时只不过是多执行一次UNDO操作,并不会影响数据库的正确性。所以一定要先写日志文件,即首先把日志记录写到日志文件中,然后写数据库的修改。
      • 一个事务的执行,要么全部完成,要么全部不做,一个事务中对数据库的所有操作都是一个不可分割的操作序列的属性是【原子性】
      • 表示两个或多个事务可以同时运行而不互相影响的是【独立性】
      • 事务的持续性是指【事务一旦提交,对数据库的改变是永久的】
      • SQL语言中的COMMIT语句的主要作用是【提交事务】
      • SQL语言中用【ROLLBACK】语句实现事务的回滚
      • 若系统在运行过程中,由于某种硬件故障,使存储在外存上的数据部分损失或全部损失,这种情况称为【介质故障】
      • 在DBMS中实现事务持久性的子系统是【恢复管理子系统】
      • 后援副本的作用是【故障后的恢复】
      • 事务日志用于保存【对数据的更新操作】
      • 数据库恢复的基础是利用转储的冗余数据。这些转储的冗余数据包括【日志文件、数据库后备副本】
    展开全文
  • 数据库恢复技术

    千次阅读 2019-09-30 00:55:18
    数据库恢复技术 事务:是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位。 事物的 ACID 特性:原子性、一致性、隔离性、持续性。 恢复的实现技术:建立冗余数据 ->...

    ---恢复内容开始---

    数据库恢复技术

    • 事务:是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位。
    • 事物的 ACID 特性:原子性、一致性、隔离性、持续性。
    • 恢复的实现技术:建立冗余数据 -> 利用冗余数据实施数据库恢复。
    • 建立冗余数据常用技术:数据转储(动态海量转储、动态增量转储、静态海量转储、静态增量转储)、登记日志文件。

    ACID特性

    1. 原子性(Atomicity)

        一个原子事务要么完整执行,要么干脆不执行。这意味着,工作单元中的每项任务都必须正确执行。如果有任一任务执行失败,则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行,事务就会被提交,即对数据所作的修改将会是永久性的。

    2. 一致性(Consistency)

        一致性代表了底层数据存储的完整性。它必须由事务系统和应用开发人员共同来保证。事务系统通过保证事务的原子性,隔离性和持久性来满足这一要求; 应用开发人员则需要保证数据库有适当的约束(主键,引用完整性等),并且工作单元中所实现的业务逻辑不会导致数据的不一致(即,数据预期所表达的现实业务情况不相一致)。例如,在一次转账过程中,从某一账户中扣除的金额必须与另一账户中存入的金额相等。

    3. 隔离性(Isolation)

        隔离性意味着事务必须在不干扰其他进程或事务的前提下独立执行。换言之,在事务或工作单元执行完毕之前,其所访问的数据不能受系统其他部分的影响。

        当我们编写了一条 update 语句,提交到数据库的一刹那间,有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作,可以想象,如果不稍加控制,就会出大麻烦来。我们必须保证数据库操作之间是“隔离”的(线程之间有时也要做到隔离),彼此之间没有任何干扰。

    4. 持久性(Durability)

        持久性表示在某个事务的执行过程中,对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。这样可以保证,所作的修改在任何系统瘫痪时不至于丢失。当我们执行一条 insert 语句后,数据库必须要保证有一条数据永久地存放在磁盘中。

    隔离性

    三类数据读问题

     1.Dirty Read(脏读):

    一个事务读到另外一个事务还没有提交的数据,我们称之为脏读。(进行存款事务时候,还没有存完,允许查询事务)

     2.Unrepeatable Read(不可重复读):

    在数据库访问中,一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。

    例如:事务B中对某个查询执行两次,当第一次执行完时,事务A对其数据进行了修改。事务B中再次查询时,数据发生了改变

     3.Phantom Read(幻读)

    幻读,是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样.

    两类数据更新问题

      1.第一类丢失更新

      2.第二类丢失更新

    首先看看“脏读”,看到“脏”这个字,我就想到了恶心、肮脏。数据怎么可能脏呢?其实也就是我们经常说的“垃圾数据”了。比如说,有两个事务,它们在并发执行(也就是竞争)。看看以下这个表格,您一定会明白我在说什么:

    余额应该为 1100 元才对!请看 T6 时间点,事务 A 此时查询余额为 900 元,这个数据就是脏数据,它是事务 A 造成的,明显事务没有进行隔离,渗过来了,乱套了。

    所以脏读这件事情是非常要不得的,一定要解决掉!让事务之间隔离起来才是硬道理。

    不可重复读又怎么解释呢?还是用类似的例子来说明:

    事务 A 其实除了查询了两次以外,其他什么事情都没有做,结果钱就从 1000 变成 0 了,这就是重复读了。可想而知,这是别人干的,不是我干的。其实这样也是合理的,毕竟事务 B 提交了事务,数据库将结果进行了持久化,所以事务 A 再次读取自然就发生了变化。

    幻读

     

     银行工作人员,每次统计总存款,都看到不一样的结果。不过这也确实也挺正常的,总存款增多了,肯定是这个时候有人在存钱。但是如果银行系统真的这样设计,那算是玩完了。这同样也是事务没有隔离所造成的,但对于大多数应用系统而言,这似乎也是正常的,可以理解,也是允许的。银行里那些恶心的那些系统,要求非常严密,统计的时候,甚至会将所有的其他操作给隔离开,这种隔离级别就算非常高了(估计要到 SERIALIZABLE 级别了)。

    归纳一下,以上提到了事务并发所引起的跟读取数据有关的问题,各用一句话来描述一下:

      1.脏读:事务 A 读取了事务 B 未提交的数据,并在这个基础上又做了其他操作。

      2.不可重复读:事务 A 读取了事务 B 已提交的更改数据。

      3.幻读:事务 A 读取了事务 B 已提交的新增数据。

    第一条是坚决抵制的,后两条在大多数情况下可不作考虑。

    这就是为什么必须要有事务隔离级别这个东西了,它就像一面墙一样,隔离不同的事务。看下面这个表格,您就清楚了不同的事务隔离级别能处理怎样的事务并发问题:

    Read Uncommitted:最低的隔离级别,什么都不需要做,一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。

    Read Committed:只有在事务提交后,其更新结果才会被其他事务看见。可以解决脏读问题。
    Repeated Read:在一个事务中,对于同一份数据的读取结果总是相同的,无论是否有其他事务对这份数据进行操作,以及这个事务是否提交。可以解决脏读、不可重复读。
    Serialization:事务串行化执行,隔离级别最高,牺牲了系统的并发性。可以解决并发事务的所有问题。
    通常,在工程实践中,为了性能的考虑会对隔离性进行折中。

    更新丢失问题

    第一类丢失更新,A事务撤销时,把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题,通过下面的账户取款转账就可以看出来:

    第二类丢失更新,B事务覆盖A事务已经提交的数据,造成A事务所做操作丢失

    解决更新丢失的办法: 

     

    悲观锁

    试图在更新之前把行锁住,使用SELECT … FOR UPDATE然后更新数据。

    乐观锁

    认为数据不会被其他用户修改,修改屏幕上的信息而不要锁

    1.使用版本列的乐观锁定

    增加NUMBER或TIMESTAMP或DATE列。每次修改行时,检查数据库中这一列的值与最初读出的值是否匹配,匹配的话修改数据且通过触发器要负责递增NUMBER、DATE、TIMESTAMP。

    增加一个时间戳列,可以知道最后修改时间。

    2.使用校验和的乐观锁定

    用基数据本身来计算一个“虚拟的”版本列,生成散列值进行比较。

    数据库独立性好,从CPU使用和网络传输方面来看,资源开销量大。

    3.使用

    ORA_ROWSCN的乐观锁定

    建立在Oracle SCN的基础上,建表时,启用ROWDEPENDENCIES,防止整个数据块的ORA_ROWSCN向前推进。可以用SCN_TO_TIMESTAMP(ORA_ROWSCN)将SCN转换为时间格式。

    将原先的悲观锁机制修改为乐观锁来控制并发,可以使用ORA_ROWSCN,这样可以无需增加新列。也可以通过SCN_TO_TIMESTAMP来获取最后修改时间。

     

    数据库恢复技术

    数据库管理系统要解决的问题:

          必须保证多个事务的交叉运行不影响这些事务的原子性

          必须保证被强行终止的事务对数据库和其他事务没有任何影响

          这两个问题就是数据库管理系统的恢复机制和并发控制机制的责任

    把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态),就称为数据库恢复。

    故障的分类

    事物内部的故障 

    两个更新操作要么全部完成要么全部不做。否则就会使数据库处于不一致状态,例如只把账户甲的余额减少了而没有把账户乙的余额增加。在这段程序中若产生账户甲余额不足的情况,应用程序可以发现并让事务滚回,撤销已作的修改,恢复数据库到正确状态

    常见的原因:事务内部更多的故障是非预期的,是不能由应用程序处理的。

    • 运算溢出
    • 并发事务发生死锁而被选中撤销该事务
    • 违反了某些完整性限制等

    系统故障(软故障)

    指造成系统停止运转的任何事件,使得系统要重新启动

    常见的原因:

    • 特定类型的硬件错误(如CPU故障)
    • 操作系统故障
    • DBMS代码错误
    • 系统断电

    介质故障(硬故障,指外存故障)

    常见原因:

    • 磁盘损坏
    • 磁头碰撞
    • 操作系统的某种潜在错误
    • 瞬时强磁场干扰

    恢复的实现技术

    1.恢复操作的基本原理:冗余

            利用存储在系统其他地方的冗余数据来重建数据库中已被破坏或者不正确的那部分数据

    2.恢复机制涉及到的关键:

    建立数据冗余数据的方法:数据转储,登陆日志文件

    数据转储

    转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程,备用的数据成为后备副本或后援副本

    数据转储的使用

    数据库遭到破坏后可以将后备副本重新装入

    重装后备副本只能将数据库恢复到转储时的状态

    转储方法

    静态转储

    • 系统中无运行事务时进行的转储操作
    • 转储期间不允许对数据库进行操作
    • 转储开始时数据库处于一致性状态
    • 得到的一定是一个数据一致性的副本

    优点:实现简单

    缺点:1.降低了数据库的可用性   2.转储必须等待正运行的用户事务结束    3.新的事务必须等转储结束

    动态转储

    • 转储操作与用户并发进行
    • 转储期间允许对数据库进行存取或修改

    优点:1.不用等待正在进行的事务结束  2.转储期间允许对数据库进行存取或修改

    缺点:不能保证副本中的数据正确有效

    动态转储进行故障恢复,需要把动态转储期间各事务对数据库的修改活动登记下来,建立日志文件;后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态

     海量转储

    • 每次转储全部数据库

    增量转储

    • 只转储上次转储更新过的数据

    海量转储与增量转储的比较

    1.从恢复角度看,使用海量转储得到的后备副本进行恢复往往更方便

    2.如果数据库很大,事务处理又十分频繁,则增量转储更有效

     

     登记日志文件

    日志文件:记录事务对数据库的更新操作文件

    格式:1. 以记录为单位的日志文件(事务标识,操作类型,操作对象,更新前数据的旧值,更新后数据的新值);2. 以数据表为单位的日志文件(事务标识,被更新的数据块)

    内容:1 各个事务的开始标记;2 各个事务的结束标记;3 各个事务所有的更新操作

    作用:1 进行事务故障恢复;2 进行系统故障恢复;3 协助后备副本进行介质故障恢复

    利用静态转储副本和日志文件进行恢复

     

     

     

    对上图进行说明:

    • 系统在Ta时刻停止运行事务,进行数据库转储
    • 在Tb时刻转储完毕,得到Tb时刻的数据库一致性副本
    • 系统运行到Tf时刻发生故障
    • 为恢复数据库,首先由DBA重装数据库后备副本,将数据库恢复到Tb时刻的状态
    • 重新运行自Tb~Tf时刻的所有更新事务,把数据库恢复到故障发生前的一致状态

    登记日志文件

    基本原则:登记的次序严格按并行事务执行的时间次序;必须先写日志文件,后写数据库

    恢复策略

     事务故障的恢复

    事务故障:事务运行至正常终止点前被终止

    恢复方法:由恢复子系统利用日志文件撤销(UNDO)此事务已对数据库进行的修改

     注:事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预

    恢复步骤

    1. 反向扫描文件日志(从后往前扫描),查找该事务的更新操作
    2. 对该事务的更新操作执行逆操作,即将日志记录中“更新前的值”写入数据库
    3. 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
    4. 如此处理下去,直至读到此事务的开始标记,事务故障恢复就完成了。

    系统故障的恢复

    系统故障:

    1. 未完成事务对数据库的更新已写入数据库
    2. 已提交事务对数据库的更新还留在缓存区没来得及写入数据库

    恢复方法:

    1. UNDO故障发生时未完成的事务
    2. Redo已完成的事务

     注:系统故障的恢复由系统在重新启动时自动完成,不需要用户干预

     

    恢复步骤:

    1. 正向扫描日志文件(1.将在故障发生前已经提交的事务加入重做(REDO)队列,这些事务既有begin transaction记录,也有commit记录;2.将在故障发生时未完成的事务加入撤销(Undo)队列,这些事务中只有begin transaction记录,无相应的commit记录)
    2. 对撤销(Undo)队列事务进行撤销(Undo)处理(1.反向扫描日志文件,对每个undo事务的更新操作进行逆操作;2.将日志记录中“更新前的值”写入数据库)
    3. 对重做(Redo)队列事务进行重做(Redo)处理(1.正向扫描日志文件,对每个REDO事务重新执行登记的操作;2.将日志记录中“更新后的值”写入数据库)

    介质故障的恢复(需要DBA介入)

    1. 重装数据库
    2. 重做已完成的事务

    具有检查点的恢复技术

    解决问题:

    1. 搜索整个日志将耗费大量的时间
    2. REDO处理:重新执行,浪费了大量时间

    解决方法:

    1. 在日志文件中增加检查点记录
    2. 增加重新开始文件
    3. 恢复子系统在登录日志文件期间动态地维护日志

     

    建立检查点:

    恢复子系统可以定期或不定期地建立检查点,保存数据库状态

    1. 定期:按照预定的一个时间间隔,如每隔一小时建立一个检查点
    2. 不定期:按照某种规则,如日志文件已写满一半建立一个检查点

    恢复:

     

    T1:在检查点之前提交

    T2:在检查点之前开始执行,在检查点之后故障点之前提交

    T3:在检查点之前开始执行,在故障点时还未完成

    T4:在检查点之后开始执行,在故障点之前提交

    T5:在检查点之后开始执行,在故障点时还未完成

    利用检查点的恢复步骤 

    1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录
    2. 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
      1. 建立两个事务队列
        • UNDO-LIST
        • REDO-LIST
      2. 把ACTIVE-LIST暂时放入UNDO-LIST队列,REDO队列暂为空。
    3. 从检查点开始正向扫描日志文件,直到日志文件结束
      1. 如有新开始的事务Ti,把Ti暂时放入UNDO-LIST队列
      2. 如有提交的事务Tj,把Tj从UNDO-LIST队列移到REDO-LIST队列
    4. 对UNDO-LIST中的每个事务执行UNDO操作
    5. 对REDO-LIST中的每个事务执行REDO操作

    数据库镜像

    数据库镜像

    • DBMS自动把整个数据库或其中的关键数据复制到另一个磁盘上
    • DBMS自动保证镜像数据与主数据库的一致性,每当主数据库更新时,DBMS自动把更新后的数据复制过去,如图

     

     

     

    出现介质故障时

    1. 可由镜像磁盘继续提供使用
    2. 同时DBMS自动利用镜像磁盘数据进行数据库的恢复
    3. 不需要关闭系统和重装数据库副本

    没有出现故障时

    1. 可用于并发操作
    2. 一个用户对数据加排他锁修改数据,其他用户可以读镜像数据库上的数据,而不必等待该用户释放锁

     

    结论

    事务是数据库的逻辑工作单位


    DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性

    DBMS必须对事务故障、系统故障和介质故障进行恢复
    恢复中最经常使用的技术:数据库转储和登记日志文件
    恢复的基本原理:利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库
    常用恢复技术
    事务故障的恢复(UNDO)
    系统故障的恢复(UNDO + REDO)
    介质故障的恢复(重装备份并恢复到一致性状态 + REDO)
    提高恢复效率的技术
    检查点技术(

    Ø可以提高系统故障的恢复效率

    Ø可以在一定程度上提高利用动态转储备份进行介质故障恢复的效率

    镜像技术(镜像技术可以改善介质故障的恢复效率)

     

    转载于:https://www.cnblogs.com/wzhao-cn/p/11557698.html

    展开全文
  • 数据恢复技术揭秘

    万次阅读 2015-05-20 23:15:56
    计算机安全专家威廉·史密斯说:“创建这些数据也许只花了10万元,但当你在关键时刻打算把它们全部找回来时,你得准备100万元的支票。” ... 而如果你掌握了数据恢复... 现在,我们一起走近这项价值百万元的技术
  • 第10章 数据库恢复技术 事务是一系列的数据库操作,是数据库应用程序的基本逻辑单元。事务处理(transaction processing)技术主要包括数据库恢复技术和并发控制技术。 10.1 事务的基本概念 1、事务 所谓事务是...
  • 事务处理(transaction processing)技术主要包括数据库恢复技术和并发控制技术。 10.1 事务的基本概念 事务:是用户定义的一个数据库操作序列,是一个不可分割的工作单位(原子性) 一般的,一个程序中被包含多个...
  • 事务处理(transaction processing)技术主要包括数据库恢复技术和并发控制技术。 10.1 事务的基本概念 事务:是用户定义的一个数据库操作序列,是一个不可分割的工作单位(原子性) 一般的,一个程序中被包含多...
  • 第七章 数据库恢复技术    一、选择题 1.一个事务的执行,要么全部完成,要么全部不做,一个事务中对数据库的所有操作都是一个不可分割的操作序列的属性是(A)。 A. 原子性   B. 一致性 C.独立性 D....
  • 数据恢复技术大揭密

    千次阅读 2006-04-08 11:32:00
    树梢上的博客 如何修改VMWare虚拟网卡的MAC地址- -| ...数据恢复技术大揭密     数据恢复技术大揭密    计算机安全专家威廉·史密斯说:“创建这些数据也许只花了10万元,但当你在关键时刻打算把它们全
  • 第七章 数据库恢复技术 1. 数据库系统中可能发生各种各样的故障,大致可以分为________ 、________ 、________ 和 ________ 等。 正确答案: 事务故障 系统故障 介质故障 计算机病毒 2. 数据库中为什么要有恢复子...
  • 一、事务的基本概念 1. 事务(Transaction) (1)概念 是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做...(3)事务是恢复和并发控制的基本单位 (4)定义事务 定义方式 显式定义方式 隐...
  • 第十章 数据库恢复技术10.1 事务的基本概念10.1.1.事务 1、事务(Transaction)是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位。 2、事务和程序是两个概念 (1)在关系...
  • 第10章 数据库恢复技术(数据库系统概论)
  • 文章目录一、 事务的基本概念1.事务1.1what's the 事务:1.2事务的定义1.2.1 事务的显示定义1.2.2 事务的隐式定义方式2.事务的ACID特性2.1原子性(Atomicity)2.2一致性(Consistency)...恢复技术是衡量系统优劣的重
  • 数据备份与恢复、系统备份与恢复

    万次阅读 2018-04-17 22:56:58
    数据备份与恢复、系统备份与恢复一、数据备份与恢复1、什么是备份备份,即另外准备一– 为应付文件、数据丢失或损坏等可能出现的意外情况,将电子计算机存储设备中的数据复制到大容量存储设备中2、备份对象的类别...
  • 该系列的博客都是基于《数据库系统概论》第五版王珊一书 前提: 因为最近要升学的原因,再加上重温数据库部分内容,所以整理一份比较详细且重点的笔记。适合有考研升学需求的人收藏 ...第十章 数据库恢复 //了解 数
  • 计算机网络技术知识

    万次阅读 多人点赞 2019-04-07 13:16:13
    计算机网络就是指,将分布在不同地理位置,具有独立功能的多台计算机及其外部设备,用通信设备与通信链路连接起来,在网络操作系统和通信协议及网络管理软件的管理协调,实现资源共享信息传递的系统。 计算机网路的...
  • 关系数据库——数据库恢复

    千次阅读 2019-12-02 14:04:14
    实现技术 恢复操作的基本原理:冗余 恢复机制涉及的两个关键问题 如何建立冗余数据 数据转储(backup) 登录日志文件(logging) 如何利用这些冗余数据实施数据库恢复 数据转储 数据转储定义: 转储...
  • 通过命令行或oracle企业管理器(oem)使备份进程自动化,执行oracle闪回恢复操作以及集成云计算技术。作为权威的资源,《oracle database 11g rman备份与恢复》也提供有关创建报告、优化性能以及执行第三方管理实用...
  • PostgreSQL备份和恢复

    千次阅读 2019-07-18 14:05:10
    虽然过程相当简单,但清晰地理解其底层技术和假设是非常重要的。 2.PostgreSQL数据备份方式 数据库的备份有多种分类方式。按照备份后的文件类型,可以分为物理备份(文件系统级别的备份)和逻辑备份(备份后的文件是...
  • NAT(地址转换技术)详解

    万次阅读 多人点赞 2018-03-17 16:31:35
    优点 缺点 NAT穿越技术 应用层网关(ALG) ALG的实际应用 NAT技术的未来 参考文献 NAT产生背景 今天,无数快乐的互联网用户在尽情享受Internet带来的乐趣。他们浏览新闻,搜索资料,下载软件,广交新朋...
  • 【知识总结】大数据技术原理与应用

    千次阅读 多人点赞 2020-11-05 10:23:16
    本文是对《大数据与云计算导论》课程知识的应试总结。基本涵盖了《大数据技术原理与应用》的重点内容。 思维导图由@福尔摩东整理 第一章 大数据概述 1、三次信息化浪潮 信息化浪潮 发生时间 标志 解决的问题 ...
  • 6-2DBMS的故障恢复

    千次阅读 2016-06-30 13:18:15
    6-2DBMS的故障恢复 数据库故障恢复就是把数据库从错误状态恢复到某一已知的正确状态的功能. 故障的种类事务内部故障 事务内部故障有预期故障,比如转账时钱不够,但更多是事务故障是非预期的,比如运算溢出,后文中...
  • 什么是微服务以及微服务的技术点

    万次阅读 2018-07-26 11:04:48
    RPC也有自己的优点,传输协议更高效,安全更可控,特别在一个公司内部,如果有统一个的开发规范和统一的服务框架时,他的开发效率优势更明显些。就看各自的技术积累实际条件,自己的选择了。 而异步消息的方式在...
  • 8.4 检查点与RBA 374 8.5 数据库的运行模式 376 8.6 逻辑备份与恢复 381 8.6.1 使用EXP进行逻辑备份 381 8.6.2 使用IMP进行逻辑恢复 386 8.6.3 使用数据泵(EXPDP/IMPDP) 389 8.7 物理备份与恢复 395 ...
  • 对于数据流量过大的网络中,往往单一设备无法承担,需要多...目前有许多不同的负载均衡技术用以满足不同的应用需求,如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡,以及链路聚合技术。 我们使用的...
  •  这篇资料主要讲了一下几个知识点: 1. 不完全恢复 2. 基于RMAN 的恢复主题 ...3. 表空间时间点恢复 4. 验证备份可恢复 5. 跨平台的数据库移动和RMAN 一. 不完全恢复 不完全恢复是
  • 技术:弹性计算ECS

    千次阅读 2013-10-23 21:27:03
    云计算(Cloud Computing)被业界看作继大型计算机、个人计算机、互联网之后的第四次IT产业革命,正日益成为未来互联网与移动技术相结合的一种新兴计算模式。云计算提供了IT基础设施和平台服务的新模式,顺应了当前...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 48,174
精华内容 19,269
关键字:

具有检查点的恢复技术的优点