Why my SQL transaction log grows so large and my disk doesn't have enough space.

昨天在帮助一个客户检查他的SQL Server数据库整体情况。发现都还好,除了日子文件特别大,46G,而磁盘也就48G左右。如果日子文件因为空间不够而不能再增长了,那数据库就停止了。情况比较紧急。

 

按照常规步骤:

1. dbcc sqlperf(database name), 密度很高,居然是100%  看来是真的满了。

2. dbcc opentran 无返回。说明没有开着的transaction.

3. backup log <database name> with truncate_only, 报错,因为日志已满无法操作。

4. 客户反映2周之前做过全备份。这个客户还是比较敬业的,能够及时做备份。但备份后,没有把日志truncate过.

5. 再次检查日志文件设置,发现初始大小居然是46G,难过涨得这么大。即使要shrink,也是不可能减少到46G以下的。

 

客户同意把日志移动到另一个磁盘。我就先把数据库take offline,然后再detach下来(这是最快的方法),把日志复制到另一个磁盘上,最后attach成功,数据库重现online了。这时,但我再次用backup log <database name> with truncate_only后,检查dbcc sqlperf(database name),密度奇迹般的降低到了0.5%. 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值