数据库的恢复模式

最新推荐文章于 2023-10-06 20:41:01 发布

cncz1234

最新推荐文章于 2023-10-06 20:41:01 发布

阅读量312

点赞数

文章标签：数据库运维

数据库的恢复模式

更改数据库的恢复模式方法如下

三种恢复模式的描述如下：

简单恢复模式(Simple Recovery Mode)

在简单恢复模式下，日志仅仅是为了保证SQL Server事务的ACID。并没有恢复数据的功能.

比如，我们有一个备份计划，如下:

我们在每周一0点做一次完整备份，在周三0点和周五0点分别做差异备份。在简单恢复模式下，如果周六数据库崩溃。我们的恢复计划只有根据周一0点的做的完整备份恢复后，再利用周五0点的差异备份进行恢复.而周五0点之后到服务器崩溃期间所有的数据将会丢失。

正如”简单”这个词所涵盖的意思，在简单恢复模式下，日志可以完全不用管理。而备份和恢复完全依赖于我们自己的完整和差异备份.

恢复模式是一个数据库级别的参数，可以通过在SSMS里或通过SQL语句进行配置:

简单恢复模式下日志的空间使用

在本系列文章的第一篇文章提到过，日志文件会划分成多个VLF进行管理，在逻辑上记录是线性的，给每个记录一个顺序的，唯一的LSN。

而在简单恢复模式下,为了保证事务的持久性，那些有可能回滚的数据会被写入日志。这些日志需要被暂时保存在日志以确保在特定条件下事务可以顺利回滚。这就涉及到了一个概念—最小恢复LSN（Minimum Recovery LSN（MinLSN））

MinLsn是在还未结束的事务记录在日志中最小的LSN号,MinLSN是下列三者之一的最小值:

CheckPoint的开始LSN
还未结束的事务在日志的最小LSN
尚未传递给分发数据库的最早的复制事务起点的 LSN.

下图是一个日志的片段：

(图片摘自MSDN）

可以看到，最新的LSN是148，147是CheckPoint,在这个CheckPoint之前事务1已经完成，而事务2还未完成，所以对应的MinLSN应该是事务2的开始，也就是142.

而从MinLSN到日志的逻辑结尾处，则称为活动日志(Active Log)。

而活动日志分布在物理VLF上的关系可以用下图表示:

因此，VLF的状态是源自其上所含有的LSN的状态，可以分为两大类:活动VLF和不活动VLF

而更加细分可以将VLF的状态分为以下四类:

1. 活动(Active) –在VLF 上存储的任意一条LSN是活动的时，则VLF则为活动状态，即使一个200M的VLF只包含了一条LSN，如上图的VLF3

2. 可恢复(Recoverable) – VLF是不活动的，VLF上不包含活动LSN,但还未被截断(truncated)

3. 可重用(Reusable) – VLF是不活动的，VLF上不包含活动LSN,已经被截断(truncated)，可以重用

4. 未使用(Unused) – VLF是不活动的,并且还未被使用过

概念如下图:

而所谓的截断(truncated)只是将可恢复状态的VLF转换到可重用状态。在简单恢复模式下，每一次CheckPoint会引发一次截断.而每一次CheckPoint都会将MinLSN向后推.所以当事务结束后并且过了CheckPoint点，其相关的日志将会被截断以便重复利用空间。

在日志达到日志文件(ldf文件）末尾时，也就是上图的VLF8时，会重新循环到VLF1开始，以便让空间进行重复利用.所以日志虽然可以从物理顺序上是从VLF1到VLF8，但逻辑顺序可以是从VLF6开始到VLF2结束:

因此可以看出，简单恢复模式下日志是不保存的（当事务结束后，相关的会被截断）。仅仅是用于保证事务回滚和崩溃恢复的用途.所以备份日志也就无从谈起，更不能利用日志来恢复数据库。

总结

本文介绍了简单恢复模式下日志的原理，并简单的引出了一些备份或者恢复数据的基础。而实际上，除了在开发或测试环境下。使用简单恢复模式的场景并不多，因为在现实生活中，在生产环境允许几个小时的数据丢失的场景几乎没有.下篇文章将会讲述在完整恢复模式下，日志的作用

简介

生产环境下的数据是如果可以写在资产负债表上的话，我想这个资产所占的数额一定不会小。而墨菲定律（事情如果有变坏的可能，无论这种可能性有多小，它总会发生）仿佛是给DBA量身定做的。在上篇文章介绍的

简单恢复模式下，从最近一次备份到当前的数据都会存在丢失的风险。而完整备份模式使得数据丢失的风险大大减少。本文主要介绍在完整备份模式下概念原理和日志所处的角色。

完整(Full)恢复模式

完整恢复模式通过将对数据库的任何修改记录到日志来给予数据最大程度的保护。在完整恢复模式下，日志的作用不仅仅是保证了数据库事务的ACID。并且还可以使数据恢复到在日志范围内的任何时间点。

在上一篇文章中说过，在简单恢复模式下，日志几乎是不用进行管理的。每一次CheckPoint都有可能截断日志，从而来回收不活动的VLF以便重复利用空间。因此在简单恢复模式下，日志的空间使用几乎可以不去考虑。与之相反，在完整恢复模式下，日志作为恢复数据的重要组成部分，日志的管理和对日志空间使用的管理则需要重视。

在完整恢复模式下，CheckPoint不会截断日志。只有对日志的备份才会将MinLSN向后推并截断日志。因此在一个业务量稍大的系统中，日志的增长速度将会变得很快。

因此日志备份的目的分为以下两个:

减少活动日志的大小
减少日志损坏的风险

通过从MSDN中摘自的下图可以看到:

在DB_1处做了完整备份，并且接下来两次分别做了两次日志备份(Log_1和Log_2),在Log_2备份完不久服务器由于数据所在磁盘损坏。这时如果日志文件完好，则可以通过备份尾部日志(Tail of log)后，从DB_1开始恢复，依次恢复Log_1,Log_2,尾部日志来将数据库恢复到灾难发生时的时间点。理论上可以使数据的损失为0。