数据库恢复技术

数据库恢复技术

---恢复内容开始---数据库恢复技术事务：是⽤户定义的⼀个数据库操作序列，这些操作要么全做，要么全不做，是⼀个不可分割的⼯作单位。事物的 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 协助后备副本进⾏介质故障恢复利⽤静态转储副本和⽇志⽂件进⾏恢复