每个 SQL Server 数据库都具有事务日志，用于记录所有事务以及每个事务对数据库所做的修改。 必须定期截断事务日志以避免它被填满。 但是，一些因素可能延迟日志截断，因此监视日志大小很重要。 某些操作可以最小日志量进行记录以减少其对事务日志大小的影响。

事务日志是数据库的重要组件，如果系统出现故障，则可能需要使用事务日志将数据库恢复到一致状态。 删除或移动事务日志以前，必须完全了解此操作带来的后果。

事务日志支持以下操作：

? 恢复个别的事务。

? 在 SQL Server 启动时恢复所有未完成的事务。

? 将还原的数据库、文件、文件组或页前滚至故障点。

? 支持事务复制。

? 支持高可用性和灾难恢复解决方案：AlwaysOn 可用性组、数据库镜像和日志传送。

=======================================================================

事务日志截断

日志截断将释放日志文件的空间，以便由事务日志重新使用。 日志截断主要用于阻止日志填充。 日志截断可从 SQL Server 数据库的逻辑事务日志中删除不活动的虚拟日志文件，释放逻辑日志中的空间以便物理事务日志重用这些空间。 如果事务日志从不截断，它最终将填满分配给物理日志文件的所有磁盘空间。

为了避免这个问题，除非由于某些原因延迟日志截断，否则 将在以下事件后自动进行截断：

? 简单恢复模式下，在检查点之后发生。将数据库恢复模式配置为简单模式。

? 在完整恢复模式或大容量日志恢复模式下，如果自上一次备份后生成检查点，则在 日志备份后进行截断 （除非是仅复制日志备份）。

在备份数据库的时候可以选择进行日志备份，如图。（注意日志备份的前提是已经进行过数据库的完整备份）。

注意下图的截断事物日志选项只有在进行事物日志备份的时候才可用，如果进行完整或差异备份，则不能选择该选项。

例如：在使用DPM备份SQL server的时候，如果进行完整备份，则不会截断日志，但是如果使用完整+事物日志的备份方式就可以截断事物日志。

为何要使用大容量恢复模式

在完整恢复模式下，所有大容量操作都将被完整地记录下来。 但是，可以通过将数据库暂时切换到用于大容量操作的大容量日志恢复模式，最小化一组大容量操作的日志记录。 最小日志记录比完整日志记录更为有效，并在大容量事务期间，降低了大规模大容量操作填满可用的事务日志空间的可能性。 不过，如果在最小日志记录生效时数据库损坏或丢失，则无法将数据库恢复到故障点。

监控日志空间的使用

可以使用 DBCC SQLPERF (LOGSPACE) 监视日志空间使用情况。如图。

=======================================================================

收缩事务日志文件的大小

收缩日志文件可删除一个或多个不包含逻辑日志任何部分的虚拟日志文件（即“不活动的虚拟日志文件”）。 在收缩事务日志文件时，将从日志文件的末端删除足够的不活动虚拟日志文件，以便将日志减小到接近目标大小。

如图。

然后选择要收缩的文件类型为日志文件。如图。

=======================================================================

日志回绕

事务日志是一种回绕的文件。例如，假设有一个数据库，它包含一个分成四个虚拟日志文件的物理日志文件。当创建数据库时，逻辑日志文件从物理日志文件的始端开始。新日志记录被添加到逻辑日志的末端，然后向物理日志的末端扩张。日志截断将释放记录全部在最小恢复日志序列号 (MinLSN) 之前出现的所有虚拟日志。“MinLSN”是成功进行数据库范围内回滚所需的最早日志记录的日志序列号。示例数据库中的事务日志的外观与下图所示相似。

分为四个虚拟日志文件的日志文件

当逻辑日志的末端到达物理日志文件的末端时，新的日志记录将回绕到物理日志文件的始端。

日志记录回绕到日志文件的开头

这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端。如果经常截断旧的日志记录，始终为到下一个检查点前创建的所有新日志记录保留足够的空间，则日志永远不会填满。

参考链接：

事务日志物理体系结构

http://msdn.microsoft.com/zh-cn/windows/hardware/ms179355(v=sql.110).aspx

逻辑日志与事务日志

事务日志记录了所有事务以及每个事务对数据库所做的修改，用于确保数据库的数据完整性以及用于数据恢复，(后面这个是个人理解)由于记录的主体对象是事务相关的日志，所以就叫事务日志。

而逻辑日志只是事务日志的一部分。这是因为事务日志是以一种回绕文件的方式记录的，具体的你可以看下这个图(摘自“事务日志物理体系结构”)

http://i.msdn.microsoft.com/ms179355.656f4617-f295-4e17-b5c7-d6d3318d4051(zh-cn,SQL.100).gif

虚拟日志文件

对于一个或多个连续的物理日志文件，SQL SERVER在这些文件的内部又划分成了多个小的文件，称为虚拟日志文件，他是日志文件收缩和日志截断的最小单位，比如物理日志文件是400M，内部划分了4个100M的虚拟文件，收缩时你得到的是300M，200M，不可能得到239M，对于一个物理文件，会划分成多少个虚拟文件，这个由SQL自己维护，唯一可以人工干预的是指定较大的物理日志文件，并指定较大的增长比例，这样可能虚拟文件的块头会大点，数量会少点，系统的维护开销会低一点。

截断事务日志

截断是对SQL逻辑日志的一个清除过程，清除非活动的逻辑事务日志。可以想象断点应该是活动与非活动的边界处--MinLSN，他会将MinLSN前面的这段日志清除掉,逻辑日志的起点也会指向断点MinLSN处，清除出来的空间并不会返还给操作系统，而是被标识为非活动的虚拟日志文件，他表示当有新的日志记录进来时，这些空间可以被再次利用，所以截断日志并不会减小物理日志文件的大小，只是清理了里面的一些内容，以便新的日志记录可以进来，SQL总是以循环链表的方式使用物理日志文件的，当逻辑日志增长到物理日志文件的尽头时，他会循环到日志文件的首部搜索被截断而释放出来的空间，如果这个时候没有空间的话，说明物理日志已经用完了，就得增加物理日志的大小，如果磁盘也用尽了，系统就会返回一个错误提示。

参考： https://forum.eviloctal.com/thread-22423-1-1.html

=======================================================

2014年6.27日补充

扩充数据库：可以通过预先的监控发现磁盘文件快满的情况，手动进行调整，手动调整的速度比自动增长要快得多；收缩数据库：不建议收缩数据库，会影响I/O性能，不建议在业务繁忙的时间进行，可能会造成新的文件碎片；数据库的整体趋势是增长的，所以收缩的意义不大，除非是特别大的数据库现在变小了；实际上收缩日志文件也是没有什么意义的；

=======================================================