数据库恢复技术

什么是事务？

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

事务如何定义？

1.显式定义：定义事务地语句一般有三条。

     BEGIN TRANSACTION;        //事务的开始

     COMMIT;     //表示提交，即提交事务的所有操作，具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束

     ROLLBACK;     //表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。

2.隐式定义：数据库管理系统按默认规定自动划分事务。（一般是一句一事务）

事务的ACID特性是什么？

   A：原子性：包含的操作要么都做，要么都不做

   C：一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

   I：隔离性：一个事务的执行不能被其他事务所干扰。即一个事务的内部操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

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

破坏事务ACID特性的因素有哪些？

1. 多个事务并行运行时，不同事务的操作交叉执行：数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原子性；
2. 事务在运行过程中被强行终止：数据库管理系统必须保证被强行终止的事务对数据库和其他事务没有任何影响。

什么是数据库的恢复？

数据库管理系统具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致性状态或完整状态）的功能。

当系统发生故障时进行数据库的恢复，那么有哪些故障呢？

1. 事务内部的故障。

1. 可预期的：可以通过事务程序本身发现并处理
2. 不可预期的

            eg：运算溢出、并发事务发生死锁而被选中撤销该事务。违反了某些完整性限制而被终止。

     恢复策略：（DBMS自动完成）进行事务撤销（UNDO操作）

1. 反向扫描日志文件，查找该事务的更新操作。
2. 对该事务的操作进行逆操作
3. 继续反向扫描日志文件
4. 如此处理下去，直到读到此事务的开始标记

2. 系统故障：常称为软故障，指造成系统停止运转的任何事件，使得系统要重新启动。

eg：特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误、系统断电等。

恢复策略：DBMS在重新启动时自动完成。

1. 系统故障时，一些尚未完成的事务的结果可能已经送入物理数据库，从而使数据库处于不正确的状态。在系统重新启动时让所有非正常终止的事务回滚，强行撤销所有未完成事务（UNDO操作）。
2. 有些已完成的事务可能一部分甚至全部留在缓冲区，尚未写回磁盘上的物理数据库中，重做（REDO操作）所有已提交的事务。

 具体做法

1. 正向扫描日志文件，设置两个队列：撤销队列(UNDO)、重做队列（REDO）。通过一次正向扫描，将故障发生前已经提交的事务（既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识加入操作队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录），将其事务标识记录计入撤销队列。找到事务的BEGIN TRANSACTION记录，加入撤销队列，继续正向扫描，遇到相应事务的COMMIT操作，将该事务从撤销队列中移出，加入重做队列。
2. 反向扫描日志文件，对撤销队列的各个事务做撤销（UNDO）处理
3. 正向扫描日志文件，对重做队列中的各个事务进行重做（REDO）处理

3. 介质故障：常称为硬故障，指外存故障、磁盘上的物理数据和日志文件被破坏。

eg:磁盘损坏、磁头碰撞。瞬时强磁场干扰等。

恢复策略：需要数据库管理员介入

1. 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到一致性状态。对于动态转储的数据库副本，还需同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法，才能使数据库恢复到一致性的状态。
2. 装入相应的日志文件副本。（转储结束时刻的日志文件副本），重做已完成的事务。即首先扫描日志文件，找出故障发生时已提交的事务的标识，将其计入重做队列，然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。

4.计算机病毒

恢复技术的基本原理——建立冗余

   关键问题：如何建立冗余数据？

数据转储和登记日志文件。

如何进行数据转储？

数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备用的数据称为后备副本或后援副本。

1. 静态转储：在系统中无运行事务时进行转储操作。

结果：转储得到的一定是一个数据一致性的副本。

2. 动态转储：转储期间允许对数据库进行存取或修改，即转储和用户事务可以并发执行。

结果：转储得到的并不是一个数据一致性的副本，因此必须把转储期间各事务对数据库的操作登记下来，建立日志文件。

                 这样，后援副本+日志文件=把数据库恢复到某一时刻的正确状态。

3. 海量转储：每次转储全部数据库。

4. 增量转储：只转储上一次转储后更新的数据。

转储方式	转储状态
	静态转储	动态转储
海量转储	静态海量转储	动态海量转储
增量转储	静态增量转储	动态增量转储

 

日志文件是什么？

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

日志文件是如何记录的？

1. 以记录为单位的日志文件

要登记的内容有：

各个事务的开始（BEGIN TRANSACTION）标记

各个事务的结束（COMMIT或ROLLBACK）标记

各个事务的所有更新操作

   以上均作为日志文件中的一个日志记录，每个日志记录主要内容包括：

1. 事务标识（标明是哪个事务）
2. 操作的类型（插入、删除或修改）
3. 操作对象（记录内部标识）
4. 更新前的旧值（对插入操作而言此项为空值）
5. 更新后的新值（对删除操作而言此项为空值）

2. 以数据块为单位的日志文件

日志记录的内容：

事务标识和被更新的数据块。（由于将更新前后的数据块都放入日志文件中，操作类型和操作对象等信息就不必放入日志记录中了）

登记日志文件的两条原则：

1. 登记的次序严格按并发事务执行的时间次序
2. 必须先写日志文件，后写数据库

日志文件的作用是什么？

进行事务故障恢复和系统故障恢复，并协助后备副本进行介质故障恢复。

解决系统故障时，要从日志文件的开始处进行扫描，因此会重复大量没有必要的REDO操作。为了解决这种问题，提出了具有检查点的恢复技术：（主要解决系统故障）

检查点是如何建立的？

1. 在日志文件中增加检查点记录

检查点记录的内容：

（1）建立检查点时刻所有正在执行的事务清单。

（2）这些事务最近一个日志记录的地址。

2. 增加重新开始文件

重新开始文件用来记录各个检查点记录在日志文件中的地址，如图说明了建立检查点Ci时对应的日志文件和重新开始文件。

恢复子系统在登录日志文件期间动态地维护日志：方法是周期性执行建立检查点、保存数据库状态的操作。具体步骤：

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

如何利用检查点恢复技术进行系统故障恢复

系统使用检查点方法进行恢复的步骤是：

1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。

2.由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST,这里建立两个事务队列：

UNDO-LIST：需要执行UNDO操作的事务集合

REDO-LIST: 需要执行REDO操作的事务集合

把ACTIVE-LIST暂时放入UNDO-LIST队列

3. 从检查点开始正向扫描日志文件。

1. 如果有新开始的事务Ti,把Ti暂时放入UNDO-LIST队列
2. 如果有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列，直到日志文件结束。

4. 对UNDO-LIST队列中的每个事务执行UNDO操作，对REDO-LIST中的每个事务执行REDO操作

举个例子

系统出现故障时，恢复子系统将根据事务的不同状态采取不同的恢复策略：

T1:在检查点之前提交。不用REDO

T2：在检查点之前开始执行，在检查点之后故障点之前提交，REDO

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

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

T5:在检查点之后开始执行，在故障点时未提交，UNDO

什么是数据库镜像？

DBMS自动把整个数据库或其中的关键数据复制到另一个磁盘上，每当主数据库更新时，DBMS自动把更新后的数据复制过去，由数据库管理系统自动保证镜像数据与主数据的一致性。

为什么要提出数据库镜像？

介质故障是对系统影响最为严重的一种故障，严重影响数据库的可用性。为了提高数据库可用性，提出了数据库镜像技术

数据库镜像有哪些作用？

1.一旦出现介质故障，可用镜像磁盘继续提供使用，同时数据库管理系统自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。

 2. 在没有出现故障时，数据库镜像还可以用于并发操作，即当一个用户对数据加排他锁修改数据时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。

数据镜像存在的问题

频繁的复制数据会降低系统运行效率，因此在实际应用中用户往往只选择对关键数据和日志文件进行镜像，而不是对整个数据库进行镜像。