【数据库基础09】数据库恢复技术

Bigdataxy

已于 2023-02-14 20:40:56 修改

阅读量856

点赞数

分类专栏：数据库基础文章标签：数据库 sql mysql

于 2023-02-14 11:20:15 首次发布

本文链接：https://blog.csdn.net/qq_53271322/article/details/129011044

版权

数据库基础专栏收录该内容

11 篇文章 1 订阅

订阅专栏

系列文章目录

第一章数据库系统绪论
第二章关系数据库
第三章关系数据库标准语言SQL
第四章数据库安全性
第五章数据库完整性
第六章关系数据理论—规范化
第七章数据库设计
第八章关系查询处理和查询优化
第九章数据库恢复技术
第十章并发控制

前言

事务是一系列的数据库操作，是数据库应用程序的基本逻辑单元。事务处理技术主要包括数据库恢复技术和并发控制技术。数据库恢复机制和并发控制机制是数据库管理系统的重要组成部分。

一、事务的基本概念

1.事务

事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。在SQL中，定义事务的语句一般有三条：

begin transaction;
commit;
rollback;

事务通常是以begin transaction开始，以commit或rollback结束。commit表示提交，即提交事务的所有操作，具体地说就是将事务中所有对数据库的更新写回磁盘上的物理数据库中去，事务正常结束。rollback表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。

二、事物的ACID特性

事务具有4个特性：原子性、一致性、隔离性和持续性。这4个特性简称为ACID特性。

原子性
事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性
事务执行的结果必须是使数据库从一个一致性变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。
隔离性
一个事务的执行，不能被其他事务干扰。
持续性
持续性也称永久性，指一个事务一旦提交，它对数据库中数据的改变就应该是永久的。

三、故障的种类

数据库系统中可能发生各种各样的故障，大致可以分一下几类。

事务内部的故障
事务内部的故障有的是可以通过事务程序本身发现的（如下面的转账事务），有的是非预期的，不能由事务程序处理。
例如，

begin transaction
	读账户甲的余额balance
	balance=balance-amount；/*Amount 为转账金额*/
	if(balance<0)then
		{打印‘金额不足，不能转账’； /*事务内部可能造成事务被回滚的情况*/
		rollback；}  /*撤销刚才的修改，恢复事务*/
	else
		{读账户已的余额balance
		balance1=balance1+amount；
		写回balance1；
		commit；}

事务内部更多的故障是非预期的，是不能由应用程序处理的。事务故障仅指这类非预期的故障。

事务故障意味着事务没有达到预期的终点（commit或者显式的rollback），因此，数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚该事务，即撤销该事务已经作出的任何对数据库的修改，使得该事务好像根本没有启动一样，这类恢复操作称为事务撤销。

系统故障
系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。
介质故障
系统故障长称为软故障，介质故障称为硬故障。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。
计算机病毒
各类故障对数据库的影响有两种可能性，一是数据库本身被破坏；二是数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。恢复的基本原理为：冗余。

四、恢复的实现技术

建立冗余数据最常用的技术是数据转储和登记日志文件。

1.数据转储

静态转储是在系统中运行事务时进行的转储操作，停机维护。动态转储是指转储期间允许对数据库进行存取或修改，不停机更新。

必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件。

转储还可以分为海量转储和增量转储两种方式。海量转储是指每次转储全部数据库，增量转储则指每次只转储上一次转储后更新过的数据。

数据转储方式可以分为4类：动态海量转储、动态增量转储、静态海量转储和静态增量转储。

2.登录日志文件

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

每个人日志记录的内容主要内容主要包括：

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

为保证数据库是可恢复的，登录日志文件时必须遵循两条原则：

登记的次序严格按并发事务执行的时间次序。
必须先写日志文件，后写数据库。Q：为什么？

A：写日志文件和修改数据库是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成一个。如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。如果先写日志文件，但是没有修改数据库，可通过日志文件进行恢复，并不会影响数据库的正确性。这就是“先写日志文件”的原则。

五、恢复策略

当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某一个一致性状态。

1. 事务故障的恢复

事务故障是指事务在运行至正常终点前被终止，这时恢复子系统应利用日志文件撤销（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤是：

反向扫描日志文件（扫描完当前整个事务），查找该事务的更新操作。
对该事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。
继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
直至读到此事务的开始标记。

2.系统故障恢复

系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新可能已写入数据库，二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。因此恢复操作就是要撤销故障发生时未完成的事务，重做已完成的事务。系统的恢复步骤是：

正向扫描日志文件（从头扫描日志文件），找出在故障发生前已经提交的事务（这些事务既有begin transaction记录，也有commit记录），将其事务标记计入重做队列（redo list，更新操作还在缓冲区，需要重做）。同时找出故障发生时尚未完成的事务（这些事务只有begin transaction记录，无相应的commit记录），将其事务标识记入撤销队列（undo list）。
对撤销队列中的各个事务进行撤销（undo）处理。
对重做队列中的各个事务进行重做（redo）处理。