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

  • 时间:
  • 浏览:0
  • 来源:幸运飞艇_幸运飞艇官方

前言

知道了意味 就好办了。

但两种客户如此 采用replication和mirroring,什么都有我初步锁定大问题是可能性长事务的运行意味 。按照常规的最好的法律法律依据,我只需分析下两种事务不是遇到阻塞、死锁等情况汇报,但会 给出对应的处理方案即可。(但实际情况汇报暂且如此 )

总结

起初我需用通过sp_droppublication来全版删除架构设计 订阅的配置,但无法通过sp_helppublication获取到@publication的名字(提示:命令已执行完!),但会 这条路走不通了。

                                                                                           图二

                                                  图三

遇到两种大问题,我最直接的感受:肯定有大的事务有有1个多劲在执行,意味 日志备份无法截断事务日志的大小。

DBCC loginfo()

显然,我的判断错了,可不可不可以看多,目前【log_reuse_wait_desc】的情况汇报为【REPLICATION】。也只要说正是事务日志架构设计 意味 日志文件不断增大的意味 。

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

这表明那先 日志文件虽然也有 活动情况汇报,一般而言,意味 两种大问题的意味 主要有两种生活:长事务的运行、replication和mirroring延迟。

正如前文分析的,两种数据库并如此 用作发布订阅,杂办 会出显两种情况汇报呢?

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

方案

                                          图一

但这次我碰到的大问题虽然比较诡异,其处理最好的法律法律依据也是我第一次使用。

DBCC SHRINKFILE(Logfilename)

今天不是遇到了有有1个多罕见的案例。

在网上找些资料,发现了sp_removedbreplication两种存储过程,执行后再去收缩日志文件,大问题果然处理!

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

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

大问题

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

经与客户沟通,了解两种数据库虽然是从有有1个多发布订阅的数据库中还原过来的,尽管新的数据库并如此 采用发布订阅,但数据库中发布订阅的其他配置选项还在,从而意味 了数据库的误判,致使日志文件不断增大。

分析

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

EXEC sp_removedbreplication dbname

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

从图一的红色框可不可不可以看多,数据库的多个VLF的情况汇报都为2,也只要active情况汇报。(可能性为0 ,表示为inactive)。