SQL Server如何截断(Truncate)和收缩(Shrink)事务日志

当SQL Server截断事务日志时，它仅仅是在虚拟日志文件中作个标记，以便再也不使用它，而后准备以重用形式来作备份(假如运载在完整或是批量日志恢复模型)。也就是说，在使用简单恢复模型时，事务日志包括以下的日志记录： 

 当checkpoint发生时，虚拟日志文件一、2再也不被使用，由于事务一、2已经被提交了，并且日志记录也再也不须要回滚了。而后SQL Server重用虚拟日志文件一、2，以下图： 

这就是咱们所熟知的事务日志截断。基本上，事务日志的活动区间已经被截断了，可是事务日志的物理大小不会改变，除非数据库使用自动收缩的属性设置。在这种状况下，事务日志就会尽量的在物理上进行周期性的收缩。  

为了物理上减少事务日志的大小，收缩事务日志做为已知的方法，你在使用时能够选择下面选项中的一种：

• 执行 DBCC SHRINKDATABASE命令
• 执行 DBCC SHRINKFILE命令
• 设置数据库的事务日志自动收缩选项

须要注意的是，事务日志仅仅能收缩到虚拟日志文件的边界。下面是个例子。

我新建了一个数据库，它有1MB的事务日志空间，5MB的自动增加空间。运行DBCC LOGINFO显示以下：

  

 这里有四个可变大小的虚拟日志文件。而后我输入一些数据，这会使事务日志 增加到5MB：

  

 在新的5MB事务日志区间里面新建了4个新的虚拟日志文件。每个新建的虚拟日志文件都是1310720bytes，每7个虚拟日志文件正在使用时(状态是2)。我如今备份事务日志，所以将会截断事务日志：   

目前仅仅有一个虚拟日志文件在使用(第7行，状态为2). 假如我如今用下面的命令，试着把日志收缩到2M：

DBCC SHRINKFILE ('AdventureWorks_log', 2)

由于活动日志记录是虚拟日志文件7，因此SQL Server仅仅删除虚拟日志文件8。此次事务日志从7MB收缩到4.7MB. SQL Server也在事务日志中新建了假的入口，为了移除2MB点以前的最近活动日志记录，以便于它包裹到虚拟日志文件2（注意状态为2的行）。 

假如如今再次备份事务日志的话，事务日志会再次被截断，如今活动区间就是虚拟日志文件2了。

   

若是我如今再尝试一次收缩文件的话，SQL Server则会成功的收缩到2MB左右，由于日志的活动区间已经接近2MB了。文件被收缩到最接近于日志登记时的大小。这时DBCC LOGINFO的输出以下： 

 

事务日志文件大小为2359296bytes(虚拟日志文件大小总量要加上8192字节的头信息)

因此若是你发现你不能收缩事务日志到一个指定的范围，运行DBCC LOGINFO，而后检查虚拟日志文件的范围，弄清楚每个日志的大小，你能把文件收缩到什么范围。