你还可以再诡异点吗——SQL日志文件不断增长

  • 时间:
  • 浏览:2
  • 来源:大发5分3DAPP下载_大发5分3DAPP官方

方案

                                          图一

现象

但你你这一 客户那么 采用replication和mirroring,所以我初步锁定现象是可能长事务的运行原困。按照常规的法律最好的方式,我只需分析下你你这一 事务有无遇到阻塞、死锁等情況,或者给出对应的处理方案即可。(但实际情況我太多 那么 )

从图一的红色框都须要看过,数据库的多个VLF的情況都为2,也可是我active情況。(可能为0 ,表示为inactive)。

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

在网上找些资料,发现了sp_removedbreplication你你这一 存储过程,执行后再去收缩日志文件,现象你以为处理!

                                                  图三

尽管本文的场景比较少见,但总体处理的思路与有些(日志文件不断增长)其实是一样的。一定量地方不太明白都须要通过网络等有些工具获得。这也说明了SQL原理的重要性,借用一本书的序言中的说说【越接触本质越我太多 迷茫!】。多接触原理,所以东西一定会触类旁通的。

遇到你你这一 现象,我最直接的感受:肯定有大的事务无缘无故在执行,原困日志备份无法截断事务日志的大小。

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

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

SQL日志文件不断增长的各种实例我太多 多说,园子里有所以牛人有过介绍,可能我再阐述那此陈谷子芝麻,想必已会被无数次吐槽。

显然,我的判断错了,都须要看过,目前【log_reuse_wait_desc】的情況为【REPLICATION】。也可是我说正是事务日志整理原困日志文件不断增大的原困。

总结

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

起初我就要通过sp_droppublication来删剪删除整理订阅的配置,但无法通过sp_helppublication获取到@publication的名字(提示:命令已执行完!),或者这条路走不通了。

正如前文分析的,你你这一 数据库并那么 用作发布订阅,为社 会再次总出 你你这一 情況呢?

                                                                                           图二

下文将为各位看管删剪介绍我的处理思路。

但这次我碰到的现象其实比较诡异,其处理法律最好的方式也是我第一次使用。

这表明那此日志文件其实一定会活动情況,一般而言,原困你你这一 现象的原困主要有四种 :长事务的运行、replication和mirroring延迟。

DBCC SHRINKFILE(Logfilename)

EXEC sp_removedbreplication dbname

今天有无遇到了一三个 多多罕见的案例。

知道了原困就好办了。

DBCC loginfo()

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

分析

前言