2、为什么日志不能收缩

　　现在我们再来看一个日志无法收缩的场景：

　　图四中，VLF1中的日志不断增加，直到VLF1的所有空间都被填满(如图五)，此时因为没有发生截断，尾日志都在VLF2上，且VLF2和VLF3都被标记为不可重新利用，数据库只能扩充LDF、新建一个VLF4用来记录新的日志，首日志的位置将出现在VLF4中,整个写日志的(从图一到图四)顺序为VLF2——>VLF3——>VLF1——>VLF4。这个过程会导致数据库的日志文件在物理上增大。　　

▲(图五)日志增长示意图　　

　　这时我们再来截断事物日志，如上文所说，尾日志的会被更新，最后可能出现尾日志和首日志在同一个VLF上的场景。从日志文件记录的架构上来看，我们可以将这个过程简单地理解为：截断的顺序会按照首日志移动的顺序移动，从VLF2——>VLF3——>VLF1——>VLF4，最终尾日志和首日志出现在同一个VLF上。

▲(图六)日志截断示意图二　　

　　如上图，这个LDF文件包括3个空的和1个只有小部分活动日志的VLF文件，首日志和尾日志在同一个VLF中，这种情况下，试图通过DBCC SHRINKFILE是不会减小LDF文件的大小的。

　　日志文件能被收缩的原因是该文件尾部的数据被清除了，使得该部分空间被释放，而不是逃过尾部去删除文件首部或者中间部分的内容。这点与MDF文件不同，MDF文件中的数据是不能被删除的，只能将文件尾部的数据迁移到其他区域的剩余空间上，然后释放尾部占用的空间。

　　在LDF中 ，日志是不能被迁移的，而且也没有迁移的必要，因为当事物被提交后，日志变为不活动状态，通过事物日志备份即可将其截断(特殊情况下日志备份不一定能截断，如发布订阅的环境)。

　　综上所述，日志文件能被收缩的前提是：日志文件的最后一个VLF必须是free状态，从后向前推，只要是free状态的VLF都会被收缩，据此可以估算一个日志文件可以释放的空间大小。

　　如下我们看一个实际的例子：

　　USE DBname

　　DBCC loginfo

▲(图七)VLF状态示意图　　

　　从上图可以看到，这个数据库的日志文件共有13个VLF，其中有前12个处于free状态，最后1个处于活动状态，因此，我们可以推断首日志和尾日志的位置都在这个VLF上。这个时候执行文件收缩将看不到文件减小的效果。