当一切正常时，没有必要特别留意什么是事务日志，它是如何工作的。你只要确保每个 数据库都有正确的备份。当出现问题时，事务日志的理解对于采取修正操作是重要的，尤其在需要紧急恢复数据库到指定点时。这系列文章会告诉你每个DBA应该知道的具体细节。

?

它不会经常提起，除非你的数据库运行在简单（SIMPLE）恢复模式，在事务日志上定期备份非常重要的。这会控制事务日志大小，并且保证，在灾难发生里，你可以恢复你的数据库到灾难发生前的某个时间点。这些日志备份要和定期的完整数据库（数据文件）备份一起。

?

如果你在测试数据库上工作，不需要恢复到先前的某个时间点，或者会乐意恢复到上次完整备份，那你就可以在简单模式里运行数据库。

?

我们来详细讨论下这些问题。

?

备份的重要性

?

考虑下，例如SQL Server数据库“崩溃”的情况里，可能是硬件故障，“活生生”的数据文件（mdf和ndf文件），和事务日志文件都不能访问了。

?

最坏的情况，其它地方不存在这些文件备份（副本），那你会遭受100%的数据丢失。为了保证你能恢复数据库，且数据恢复到服务器崩溃前存在的某个时间点，或者恢复到数据因为其他原因丢失或损坏前，DBA需要同时为数据和日志文件做定期备份。

?

DBA可以进行3个主要类型的备份（但是当在简单（SIMPLE）恢复模式时只有前2个可以应用）

?

完整数据库备份——在数据库里备份所有的数据。对提供的数据库，这本质是制作MDF文件副本。

?

差异数据库备份——自上次备份后，制作已改变的任何数据的副本。

?

事务日志备份——自上次事务日志备份，制作插入到事务日志的所有日志记录的副本（如果在简单（SIMPLE）恢复模式里，是数据库检查点）。当日志备份完成时，通常日志被截断，这样的话文件里的空间可以被重用，但是一些因素可以延迟这个（看第8篇——救命，我的日志满了。）

?

一些初级的DBA和很多开发者，可能会被“完整”误解，误认为完整备份备份“一切”；数据和事务日志内容同时备份。这是不对的。本质上，完整和差异备份同时只备份数据，尽管它们也备份足够的事务日志来启用备份数据的恢复，当数据库在备份时，重现任何改变。但是，实际上，完整数据库备份不备份事务日志，也不会导致事务日志的截断。只有事务日志备份会造成日志的截断，因此在生产环境里，进行日志备份是唯一控制日志文件大小的正确方法。在第8篇——救命，我的日志满了会讨论一些常见但不正确的方式。

?

文件和文件组备份

大的数据库有时会由多个文件组组织，是可以在各个文件组、或文件组里的文件上进行完整和差异备份，而不是备份整个数据库。对此以后在以后的文章里不会详谈。

?

恢复模式

?

SQL Server数据库备份和恢复操作发生在数据库恢复模式的上下文里。恢复模式是决定你是否需要（或甚至可以）备份事务日志和操作如何记录的数据库属性。对于可用恢复操作，还有页粒度和文件恢复都有一些不同，但这个系列文章不会讨论这些。

?

一般来说，数据库会运行在简单和完整恢复模式，它们之间的重用区别如下：

?

简单（SIMPLE）——事务日志只用作数据库恢复和回滚操作。在检查点期间是自动截断。它不会被备份，因此它不能用于还原数据库到过去存在的某个时间点。

?

完整（FULL）——事务日志在检查点期间不会自动截断，因此可以被备份并用来还原数据到先前的某个时间点，也用作数据库恢复和回滚。只有当日志备份发生时，日志文件会截断。

?

还有第3个模式，大容量日志（BULK_LOGGED），在这个特定操作里，通常会生成很多写入到事务日志，为了不淹没事务日志而进行很少的记录。

?

不能最小记录的操作

?

可以被最小记录的操作包括大容量导入操作（例如使用BCP或BULK INSERT），SELECT/INTO操作和特定索引操作（例如索引重建）。

?

选择正确的恢复模式

?

在完整恢复模式和简单恢复模式之间选择的最重要标准是：你愿意冒丢失多少数据的风险？

?

在简单恢复模式里，只有完整和差异备份。比方说你完全依赖完整备份，在每天早上2点进行完整备份，有一天服务器在早上1点的时候服务器经历了一次致命的崩溃。在这个情况里，你只能恢复前一个早上2点的完整数据库备份，会丢失23个小时的数据。

?

在完整备份之间可以进行差异备份，来减少数据丢失的风险。所有的备份都有密集的I/O流程，对于完整备份更是名副其实，其次是差异备份。他们很可能影响数据库的性能，当用户们正在访问数据库时不应该运行。实际上，如果你运行在简单恢复模式，数据丢失的风险是几个小时。

?

如果数据库存放关键业务数据，你会更喜欢数据丢失是几分钟而不是几个小时，那样的话你需要运行数据库在完整恢复模式。在这个模式里，你需要进行一次完整数据备份，然后是一系列定期的事务日志备份，再又是另一个完整备份，这样反复进行。

?

在这个情况下，理论上你可以恢复最近的可靠完整备份（加上最近的差异备份，如果有的话），接下来是可用日志备份链，自上次完整或差异备份后。然后，在恢复过程中，在备份日志里的所有记录的操作会前滚，将数据库恢复到非常接近于灾难时间。

?

日志文件备份的频率多少会再次取决于你准备丢失的数据，加上你服务器上的工作量。在重要的金融或会计应用上，对于数据丢失的容忍几乎为零，那样的话你可以每15分钟备份一次日志，甚至可以更高频率。在刚才的备份例子里，意味着你可以恢复上午2点的完整备份，然后按顺序应用每个日志文件备份，假设你有自用作数据库恢复基础的完整备份，有完整扩展的日志链（log chain）到上午12点45分，刚好在数据库崩溃前15分钟。事实上，崩溃后当前的日志还是可以访问的，允许你进行尾日志备份（tail log backup），你可以最小化你的数据丢失接近为0。

?

日志链和尾日志备份……

会在第5篇——完整恢复模式里的日志管理里详细介绍。

?

当然，使用完整备份会带来更多的维护，创建和监控用来频繁运行事务日志备份的作业，这些都要额外工作，这些备份需要I/O资源（尽管只是短时间），需要磁盘空间来存储大数量的备份文件。对数据库选择合适的恢复模式前，在业务层面，这些都要慎重考虑这些。

?

设置和切换恢复模式

?

恢复模式可以使用下列简单的命令进行设置。

?

?1 USE master;

?2?

?3 -- set recovery model to FULL

?4 ALTER DATABASE TestDB

?5 SET RECOVERY FULL;

?6?

?7 -- set recovery model to SIMPLE

?8 ALTER DATABASE TestDB

?9 SET RECOVERY SIMPLE;

10?

11 -- set recovery model to BULK_LOGGED

12 ALTER DATABASE TestDB

13 SET RECOVERY BULK_LOGGED;

?