SQL server数据库SQL日志文件不断增长,收缩后日志不变小解决方法

前言

今天算是遇到了一个罕见的案例。

SQL日志文件不断增长的各种实例不用多说,园子里有很多牛人有过介绍,如果我再阐述这些陈谷子芝麻,想必已会被无数次吐槽。

但这次我碰到的问题确实比较诡异,其解决方式也是我第一次使用。

下文将为各位看管详细介绍我的解决思路。

现象

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

分析

遇到这个问题,我最直接的感受:肯定有大的事务一直在执行,导致日志备份无法截断事务日志的大小。

首先,我在该数据库下运行DBCC loginfo()

clip_image002

                                          图一

从图一的红色框可以看到,数据库的多个VLF的状态都为2,也就是active状态。(如果为0 ,表示为inactive)。

这表明这些日志文件确实都在活动状态,一般而言,导致这种现象的原因主要有三种:长事务的运行、replication和mirroring延迟。

但这个客户没有采用replication和mirroring,所以我初步锁定问题是因为长事务的运行导致。按照常规的方法,我只需分析下这个事务是否遇到阻塞、死锁等情况,然后给出对应的解决方案即可。(但实际情况并非如此)

为保险起见,我运行如下语句来验证下我的判断:

SELECT log_reuse_wait_desc, * FROM sys.databases WHERE NAME='dbname'

image                                                                                           图二

显然,我的判断错了,可以看到,目前【log_reuse_wait_desc】的状态为【REPLICATION】。也就是说正是事务日志分发导致日志文件不断增大的原因。

正如前文分析的,这个数据库并没有用作发布订阅,怎么会出现这个状态呢?

经与客户沟通,了解这个数据库其实是从一个发布订阅的数据库中还原过来的,尽管新的数据库并没有采用发布订阅,但数据库中发布订阅的一些配置选项还在,从而导致了数据库的误判,致使日志文件不断增大。

方案

知道了原因就好办了。

起初我想通过sp_droppublication来完全删除分发订阅的配置,但无法通过sp_helppublication获取到@publication的名字(提示:命令已执行完!),因此这条路走不通了。

在网上找些资料,发现了sp_removedbreplication这个存储过程,执行后再去收缩日志文件,问题果然解决!

EXEC sp_removedbreplication dbname

DBCC SHRINKFILE(Logfilename)

DBCC loginfo()

clip_image007

  • 1
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论 1

打赏作者

luozhihuinet2020

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值