日志真没想象的那么简单

发布时间：2011-03-21 16:10 来源：未知

【51CTO精选译文】凡是接触过SQL Server的人现在应该都知道，事务日志（transaction log）是任何SQL Server数据库的一个重要组成部分。谈论日志是我个人偏爱的话题之一，单单介绍日志方面通常存在的一些误解会是长篇大论，岂止这篇短文涵盖得了。

在过去的两年里，我曾在无数次大会上作过名为《简单恢复到底有多简单？》的报告，今年5月在加拿大蒙特利尔举行的DevTeach / SQLTeach大会上我还会做同样的报告。虽然我无法在此介绍所有详细内容，也无法介绍日志的组织、日志为何会扩大或缩小，以及截断日志到底是什么意思，但可以基本回答“简单恢复到底有多简单”这个问题。简单恢复的简单之处在于你的备份策略。你没必要为每隔多久进行日志备份而操心，因为无法进行日志备份。

简单恢复并不意味着SQL Server不用日志功能了。这是个非常普遍的误解，也是个普遍的要求——许多用户想要以某种方法来运行SQL Server，又不用负担日志开销，因而想知道允许这么做的特殊而秘密的跟踪标志（trace flag）。实际上，没有所谓的不生成日志的操作，即无日志操作，尽管人们可能需要这样子。SQL Server至少需要把关于你操作的足够多的信息记入日志，以便正常运行过程中系统突然出现故障的话，可以撤消（或回滚）一切。

虽然SQL Server没有执行无日志操作的可能性，不过倒是有最小日志（minimal logging）这样的操作。不过我发现，最小日志中到底哪些信息被记入日志并没有得到一个很明确的定义。SQL Server联机丛书（BOL）描述了一组最小日志操作，表示“最小日志记录的仅仅是在不支持及时点恢复的情况下，恢复事务所需要的信息。”这个定义意味着最小日志必须记录足够多的信息，以便恢复或前滚事务，即使每一单独的数据行变更并没有按时间顺序记入日志。然而，其他定义表明最小日志只够回滚事务。

简单恢复是三种恢复模式之一，而这三种模式之间的差异恰恰决定了如何管理日志。假如你在BOL中读到关于恢复模式的部分，它不但列出了可以最小日志的一系列操作，还写到那些操作只是在大批量日志（BULK_LOGGED）和简单（SIMPLE）恢复模式下才是最小日志的；而在完全（FULL）恢复模式下，操作都是完全日志的。但我找不到哪里有完整的定义表明“完全日志”是什么意思。我过去以为完全日志意味着，每一个单独的行都写入到日志中，就好像你执行了一组单独的插入（INSERT）、更新（UPDATE）或删除（DELETE）操作。但对某些操作来说，事实并非如此。

当一个可以最小日志的操作在完全恢复模式下在数据库里面执行时，写入到事务日志的并不是每一个单独的行，而是操作期间被修改的每一页。所以，假如你在完全恢复模式下在数据库里面执行大批量插入（BULK INSERT）操作时，由于每一页塞满了新的行，该页写入到日志中，而这条日志记录的大小将是8192个字节大小（与SQL Server的页大小相同）。假如你在完全恢复模式下在数据库里面构建或重构索引，SQL Server并不会把生成的每一个单独的索引行记入到日志。而是一旦整个索引页生成，就把它们记入到日志。 

从空间和时间方面来看，把整个页记入日志其实要比把每一个单独的行记入日志高效得多。但只针对被认为是最小日志操作的那些操作才这么做。所以，我认为那些操作进行完全日志与单独的数据修改操作进行完全日志不是一个概念。

所以，有一组操作我们可以称之为最小日志操作。点击这里：http://msdn.microsoft.com/en-us/library/ms191244(v=SQL.100).aspx，可以参阅这些操作的完整列表。这些操作之所以很特别，就在于它们在每一种恢复模式下日志方式各不相同。在完全恢复模式下，每一个完整的被修改页写入到日志；在大批量日志恢复模式和简单恢复模式下，SQL Server只是把关于被修改页的信息记入日志，而不是将页里面的内容本身记入日志。其他操作是真正的完全日志——不管你在哪种恢复模式下，它们含有每一个变更行的全部详细信息，包括含有操作的事务、操作执行时间以及受到影响的页。

恢复模式是为SQL Server 2000产品添加的一项很棒的特性，但任何一种恢复模式根本就不简单。你对于SQL Server如何管理事务日志了解得越深入，就能做出越明智的决定，确定哪一种恢复模式适合自己。 

原文链接：http://www.sqlmag.com/article/log-files3/How-Simple-Is-Logging-.aspx