昨天在帮助一个客户检查他的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%.