数据库恢复技术

数据库恢复技术

重点：掌握事务的概念，理解数据库恢复实现技术。
1．事务的概念与四个特性
2．故障的种类（事务故障、系统与介质故障）
3．恢复的实现技术（数据转储、登记日志文件，日志及日志的作用）
4. 针对三类不同故障的实现策略
数据库恢复技术
事务：是数据库最先的逻辑工作单元，它可以包括一条或多条语句，也可以有一个或多个程序，一般情况下，一个程序包含多个事务。
事务的定义

begin transaction

commit
//正常结束
begin transaction

rollback

事务异常终止

事物的特性
原子性：事务是数据库的逻辑工作单元，内部的诸多程序要不全部执行，否则就不执行
一致性：事务的执行结果使数据库从一个一致性状态变到另一个一致性状态
隔离性：一个事务的执行不能被其他的事物干扰，事务内部的操作及使用对其他事务来说是隔离的，并行执行的事务不能互相干扰
持续性：事务执行的结果对数据库是永久性的
DBMS提供数据库恢复的子系统
数据库恢复：把数据库从某一错误状态恢复到某一已知的正确状态

数据库故障的种类

1.事物内部的故障：某个正在运行的事务没有执行完就结束啦，它分为可预期的，非预期的，事务故障是指非预期的故障
可预期的事物内部故障数据库自己就可以处理
非预期举例：输入数据错误 数据溢出 并发事务发生死锁 违反某些完整性规则
事务故障的恢复：撤销事务undo 在不影响其他事务运行的情况下，强行回滚rollback事务

2.系统故障：系统停止运转使正在进行的事务异常终止，只会使内存缓冲区内的数据丢失，不会对外部存储设备上的数据造成影响
原因：特定类型的硬件错误 操作系统故障 系统断电 DBMS代码错误
系统故障的恢复：（1）发生故障时事务未提交，强行撤销所有未完成的事务（undo）（2）发生故障时事务已提交，但缓冲区中的信息还没有完全写入磁盘，重做所有已提交的事务 （redo）

3.介质故障：磁盘损坏 磁头碰撞 操作系统某种潜在的错误 瞬时强磁场干扰
利用副本恢复数据，重做建立副本之后的操作
4. 计算机病毒，人为恶意 装入发生故障前的副本

恢复实现的技术
恢复操作的基本原理就是冗余
利用数据库中其他地方存在的冗余数据来重建数据库已经被破坏或者不正确的地方
冗余数据来源：数据转储 登录日志文件
数据转储就是DBA将数据库写入磁带或者另一个磁盘上，备用的数据称为后备副本或者后援副本
当时数据库发生故障时将后备副本重新装入，利用数据转储只能将数据库恢复到数据库转储时的状态

转储的方法
静态转储：转储使不能进行其他操作
动态转储：允许修改，但是不能保证数据正确，需要转储期间的日志文件，两者结合才能保证恢复到某一正确状态
海量转储：每次全部转储
增量转储：只转储上次转储后修改的数据

登记日志文件
日志文件：记录事务对数据库更新操作的文件
内容：各事物的开始标记，结束标记，各事物的所有更新操作
事务故障恢复，系统故障恢复必须用到日志文件
动态转储的后备副本进行介质故障恢复必须用到日志文件
静态转储后的后备副本的介质故障回复，也可以用到日志文件
必须要先写日志文件，然后再写入数据库，为什么？
因为写日志文件和写入数据库是两个不同的操作，这两个操作之间可能会发生故障，
如果先写入数据库，如果发生故障，而日志文件并没有记录，那么就会产生错误的信息
如果先写入日志文件，发生故障，只是会对日志文件进行一次UNDO操作，并不会影响数据库的正确性

事务故障的恢复
由恢复子系统利用日志文件撤销（undo）对此事务对数据库的修改，对用户透明，系统自己执行
步骤：
1.反向扫描日志文件
2.对该事务的更新操作执行逆操作，插入变删除，删除变插入，以前的之替换修改后的值
3.直到读到该事务的开始标记

系统故障的恢复
系统故障有前面说的两种情况
：首先就是事务没有执行完，没有到达commit或者rollback，撤销已经做到的修改，这种用undo
还有就是已经完成的事务可能一部分或者全部都在缓冲区，还没有写到数据库中，然后这些就重新把结果写入数据库，用redo
系统自己执行，不用用户干预
步骤
1.正向扫描日志文件，得到两个队列
redo队列：已经提交的事务
undo队列：尚未完成的事务
2.对UNDO队列进行undo处理：反向扫描日志文件，对每个undo事务的更新执行逆操作
3.对redo队列进行redo处理：正向扫描日志文件，对每一个reodo事务重新进行登记的操作

介质故障的处理
利用数据库后备副本和日志文件进行恢复
需要DBA的介入，具体操作仍有DBMS执行
DBA的任务
重装最近的转储地数据库副本和有关的日志文件的副本，执行系统提供的恢复命令
恢复步骤
1.转入最近转储的数据库副本，然后使数据库恢复到最近一次转储时的一致性状态
对于静态转储装入副本之后就是一致性状态，对于动态转储需要转储时刻的日志文件副本
2.重做已经完成的事务
首先正向扫描日志文件，找出故障发生时已提交事务的标识，将其计入重做队列
然后正向扫描日志文件，对重做队列中的所有事务进行重做处理

数据库镜像
利用数据库镜像就是把数据自动的复制到另一个磁盘中，保持和元数据的一致性，一旦介质出现故障，那么就可以由数据库镜像继续提供使用，不需要关闭系统和重装副本，镜像还可以用于并行操作。

并发控制
重点：并发控制概述，死锁和活锁，并发调度的可串行性
并发控制概述（并发带来的三个不一致性）
封锁机制如何解决三类不一致问题；死锁、活锁问题及其解决的方法
并发调度的可串行性（什么是可串行化调度，冲突操作，冲突可串行化调度）
两段锁协议
单处理机：事务串行执行 单处理机：交叉并发执行 多处理机：同时并发执行
读脏数据：读写冲突 A修改了数据，然后B读取了修改后的数据，但是由于某种原因A撤销了对数据的修改，B读到的数据就是脏数据
丢失修改：写写冲突 A B同时读取统一数据，然后同时做了修改。他们中的一个修改会被覆盖掉
不可重复读：读写冲突 有三种情况
1.B读取某些记录 然后A对记录进行了修改，当B再次读取记录的时候，数据不相同
2.B读取某些记录，A删除了部分记录，B再次读取发现部分记录不存在
3.B读取某些记录，A添加了部分记录，B再次读取发现记录变多
并发操作破坏了事物的隔离性

并发控制的主要技术
封锁
时间戳
乐观控制

封锁：就是事务T对某个数据对象操作之前，先向系统发出请求，对其加锁。加锁之后的事务对该数据对象有了一定的控制，在事务T释放它的锁之前，其他的事务不能更新此数据对象。
排他锁：写锁 若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他事务不能对A施加任何锁，直到T释放A上的锁为止
共享锁：读锁 若事务T对数据对象A加上S锁，则事务T只能对A读而不能更新，其他事务只能随A加S锁，不能加X锁，直到T释放A上的S锁为止
封锁协议
一级封锁协议：在事务T对数据对象A进行更新时，必须对A加上X锁，直到事务T结束才可以释放 可以解决丢失修改的问题
二级封锁协议：在一级封锁协议的基础上，事务T读取数据前，A要加上S锁，读完数据之后才可以释放 可以解决读脏数据的问题
三级封锁协议：在一级封锁协议的基础上，事务T读取事务前，A要加上S锁，事务结束后才可以释放 可以解决不可重复读
三者的主要区别：什么时候需要加锁，什么时候释放锁

活锁：事务T1对数据对象A请求封锁，事务T2之后也对A请求封锁，但是T2只能等待T1事务结束，与此同时事务T3也对A请求封锁，T3也在等待T1结束，还有T4、T5…但是数据库管理系统在T1释放锁后并没有批准T2的申请，而是批准T3的申请、接着是T4、T5的申请，导致T2一直在等待，这时候就形成了活锁
解决方案：先来先服务策略，当多个事务同时请求对统一数据对象的封锁时，封锁子系统会按照请求封锁的先后次序对事物进行排队，数据对象上的锁一旦释放就批准申请队列中第一个事务获得锁。

死锁：事务T1正对A进行封锁，然后又请求对B进行封锁，但是B正在被T2封锁，所以事务T1就等待B上的锁被释放，但是事务T2又申请对A进行封锁，但是A正被T1封锁，所以T2也开始等待，T1和T2就一直等待，形成死锁
预防死锁：一次封锁法 顺序封锁法
检测死锁：超时法 等待图法
发生死锁后只需要选择一个代价小的事务撤销，收回其持有的所有锁

多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行执行这些事务的结果相同，称这种调度策略为可串行化调度
可串行性是并发事务正确调度的准则
冲突操作：读写操作 写写操作
不同事物的冲突操作、同一事物的两个操作是不可以交换的
冲突可串行化调度：一个调度Sc在保证不改变冲突操作次序的情况下，冲过交换两个事务不冲突的部分，得到一个新的调度Sz，如果Sz是可串行化调度，那么称调度Sc是冲突可串行化的调度。如果一个调度是冲突可串行化的调度，那么他一定是可串行化调度，但是反过来不一定成立。

create schema "S-T" authorization wang;
//不输入模式名默认为用户名
drop schema S-T cascade;//级联删除
restrict //限制删除
//列级完整性规则 非空not null 主码primary key 唯一unique 缺省值 check取值约束
//表级完整性规则
//模式与表
create table "S-T".SC();
create schema 中可以接受 create table create view grant 字句
create schema test authorization zhang create table TA()；