一言
因为不可能,所以才值得相信。——浮士德
数据库系统概论笔记:第十章:数据库恢复技术

10.1 事务的基本概念

1.事务

  • 事务(Transaction)是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位。

  • 事务和程序是两个概念:在关系数据库中,一个事务可以是一条SQL语句,一组SQL语句或整个程序。一个程序通常包含多个事务。

  • 事务是恢复和并发控制的基本单位

  • 定义事物的语句有三条:

    • BEGIN TRANSACTION 开始

    • COMMIT 提交:该操作会将这个事物对数据的操作写到物理数据库去

    • ROLLBACK 回滚:撤销

   BEGIN TRANSACTION           BEGIN TRANSACTION
          SQL 语句1                   SQL 语句1
          SQL 语句2                   SQL 语句2
          。。。。。                   。。。。。
   COMMIT                      ROLLBACK

2.事务的ACID特性

  • 原子性(Atomicity):事务是数据库的逻辑工作单位,事务中包括的诸操作要么都做,要么都不做。

  • 一致性(Consistency):事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

    • 一致性状态:数据库中只包含成功事务提交的结果

    • 不一致状态:数据库系统运行中发生故障,有些事务尚未完成就被迫中断;这些未完成事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态 。

  • 隔离性(Isolation):一个事务的执行不能被其他事务干扰,一个事务内部的操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。

  • 持续性(Durability ):持续性也称永久性(Permanence),一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

10.2 数据库恢复概述

10.3 故障的种类

10.4 恢复的实现技术

10.4.1数据转储

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

10.4.2 登记日志文件

1.日志文件的格式和内容

日志文件(log file)是用来记录事务对数据库的更新操作的文件。

格式:

  • 以记录为单位的日志文件

    • 各个事务的开始标记(BEGIN TRANSACTION)

    • 各个事务的结束标记(COMMIT或ROLLBACK)

    • 各个事务的所有更新操作

就是前面的创建事务,回滚,提交等,会记录在一个日志上。

例:

10.5 恢复策略

这章主要就是考这个

10.5.1 事务故障的恢复

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

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

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

系统故障的恢复步骤:

  1. 正向扫描日志文件(即从头扫描日志文件)
  • 重做(REDO) 队列: 在故障发生前已经提交的事务

    这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录

  • 撤销 (UNDO)队列:故障发生时尚未完成的事务

    这些事务只有BEGIN TRANSACTION记录,无相应的COMMIT记录

  1. 对撤销(UNDO)队列事务进行撤销(UNDO)处理

    • 反向扫描日志文件,对每个撤销事务的更新操作执行逆操作

    • 即将日志记录中“更新前的值”写入数据库

  2. 对重做(REDO)队列事务进行重做(REDO)处理

    • 正向扫描日志文件,对每个重做事务重新执行登记的操作

    • 即将日志记录中“更新后的值”写入数据库

总的原则就是:

  1. 故障发生以前提交的事物,需要重做(因为人家已经提交了,已经对物理数据库实际操作了

  2. 发生以前没提交的,就进行回滚,也就是撤销这些操作

10.5.2 系统故障的恢复

系统故障造成数据库不一致状态的原因

  • 未完成事务对数据库的更新可能已写入数据库。

  • 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。

恢复方法:

  • Undo 故障发生时未完成的事务。

  • Redo 已完成的事务。

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

10.5.3 介质故障的恢复

例题:

总的原则是

  1. 故障发生以前提交的事物,需要重做(因为人家已经提交了,已经对物理数据库实际操作了

  2. 发生以前没提交的,就进行回滚,也就是撤销这些操作

如果系统故障发生在14之后,说明哪些事务需要重做,哪些事务需要回滚;

根据以上原则,可得 重做:T1、T3;回滚:T2、T4。

如果系统故障发生在10之后,说明哪些事务需要重做,哪些事务需要回滚:

                           重做:T1:回滚:T2、T3。

如果系统故障发生在9之后,说明哪些事务需要重做,哪些事务需要回滚:

                           重做:T1;回滚:T2、T3。

如果系统故障发生在7之后,说明哪些事务需要重做,哪些事务需要回滚。

                           重做:T1;回滚:T2

如果系统故障发生在14之后,写出系统恢复后A、B、C的值。
如果系统故障发生在12之后,写出系统恢复后A、B、C的值。
如果系统故障发生在10之后,写出系统恢复后A、B、C的值。
如果系统故障发生在9之后,写出系统恢复后A、B、C的值。
如果系统故障发生在7之后,写出系统恢复后A、B、C的值。
如果系统故障发生在5之后,写出系统恢复后A、B、C的值。

①A=8,B=7,C=11。
②A=10,B=0,C=11
③A=10,B=0,C=11。
④A=10.B=0,C=11
⑤A=10,B=0,C=11。
⑥A=0,B=0,C=0。

如果没有被操作,那么那个数的值就是0。

例题2:

1.如果系统故障只发生在T。,说明哪些事务需要
重做,哪些事务需要撤销。

T5、T7撤销;T3、T4、T6、T8重做
2.如果系统故障只发生在T,说明哪些事务需要
重做,哪些事务需要撤销。

T3、T4重做;T5、T6、T7撤销

该题就是多了一个检查点,检查点之前的事务不用考虑,从检查点之后开始,如果故障之前就完成了,那就重做,如果没完成,那就回滚

10.6 具有检查点的恢复技术

10.7 数据库镜像

出现介质故障时
DBMS自动利用镜像磁盘数据进行数据库的恢复,不
需要关闭系统和重装数据库副本(图b)
没有出现故障时
可用于并发操作(图a)
一个用户对数据加排他锁修改数据
其他用户可以读镜像数据库上的数据

暂无评论

发送评论 编辑评论

|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇