SQLServer的日志是DB级别的这点和MySQL不同，多个DB就需要维护多个日志文件并且每个DB的日志文件可以有多个，所以从空间资源的角度来说这给云上的用户带来一些困扰，毕竟在云上磁盘空间是要收费的，除了性能他们也非常关心这些日志何时截断重用、何时收缩
事务日志
在理解事务日志基本概念的基础上我们来做个有关收缩的测试：
--1. 构建测试用的日志 -- tpcc是我的测试DB，ITEM表是之前生成的一个测试表，这里不需要关心表内容 USE [tpcc] GO DECLARE @VALUE INT SET @VALUE = 0 WHILE @VALUE <= 100 BEGIN SELECT * INTO ITEM_2 FROM ITEM DROP TABLE ITEM_2 SET @VALUE = @VALUE + 1 END GO --2. 观察当前等待日志截断重用的原因和每个DB的日志使用量 select log_reuse_wait_desc from sys.databases where name='tpcc' go dbcc sqlperf(logspace) go --3. 备份数据和日志 BACKUP DATABASE TPCC TO DISK='D:\BACKUP\TPCC.BAK' WITH COMPRESSION,INIT BACKUP LOG TPCC TO DISK='D:\BACKUP\TPCC.TRN' WITH COMPRESSION,INIT --4. 再次观察当前等待日志截断重用的原因和每个DB的日志使用量 select log_reuse_wait_desc from sys.databases where name='tpcc' go dbcc sqlperf(logspace) go --5. 收缩日志 USE [tpcc] GO dbcc shrinkfile(log) --6. 查看收缩后的日志使用量 dbcc sqlperf(logspace) go这一步也可以通过上一步收缩的结果计算出来（90112*8K = 704 MB）；
现在在理解基本概念的基础上产生了第一个疑问，为什么1G的日志使用了4%却只能收缩到704MB？
为了解答这个问题我们需要引入另一个概念 Virtual Log Files(VLF)，SQLServer为了方便日志管理，逻辑上将事务日志划分为多个虚拟日志文件，我们要讨论的收缩就是以虚拟日志文件为单位操作的。
具体可以参考日志的结构
我们再来重复一次刚才的测试，这次加入对VLFs的记录观察；
在刚才的1、3、5步骤之后记录如下SQL返回结果，帮助后续分析；
USE [tpcc] GO dbcc loginfo步骤1结束后
步骤3结束后
步骤5结束后
这里跟收缩日志最相关的是Stats字段，0表示inactive，2表示active，active状态的VLF通过checkpoint+日志备份可以转化为inactive，但有一个原则是header（可理解为最新的活动日志）部分只能后推或回绕（wraps around）不能move forward（跟offset相关）；
在开始备份前有11个活动VLF，checkpoint（数据备份的第一阶段）+ 备份日志后只有最新的VLF处于活动状态（日志截断并标记老的VLF为inactive-可重用），收缩后释放掉了未使用的VLF；
截止到这里截断和收缩实际已经达到了充分利用空间的目的，虽然直观看物理文件没有下降多少但新的日志已经开始回绕；但即便如此一些客户还在追求物理文件的进一步减少，实际想达到这个目的也很简单，依据之前讲的header部分已经回绕，再次备份收缩就可以了；
--再次备份 backup database tpcc to disk='d:\backup\tpcc.bak' with compression,init backup log tpcc to disk='d:\backup\tpcc.trn' with compression,init --再次收缩 USE [tpcc] GO dbcc shrinkfile(log) --观察VLF USE [tpcc] GO dbcc loginfo为什么没有收缩最后一个inactive的VLF跟这个DB的日志初始化大小、shrinkfile的参数有关，简单说不回收最后一个VLF已经可以达到初始化的大小；
我们也可以通过VLF的总大小和物理文件对比做一个验证：
--通过FileSize计算要加8KB的页头 67043328+67043328+67043328+67043328+67043328+67043328+67043328+67559424+8192=536870912B=512MB --通过最后一个偏移量算 469311488+67559424=536870912B=512MB