USE mydb GO BACKUP LOG mydb WITH TRUNCATE_ONLY GO DBCC SHRINKFILE(mydb_log,8) GO
哪个工作正常,缩小到8MB …但有问题的数据库是一个Log Shipping Publisher,日志已经回升到大约500MB并且增长很快.
除了创建自定义“执行T-sql语句任务”维护计划任务以及将其挂钩到我的日志备份任务之外,有没有办法自动化这个日志缩小?如果这是最好的方式那么好……但我只是认为sql Server会有更好的方法来解决这个问题.我认为它应该在您进行日志备份时自动缩小,但这种情况不会发生(可能是因为我的日志传送,我不知道).
这是我目前的备份计划:
>每晚完整备份
>交易日志备份每天一次,上午晚些时候(也许挂钩日志缩小到这个……不过每天都不需要缩小)
或者也许我在运行完整备份任务后每周运行一次?你们都觉得怎么样?
解决方法
>您在正常操作期间点击文件增长零填充初始化,从而降低性能
>您的日志以较小的增量增长,从而创建了许多虚拟日志文件,从而导致较差的运营性能
>缩小期间,您的日志会碎片化.虽然没有数据文件碎片那么糟糕,但日志文件碎片仍会影响性能
>有一天,每天500MB的增长将耗尽磁盘空间,你希望该文件是预先生成的
你不必接受我的话,你可以在一些MVP博客上阅读他们对日志和文件缩减的做法的定期说明:
> Auto-shrink – turn it OFF!
> Oh,the horror! Please stop telling people they should shrink their log files!
> Why you want to be restrictive with shrink of database files
> Don’t Touch that Shrink Button!
> Do not truncate your ldf files!
还有更多,我只是厌倦了链接它们.
每次缩小日志文件时,仙女都会失去翅膀.