数据库系统⼁数据库常⽤恢复技术
⽂章⽬录
0. 概述
数据库的恢复是指DBMS必须具有把数据库从错误状态恢复到某⼀已知的正确状态(亦称为⼀致状态或完整状态)的功能。尽管数据库系统中采取了各种保护措施来防⽌数据库的安全性和完整性被破坏，保证并发事务的正确执⾏，但是计算机系统中硬件故障、软件错误、操作员失误及恶意破坏仍是不可避免的，这些故障轻则造成运⾏事务⾮正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此DBMS必须具有数据库的恢复功能。
数据库恢复的基本单位是事务。数据库恢复机制包括⼀个数据库恢复⼦系统和⼀套特定的数据结构。
实现可恢复性的基本原理是重复存储数据，即数据冗余。
恢复机制涉及的两个关键问题是:
如何建⽴冗余数据
如何利⽤这些冗余数据实施数据库恢复。
建⽴冗余数据最常⽤的技术是数据转储和登录⽇志⽂件。它们是数据库恢复的基本技术，通常在⼀个数据库系统中，这两种⽅法是⼀起使⽤的。
1. 数据转储
[1] 数据转储的概念
数据转储就是DBA定期地将整个数据库复制到磁带或另⼀个磁盘上保存起来的过程。
这些备⽤的数据⽂本称为后备副本或后援副本。当数据库遭到破坏后可以将后备副本重新装⼈。
但重装后备副本只能将数据库恢复到转储时的状态，要想恢复到故障发⽣时的状态，必须重新运⾏⾃转储以后的所有更新事务。
转储是⼗分耗费时间和资源的，不能频繁进⾏。DBA应该根据数据库使⽤情况确定⼀个适当的转储周期。转储周期可以是⼏⼩时、⼏天，也可以是⼏周、⼏个⽉。
[2] 静态转储和动态转储。
转储按转储时的状态分为静态转储和动态转储。
静态转储
静态转储是在系统中⽆运⾏事务时进⾏的转储操作。即转储操作开始的时刻，数据库处于⼀致性状态,⽽转储期间不允许对数据库的任何存取、修改活动。显然，静态转储得到的⼀定是⼀个数据⼀致性的副本。
静态转储简单，但转储必须等待正在运⾏的⽤户事务结束才能进⾏，同样，新的事务必须等待转储结束才能执⾏。显然，这会降低数据库的可⽤性。
动态转储
动态转储是指转储期间允许对数据库进⾏存取或修改。即转储和⽤户事务可以并发执⾏。
它不⽤等待正在运⾏的⽤户事务结束，必须把转储期间各事务对数据库的修改记下来，建⽴⽇志⽂件(Log File)。这样，后援副本加上⽇志⽂件就能把数据库恢复到某⼀时刻的正确状态。
[3]海量转储和增量转储
转储按⽅式不同分为海量转储和增量转储。
海量转储
海量转储是指每次转储全部数据库。
增量转储
增量转储则指每次只转储上⼀次转储后更新过的数据。
从恢复⾓度看,⼀般说来,⽤海量转储得到的后备副本进⾏恢复会更⽅便些。但如果数据库很⼤，事务处理⼜⼗分频繁，则增量转储⽅式更实⽤、有效。
[4] 数据转储⽅法
数据转储有两种⽅式，分别可以在两种状态下进⾏，因此数据转储⽅法可以分为4类，见下表。
2. 登记⽇志⽂件
⽇志⽂件是⽤来记录事务对数据库的更新操作的⽂件。概括起来,⽇志⽂件主要有两种格式：
以记录为单位的⽇志⽂件
以数据块为单位的⽇志⽂件。
[1] 以记录为单位的⽇志⽂件
⼀个⽇志记录(LogRecord)包括每个事务开始的标记、结束标记和每个更新操作。
[2] 以数据块为单位的⽇志⽂件
包括事务标识和被更新的数据块。
由于将更新前的整个块和更新后的整个块都放⼈⽇志⽂件中，操作的类型和操作对象等信息就不必放⼈⽇
志记录中。
[3] ⽇志⽂件的作⽤
⽇志⽂件在数据库恢复中起着⾮常重要的作⽤。可以⽤来进⾏事务故障恢复和系统故障恢复，并协助后备副本进⾏介质故障恢复。具体的作⽤如下:
①事务故障恢复和系统故障必须⽤⽇志⽂件。
②在动态转储⽅式中必须建⽴⽇志⽂件，后备副本和⽇志⽂件综合起来才能有效地恢复数据库。
③在静态转储⽅式中，也可以建⽴⽇志⽂件。
④当数据库毁坏后可重新装⼈后备副本把数据库恢复到转储结束时刻的正确状态，然后利⽤⽇志⽂件，把已完成的事务进⾏重做处理，对故障发⽣时尚未完成的事务进⾏撤销处理。这样不必重新运⾏那些已完成的事务程序就可把数据库恢复到故障前某⼀时刻的正确状态。
[4] 利⽤⽇志⽂件恢复⽰例图
[5] ”⽇志先写“原则
把对数据的修改写到数据库中与把表⽰这个修改的⽇志记录写到⽇志⽂件中是两个不同的操作。有可能在这两个操作之间发⽣故障，即这两个写操作只完成了⼀个。如果先写了数据库修改,⽽在运⾏记录中没有登记下这个修改，则以后就⽆法恢复这个修改了。如果先写⽇志，但没有修改数据库，按⽇志⽂件恢复时只不过是多执⾏⼀次不必要的撤销(UNDO)操作，并不会影响数据库的正确性。
3. 检查点恢复技术
[1] 两个问题
利⽤⽇志技术进⾏数据库恢复时，恢复⼦系统必须搜索⽇志，确定哪些事务需要REDO(重做)，哪些事务需要UNDO。
⼀般需要检查所有⽇志记录。这样做有两个问题：
⼀是搜索整个⽇志将耗费⼤量的时间；百度数据恢复
⼆是很多需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了，然⽽恢复⼦系统⼜重新执⾏了这些操作，浪费了⼤量时间。
为了解决这些问题,⼈们研究发展了具有检查点的恢复技术。
[2] 检查点
检查点(Check Point)也称安全点、恢复点。当事务正常运⾏时，数据库系统按⼀定的时间间隔设检查点。⼀旦系统需要恢复数据库状态，就可以根据最新的检查点的信息，从检查点开始执⾏，⽽不必从头开始执⾏那些被中断的事务。
具有检查点的恢复技术在⽇志⽂件中增加⼀类新的记录——检查点记录(检查点建⽴时所有正在执⾏的事务清单)，增加⼀个重新开始⽂件(存储各检查点记录的地址)，并让恢复⼦系统在登录⽇志⽂件期间动态地维护⽇志。
系统在检查点做的动作主要如下:
①暂时中⽌现有事务的执⾏。
②在⽇志中写⼈检查点记录，并把⽇志强制写⼈磁盘。
③把主存中被修改的数据缓冲区强制写⼈磁盘。
④重新开始执⾏事务。
[3] ⽰意图
系统出现故障时恢复⼦系统将根据事务的不同状态采取不同的恢复策略，如图所⽰。
4. 数据库镜像
[1] 介质故障
介质故障是对系统影响最为严重的⼀种故障。
系统出现介质故障后,⽤户应⽤全部中断，恢复起来也⽐较费时。故DBA必须周期性地转储数据库，如果不及时⽽正确地转储数据库，⼀旦发⽣介质故障，会造成较⼤的损失。
[2] 数据库镜像
为避免磁盘介质出现故障影响数据库的可⽤性，许多DBMS提供了数据库镜像(Mirror)功能⽤于数据库恢复。其⽅法是DBMS根据DBA的要求，⾃动把整个数据库或其中的关键数据复制到另⼀个磁盘上，并⾃动保证镜像数据与主数据的⼀致性，即每当主数据库更新时，DBMS⾃动把更新后的数据复制过去，如图6-7(a)所⽰。
⼀旦出现介质故障，可由镜像磁盘继续提供使⽤，同时DBMS⾃动利⽤镜像磁盘数据进⾏数据库的恢复，不需要关闭系统和重装数据库副本，如图6-7(b)所⽰。
[3] 双磁盘镜像技术
在没有出现故障时，数据库镜像还可以⽤于并发操作，即当⼀个⽤户对数据加排他锁修改数据时，其他⽤户可以读镜像数据库上的数据，⽽不必等待该⽤户释放锁。
双磁盘镜像技术(MirroredDisk)常⽤于可靠性要求⾼的数据库系统。数据库以双副本的形式存放在2个独⽴的磁盘系统中，每个磁盘系统有各⾃的控制器和CPU，且可以互相⾃动切换。
5. 远程备份系统
[1] 必要性
现代数据库应⽤要求事务处理系统提供⾼可⽤性，即系统不能使⽤和等待的时间必须少之⼜少。传统的事务处理系统是集中式或局域客户/服务器模式。这样的系统易遭受⽕灾、洪⽔和地震等⾃然灾害的毁坏。故要求数据库系统有抗破坏⼒，使之⽆论在系统故障还是⾃然灾害下都能快速恢复运⾏。
[2] 远程备份系统
获得⾼可⽤性的⽅式之⼀是远程备份系统，即在⼀个主站点(Primary Site)执⾏事务处理，使⽤⼀个远程备份(RemoteBackup)站点以应付突发事件。⼀开始所有主站点的数据都被复制到远程备份站点。随着更新在主站点上执⾏，远程站点必须保持与主站点同步。
[3] 同步⽅法
通过发送所有主站点的⽇志记录到远程备份站点，远程备份站点根据⽇志记录执⾏同样的操作来达到同步。
注意不是传送更新的数据本⾝，⽽是传送更新数据的操作命令，这样可⼤⼤减少数据的传送量。
远程备份站点必须物理地与主站点分开放在不同的地区，这样发⽣在主站点的灾害就不会殃及远程备份站点。
[4] ⽰意图
当主站点发⽣故障时，远程备份站点就⽴即接管处理。但它⾸先使⽤源于主站点的数据副本(也许已过
时)以及收到的来⾃主站点的⽇志记录执⾏恢复。事实上，远程备份站点执⾏的恢复动作就是主站点要恢复时需要执⾏的恢复动作。对于单站点的恢复算法稍加修改，就可⽤于远程备份站点的恢复。⼀旦恢复执⾏完成，远程备份站点就开始处理事务。即使主站点的数据全部丢失，系统也能恢复，相对单站点系统⽽⾔，这⼤⼤地提⾼了系统的可⽤性。
[5] 分布式数据库
另⼀种实现⾼可⽤性的⽅法是使⽤分布式数据库，将数据复制到不⽌⼀个站点。此时事务更新任何⼀个数据项，都被要求去更新其所有复制品。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。