SQL日志文件不断增长案例

sql日志文件不断增长案例
 

前言

今天算是遇到了一个罕见的案例。
sql日志文件不断增长的各种实例不用多说，园子里有很多牛人有过介绍，如果我再阐述这些陈谷子芝麻，想必已会被无数次吐槽。
但这次我碰到的问题确实比较诡异，其解决方式也是我第一次使用。
下文将为各位看管详细介绍我的解决思路。

现象

一客户反馈的日志文件不断增长，已分配的磁盘空间快使用完，尝试过事务日志截断（事务日志备份）的操作，但没有任何效果。

分析

遇到这个问题，我最直接的感受：肯定有大的事务一直在执行，导致日志备份无法截断事务日志的大小。
首先，我在该数据库下运行dbcc loginfo()

  图一
从图一的红色框可以看到，数据库的多个vlf的状态都为2，也就是active状态。（如果为0 ，表示为inactive）。
这表明这些日志文件确实都在活动状态，一般而言，导致这种现象的原因主要有三种：长事务的运行、replication和mirroring延迟。
但这个客户没有采用replication和mirroring，所以我初步锁定问题是因为长事务的运行导致。按照常规的方法，我只需分析下这个事务是否遇到阻塞、死锁等情况，然后给出对应的解决方案即可。（但实际情况并非如此）
为保险起见，我运行如下语句来验证下我的判断：
select log_reuse_wait_desc, * from sys.databases where name=’dbname’
  图二

显然，我的判断错了，可以看到，目前【log_reuse_wait_desc】的状态为【replication】。也就是说正是事务日志分发导致日志文件不断增大的原因。
正如前文分析的，这个数据库并没有用作发布订阅，怎么会出现这个状态呢？
经与客户沟通，了解这个数据库其实是从一个发布订阅的数据库中还原过来的，尽管新的数据库并没有采用发布订阅，但数据库中发布订阅的一些配置选项还在，从而导致了数据库的误判，致使日志文件不断增大。

方案

知道了原因就好办了。
起初我想通过sp_droppublication来完全删除分发订阅的配置，但无法通过sp_helppublication获取到@publication的名字（提示：命令已执行完！），因此这条路走不通了。
在网上找些资料，发现了sp_removedbreplication这个存储过程，执行后再去收缩日志文件，问题果然解决！
exec sp_removedbreplication dbname
dbcc shrinkfile(logfilename)
dbcc loginfo()

  图三

总结

尽管本文的场景比较少见，但总体解决的思路与其他（日志文件不断增长）其实是一样的。少许地方不太明白可以通过网络等一些工具获得。这也说明了sql原理的重要性，借用一本书的序言中的一句话【越接触本质越不会迷茫！】。多接触原理，很多东西都是触类旁通的。