文章目录
数据库恢复技术
先上图!!
事务的基本概念
定义:
- 一个数据库操作序列
- 一个不可分割的工作单位(不能之完成一部分,要么全完成,要么都不完成)
- 恢复和并发控制的基本单位
事务和程序比较
- 在关系数据库中,一个事务可以是一条或多条SQL语句,也可以包含一个或多个程序
- 一个程序通常包含多个事务
定义事务(☆)
显示定义方式:
begin transaction
--sql语句一
--语句二
--........
commit
--全部操作完成
BEGIN TRANSACTION
SQL 语句1
SQL 语句2
……
ROLLBACK
–全部操作都取消掉
隐式方式:
- 当用户没有显式地定义事务时,DBMS按缺省规定自动划分事务
COMMIT(操作序列全部执行完成)
- 事务正常结束
- 提交事务的所有操作(读+更新)
- 事务中所有对数据库的更新永久生效
ROLLBACK(操作序列全都不执行)
- 事务异常终止
- 回滚事务的所有更新操作,事务回到开始时的状态
默认情况下,SQL Server采用自动提交方式,即如果没有显示定义事务,则一个SQL语句为一个事务。在查询分析器中执行下列语句,DBMS将理解为 3 个事务:
select * from student
update student
set sdept='IS’
where sno='201215121'
update student
set sdept='CS’
where sno='201215125'
新建查询,执行下面的一组SQL语句,则两个事务
select * from student
begin transaction
update student
set sdept='IS’
where sno=‘202015121'
update student
set sdept='CS’
where sno=‘202015125'
commit
分析下列一段SQL中包括几个事务?运行后对数据产生什么样的影响?
select * from student
begin transaction
update student
set sdept='IS'
where sno='201215121'
update student
set sdept='CS'
where sno='201215125'
rollback
答:两个事务,对数据没有任何影响,因为rollback进行了回滚操作。
事务的特性
(1)原子性
- 事务是数据库的逻辑工作单位。事务中包括的所有操作要么都做,要么都不做。
(2)一致性
- 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。(只要事务的原子性不遭到破坏,就能保证一致性)
(3)隔离性:对并发执行而言一个事务的执行不能被其他事务干扰
- 一个事务内部的操作及使用的数据对其他并发事务是隔离的
- 并发执行的各个事务之间不能互相干扰
(4)持续性也称永久性
- 一个事务一旦提交,它对数据库中数据的改变就应该是永久性的
- 接下来的其他操作或故障不应该对其执行结果有任何影响
数据库恢复概述
数据库管理系统对故障的对策
- DBMS提供恢复子系统
- 保证故障发生后,能把数据库从错误状态恢复到某一已知的正确状态,就是数据库的恢复
- 保证事务ACID
数据库恢复技术是衡量系统优劣的重要指标
数据库恢复机制是数据库管理系统的重要组成部分,占整个系统代码的 百分之十以上
恢复实现技术(☆)
恢复操作的基本原理:
冗余,用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据
恢复机制涉及的关键问题
如何建立冗余数据
- 数据转储(backup)
- 登录日志文件(logging)
如何利用这些冗余数据实施数据库恢复
数据转储
转储
是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程
- 这些备用的数据文本称为后备副本或后援副本
如何使用
- 数据库遭到破坏后可以将后备副本重新装入
- 重装后备副本只能将数据库恢复到转储时的状态
转储方法
按转存状态:
- 静态转储
- 动态转储
按转存方式:
- 海量转储
- 增量转储
静态转储:
- 在系统中无运行事务时进行转储
- 转储开始时数据库处于一致性状态
- 转储期间不允许对数据库的任何存取、修改活动
- 优点:实现简单
- 缺点:降低了数据库的可用性
转储必须等用户事务结束
新的事务必须等转储结束
动态转储:
- 转储操作与用户事务并发进行
- 转储期间允许对数据库进行存取或修改
- 优点
不用等待正在运行的用户事务结束
不会影响新事务的运行 - 缺点
不能保证副本中的数据正确有效
利用动态转储得到的副本进行故障恢复
- 需要把动态转储期间各事务对数据库的修改活动登记下来,建立日志文件
- 后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态
海量转储与增量转储
- 海量转储: 每次转储全部数据库
- 增量转储: 只转储上次转储后更新过的数据
- 海量转储与增量转储比较
从恢复角度看,使用海量转储得到的后备副本进行恢复往往更方便
但如果数据库很大,事务处理又十分频繁,则增量转储方式更实用更有效
恢复实现技术
登录日志文件
日志文件(log)是用来记录事务对数据库的更新操作的文件
日志文件格式:
- 以记录为单位的日志文件
- 以数据块为单位的日志文件
以记录为单位的日志文件内容
- 各个事务的开始标记(BEGIN TRANSACTION)
- 各个事务的结束标记(COMMIT或ROLLBACK)
- 各个事务的所有更新操作
以上均作为日志文件中的一个日志记录 (log record)
分析下面的事务会产生多少条日志记录?
Begin transaction
select * from student where sno='201915121'
Update student
Set sdept='IS'
Where sno='201915121'
select * from student where sno='201915125'
Update student
Set sdept='CS'
Where sno='201915125'
COMMIT
答:4条日志记录(Begin transaction、Update、Update、COMMIT)
以数据块为单位的日志文件,每条日志记录的内容
- 事务标识(标明是那个事务)
- 被更新的数据块
日志文件的作用+
- 进行事务故障恢复
- 进行系统故障恢复
- 协助后备副本进行介质故障恢复
登记日志文件
基本原则
- 登记的次序严格按并行事务执行的时间次序
- 必须先写日志文件,后写数据库
写日志文件操作:把表示这个修改的日志记录写到日志文件
写数据库操作:把对数据的修改写到数据库中
为什么要先写日志文件
- 写数据库和写日志文件是两个不同的操作
- 在这两个操作之间可能发生故障
- 如果先写了数据库修改,而在日志文件中没有登记下这个修改,则以后就无法恢复这个修改了
- 如果先写日志,但没有修改数据库,按日志文件恢复时只不过是多执行一次不必要的UNDO操作,并不会影响数据库的正确性
恢复策略
事务故障的恢复
- 事务故障:事务在运行至正常终止点前被终止
运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制等 - 恢复方法
由恢复子系统应利用日志文件撤消(UNDO)此事务已对数据库进行的修改 - 事务故障的恢复由系统自动完成,对用户是透明的,不需要用户干预
系统故障的恢复
- 系统故障造成数据库不一致状态的原因:
未完成事务对数据库的更新已写入数据库
已提交事务对数据库的更新还留在缓冲区没来得及写入数据库 - 恢复方法
Undo 故障发生时未完成的事务
Redo 已完成的事务 - 系统故障的恢复由系统在重新启动时自动完成,不需要用户干预
介质故障的恢复
-
介质故障:称为硬故障,指外存故障
-
恢复方法
- 重装数据库
使数据库恢复到一致性状态 - 重做已完成的事务
- 重装数据库
-
介质故障的恢复需要DBA介入
DBA的工作:
重装最近转储的数据库副本和有关的各日志文件副本
执行系统提供的恢复命令
具体的恢复操作仍由DBMS完成
例一:
完整备份和还原
假如有三次完整备份
只能选择任意的一个完整数据库备份进行还原
还原到10:00
还原到11:00
还原到12:00
例二:
完整备份+差异备份与还原
如果需要还原到11:00时的数据库状态
- 完整数据库备份1+差异数据库备份2
如果需要还原到12:30时的数据库状态
- 完整数据库备份2+差异数据库备份3
例三:
完整备份+日志备份与还原
如果需要还原到11:00时的数据库状态
- 完整备份1+日志备份1+日志备份2
如果需要还原到12:30时的数据库状态
- 完整备份2+日志备份3
- 完整备份1+日志备份1+日志备份2+日志备份3
如果需要恢复到10:45时的状态
- 完整备份1+日志备份1+日志备份2
(指定到10:45的恢复即时点)