rhb_blog

rao的博客

0%

数据库_数据库恢复技术

发表于 更新于 分类于 ，

事务的基本概念

参考文章

事务（trancaction）：用户定义的一个数据库操作序列，该序列构成一个独立的、不可分割的逻辑处理任务。要么全做，要么全不做。

一个数据库事务通常包含对数据库进行读或写的一个操作序列。它的存在包含有以下两个目的：

1、为数据库操作提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持一致性的方法。
2、当多个应用程序在并发访问数据库时，可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。

事务的组成

1、一条SQL语句

2、一组SQL语句序列

事务的描述方式

显式

1
2
3
4
BEGIN TRANSACTION
	update...
	insert...
COMMIT 或者ROLLBACK

其中：

COMMIT：提交。事务对数据库的所有修改操作写回到磁盘上的数据库文件中。

ROLLBACK：回滚。撤销所有已实施的对数据库的修改，数据库回滚到事务开始状态。

隐式

一条SQL语句，例如execDirect（）。

程序隐式定义，例如会话结束、程序对象关闭时其中隐藏的COMMIT/ROLLBACK。

事务的ACID性质

并非任意的对数据库的操作序列都是数据库事务。事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

原子性（Atomicity）

定义：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。

目标：保证数据库中数据的正确性

技术：

  • 日志+COMMIT/ROLLBACK（UNDO）；
  • 并发控制（交叉执行）。

一致性（Consistency）

定义：事务应确保数据库（DB）的状态从一个一致（正确）状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。

目标：保证数据库中数据的正确性（有效、相容，防止对数据的更新结果被丢失、读到无效的数据、读到不一致的数据）。

技术：

  • 并发控制（保护临界资源）

隔离性（Isolation）

定义：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。

目标：防止事务之间由于相互干扰而出现并发错误、链式夭折。

技术

  • 并发控制

原子性与隔离行

一致性与原子性是密切相关的,原子性的破坏可能导致数据库的不一致，数据的一致性问题并不都和原子性有关。
比如刚刚的例子，在第五步的时候，对B账户做加法时只加了50元。那么该过程可以符合原子性，但是数据的一致性就出现了问题。

因此，事务的原子性与一致性缺一不可。

持久性（Durability）

定义：一个事务一旦提交，他对数据库的修改应该永久保存在数据库中。

目标：保证数据库的可靠性

技术：

（事务终止前应完成commit）

  • 提交的持久化（内存是挥发性存储装置，外存是非挥发性存储装置）。
  • 备份+日志。（外存）

数据库系统故障分类

数据库系统故障种类

  • 事务故障
  • 系统故障
  • 介质故障
  • 计算机病毒

事务故障

1、表现形式：

  • 应用处理异常
    • 可能产生自程序预留的异常情况的应对方案。
    • 可能来自于非预期的、不能由应用程序处理的故障
      • 断网
      • 应用程序进程僵死
      • 应用程序进行被意外杀死
      • 应用程序端电脑死机、断电
  • 系统异常
    • 事务超时、死锁、活锁等【为避免过久占用资源、DBMS系统按照事先设定的系统参数强行终止事务。】

2、特征：

  1. 特定的事务没有到达预期的终点（COMMIT），事务夭折；
  2. 夭折事务对数据库的部分修改可能已写入数据文件。
    （数据库可能因此处于不正确、不一致状态）

系统故障

1、表现形式

  • 某些类型的硬件故障
    • CPU、内存、主板。。。
      【服务器上的硬件，其故障影响到DBMS系统的正常运行，但不涉及外存储设备】
  • 系统软件故障
    • DBMS：ORACLE、SQL SERVER、MYSQL、DB2。。。
    • OS：UNIX、WINDOWS、LINUX。。。
    • 死机、蓝屏、意外重启、某系统功能意外退出
    • 服务器上的系统软件，其故障影响到DBMS系统的正常运行，但不涉及外存储设备。
  • 系统操作失误
    • 非正常关机\重启、强行终止系统进程、意外卸载相关系统运行环境。。。
  • 系统异常断电
    • 重启之后系统未发现数据库的存储文件错误或者磁盘错误。

2、特征

  • 内存数据丢失或不再可靠
  • 外存数据未受到破坏
  • 一些尚未完成事务的更新结果可能已写入数据库存储介质
  • 已完成事务的更新结果可能部分还未写入数据库（数据文件，也可能正处于提交过程中）
  • 已完成事务的结果可能全部未写入数据库（例如正在等待检查点）
    数据库的数据存储介质依旧可靠，但是数据处于不正确或不一致状态

介质故障

1、表现形式

  • 磁盘故障
    • 磁盘损坏（磁道、扇区、分区、文件分配信息）
    • 磁盘读写装置损坏（磁头、电机）
  • 外界干扰
    • 强磁场干扰（磁性数据被清洗），灾害

2、特征

硬故障，外存中数据的部分或全部丢失，数据相关存储文件本身异常。
（目前比较成熟的DBMS软件一般能够在服务启动时校验存储介质上的数据文件是否异常）

计算机病毒

1、表现形式

  • 消耗资源
    • 内存、磁盘、网络端口，破坏系统的正常运行
  • 泄露信息
    • 系统信息、数据库信息
  • 篡改数据
  • 篡改程序
    • 植入木马、埋下隐患

2、特征

计算机病毒是一种人为造成的技术故障或破坏，含有非法或者恶意企图，在执行某个功能时启动病毒代码，可能造成对数据库系统的危害

系统不再可靠、可信

各类故障对数据库的影响

  • 数据本身被破坏

    需要去寻找可用的数据，重建数据库状态

  • 数据可能不正确（事务的运行被恶意干扰或非正常终止）
    需要截至系统的容错机制，恢复数据的正确性

    不同的故障影响的范围不同，采取的恢复策略也不同
    自动、人工启动、借助外部资源

恢复的基本原理：冗余

数据库备份和日志

数据转储

一般由数据库管理员制定计划，定期的将数据库内容复制到磁带、磁盘或者其他存储介质上保存起来，成为后备副本或后援副本。

转储需要考虑的问题：耗费时间和资源，不宜频繁进行。

转储状态

静态转储

数据库系统中无事务运行时进行转储。

①特征：转储期间不对数据库进行任何联机事务操作。一定得到一个数据一致性付本。

②优点——简单

③ 缺点：停止一切事务运行；降低数据库的可用性

动态转储

转储与事务同时（并发）执行。

①特征：转储期间可对数据库进行读写操作。

②优点：不用等待正在运行的事务结束，也不影响新事务的运行。

③缺点：获得一致性副本比较麻烦。
解决思路：把转储期间各事务对数据库的修改活动登记下来——日志文件

转储方式

海量备份

① 方法：将数据库的全部数据转储。

② 优点：简单——备份简单，恢复简单

③ 缺点：重复执行全部数据的转储动作
转储量大；
停止运行（多为静态转储）。

增量备份

① 方法：每次转储上次转储后更新过的数据。

② 优点：备份量小。

③ 缺点：恢复过程相对复杂。

登记日志文件

在数据库系统中，数据文件也是一种设备，里面的数据是资源，也有类似的需求，相应的有日志文件及其维护机制。

日志——数据库恢复子系统“自己的数据”。

日志文件及其类型

日志文件的概念

记录事务对数据库的更新操作的文件称之为日志文件。

日志文件类型

①记录为单位的日志文件

②数据块为单位的日志文件

以记录为单位的日志文件内容

①事务开始标记（一个日志记录，Begin Transaction）；

②事务结束标记（一个日志记录，Commit，或者Rollback）；

③每个事务的所有更新操作（每个操作一个日志记录）。

每个日志记录内容：

1）事务标识（TRID）；
2）操作类型；
3）操作对象；
4）更新前数据旧值；
5）更新后数据新值。

以数据块为单位的日志文件内容

事务标识+数据块

①数据块（整块）更新前内容；

②数据块更新后内容。

日志文件的作用

1）事务恢复
2）数据库故障恢复
3）系统分析

日志文件的登记

为保证数据库的恢复能正确进行，日志文件的登记必须遵循两条原则：
1）按事务操作执行时间顺序登记日志（多个事务操作并发）
如实记录数据库的状态变化过程，从而保障恢复时能按照逻辑顺序定位到相应的状态。

2）须先写日志文件，后写数据库文件！！！！！
（先写日志协议——WAL）

日志包含了状态变化过程的与事务相关的完整信息，数据块则未必。因此，恢复的依据必须首先是日志。若先写数据文件之后日志文件因故障未能写出，则无法判断相关数据块在恢复时应该采取的动作。

故障恢复策略

事务故障恢复：UNDO

系统故障恢复：REDO+UNDO

介质故障恢复：装入后备副本+REDO

恢复的背景需求

1）文件管理系统和数据库管理系统都有备份与恢复技术

文件管理系统
Ghost、副本文件、操作系统补丁更新时的备份、平台提供的备份软件（例如：手机和电脑数据云备份）

数据库管理系统
转储备份+日志、镜像、逻辑备份（数据导出）

2）恢复的需求存在差异

文件管理系统
恢复到某个版本或某个时间点、恢复某个文件集合【数据的正确性一般由应用程序或人工判断】

数据库管理系统
以数据库为单位，恢复到某个时刻的数据库正确状态【数据的正确性由DBMS判断】

3）数据库恢复的任务

将因破坏或故障而导致的数据库数据的错误状态恢复到最近一个正确状态。

4）目标

①保持事务原子性（Atomicity）
②保持事务持久性（Durability）

5）恢复的数据基础

当前可用的数据文件——当前可看到的正确以及错误的数据
转储的数据文件——转储时可以看到的正确以及错误的数据
日志——用于分析可看到的数据的错误以及看不到的正确数据

事务故障的恢复【事务在运行至正常终点前被终止】

——因各种异常或错误导致事务未执行完而夭折时的恢复。

此时，数据库管理系统正常运行，数据文件和日志文件均未损坏；可能存在其他并发执行的事务，这些事务不受影响。

1）目标：维护原子性

2）动作特征：执行已有操作的“逆向”操作，称为撤销，或者undo。

3）恢复步骤

① 反向扫描日志文件（从日志文件尾向文件头）：
——查找事务执行过最后一条更新操作记录；

② 执行上述找到的最后一条日志记录的UNDO操作【插入→删除，删除→插入，修改前的值→修改后】；

③ 循环执行上述扫描及undo操作，直至事务开始标记。

4）执行方式DBMS自动完成

系统故障的恢复【系统终止造成数据库不一致状态】

——撤消故障发生时未完成事务和重做已完成事务的恢复。

此时，数据文件和日志文件均未损坏，但数据库管理系统出现异常，可能存在多个并发执行的事务，一些已提交事务的日志已写到日志文件，但最新数据却有可能遗留在数据缓冲区。

1）目标：原子性、持久性

2）动作特征：未完成事务已有操作需落实其逆向操作，称为撤销，或者undo；已完成事务需落实其全部操作动作，确保其原子性、持久性，称为“重做”，或者redo。

3）步骤

①正向扫描日志文件（从日志文件头向文件尾）：

  • 找出故障发生前已提交事务，该事务标识记入REDO队列；
    【有BEGIN TRANSANCTION和COMMIT的加入REDO队列】

  • 找出故障发生时未完成事务，该事务标识记入UNDO队列；
    【只有BEGIN TRANSANCTION没有COMMIT的加入UNDO队列】

②执行undo和redo操作

  • 依照日志记录反向顺序对UNDO队列中事务进行UNDO操作（写入修改前的值）：
    （反向扫描日志文件，执行队列中事务的undo操作）；

  • 依照日志记录正向顺序对REDO队列中事务进行REDO操作（写入修改后的值）：
    （正向扫描日志文件，执行队列中事务的redo操作）。

4）执行方式：一般是DBMS重启后自动完成。

介质故障的恢复【需要DBA介入】

——数据库文件和日志文件被破环时的恢复。

数据库管理系统发现数据文件或日志文件读写异常，系统无法正常运行，并且依靠重启也无法恢复到正确状态。

此时，需要以往转储的后备副本数据，以及相应的日志文件（包括归档日志文件和联机日志文件）。
如果联机日志文件损坏，则有可能丢失数据。

1）目标：原子性、持久性

2）动作特征：寻找、装载副本；未完成事务已有操作需落实其逆向操作，undo；已完成事务需落实其全部动作，确保其持久化，redo。

3）恢复步骤

①装入后备数据副本（一般选择最新的转储副本）

②运用与后备数据副本配套的归档日志
采用系统故障的恢复方法，通过归档日志中的事务的redo和undo操作，将数据恢复到和转储副本配套的数据库正确状态。

③运用后期的归档日志和联机日志副本
依次装入日志文件，正向扫描日志，直至日志文件尾，建立UNDO和REDO队列，按照系统故障的恢复动作，执行两个队列的redo和undo操作。

4）执行方式：人工介入、通过恢复子系统完成。

检查点技术

产生原因

利用日志恢复系统故障的过程需要扫描全部的日志记录，进行相关的恢复操作，因而较大的日志文件将带来大量的日志扫描和恢复操作。

Undo——为了确保夭折事务的更新影响不生效，逻辑上可看作一种撤销操作。

DBMS缓存中的数据会因为内外存交换机制写出到磁盘，不一致的数据必须物理上更新回正确状态，undo恢复是唯一能够执行此类撤销操作的系统机制。

Redo——为了确保已提交事务的更新的持久性。

事务提交时它所更新的数据可能仍在缓存中，缓存数据不具备持久化状态，此时，日志的redo功能可以看做其持久性的保障，所以需要先写日志协议。

如果数据存在不违背先写日志的前提下，及时的被写出到磁盘文件，结果会怎样？

许多需要redo的事务的数据更新结果（后像数据）已被写入磁盘文件中，对其redo只是重复的将数据再次设置为后像的值，没有必要。

可以将这一思想用于恢复的优化

优化机制——定期的在不违背先写日志的前提下，将缓存中的数据写出到磁盘文件——检查点（checkpoint）。【周期性、先写日志、缓存写出、记录优化完成】

优化了redo任务，undo的相关开销是否减少？

检查点机制

生成检查点的时机——周期性

①时间周期；

②日志记录周期（日志文件写满或者到达一定数量）。

两个“增加”：

（1）在日志中增加一类记录（检查点记录）

​ 检查点记录内容：

​ ① 建立检查点时刻所有正在执行的（active）事务清单；

​ ②上述事务的最早一条日志记录的地址。

（2）增设重新开始文件。
用来记录各个检查点记录在日志文件中的地址。

检查点动作

——保存数据库状态，建立检查点。

1）将当前日志缓冲区中的所有日志记录写入磁盘的日志文件；

2）在日志文件中写入一个检查点记录；

3）把当前数据缓冲区的所有数据写入磁盘数据文件；

4）在重新开始文件中记录检查点记录的地址。

使用检查点的恢复技术

恢复子系统可以定期或不定期地建立检查点,保存数据库状态

  1. 定期：按照预定的一个时间间隔，如每隔一小时建立一个检查点
  2. 不定期：按照某种规则，如日志文件已写满一半建立一个检查点

T1：在检查点之前提交

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

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

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

T5：在检查点之后开始执行，在故障点时还未完成

采用检查点的恢复步骤

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

2）由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST

  1. 建立两个事务队列
    • UNDO-LIST
    • REDO-LIST
  2. 把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。

3）从检查点开始正向扫描日志文件，直到日志文件结束

  1. 如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列
  2. 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列

4）以检查点记载的最早日志记录和日志文件末尾为界

  1. 对UNDO-LIST中的每个事务执行UNDO操作
  2. 对REDO-LIST中的每个事务执行REDO操作

问题回答

1、为什么需要检查点？

  • 搜索整个日志文件需要耗费的时间很多
  • 重做处理，重新执行，耗费了大量的时间

2、解决方案是什么？

  • 在日志文件中增加检查点（check point）记录

  • 增加重新开始文件

  • 恢复子系统在登录日志文件期间动态的维护日志

3、检查点记录的内容有哪些？

  • 建立检查点时刻，所有正在执行的事务清单
  • 这些事务最近一个日志记录的地址

4、重新开始文件的内容有哪些？

  • 记录各个检查点记录在日志文件中的地址

结论

事务是数据库的逻辑工作单位

DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性

DBMS必须对事务故障、系统故障和介质故障进行恢复
恢复中最经常使用的技术：数据库转储和登记日志文件
恢复的基本原理：利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库
常用恢复技术
事务故障的恢复（UNDO）
系统故障的恢复（UNDO + REDO）
介质故障的恢复（重装备份并恢复到一致性状态 + REDO）
提高恢复效率的技术
检查点技术（
Ø可以提高系统故障的恢复效率
Ø可以在一定程度上提高利用动态转储备份进行介质故障恢复的效率
）