我无法弄清楚如何缩小数据库ldf文件的大小.
@H_404_2@DBA说我应该使用
使用truncate_only备份日志dbname @H_404_2@虽然看起来它在SQL查询分析器中正确执行,但ldf文件仍然超过2 Gb. @H_404_2@**澄清基于以下一些评论和一些答案.***有问题的特定数据库是我的笔记本电脑上的数据库,我只将其用于开发过程.日志文件正在增长到导致完整磁盘的程度.不涉及生产风险.我理解我提出的问题中的方法和我接受的答案在生产环境中存在风险.*
使用truncate_only备份日志dbname @H_404_2@虽然看起来它在SQL查询分析器中正确执行,但ldf文件仍然超过2 Gb. @H_404_2@**澄清基于以下一些评论和一些答案.***有问题的特定数据库是我的笔记本电脑上的数据库,我只将其用于开发过程.日志文件正在增长到导致完整磁盘的程度.不涉及生产风险.我理解我提出的问题中的方法和我接受的答案在生产环境中存在风险.*
解决方法
Oh,the horror! Please stop telling people they should shrink their log files!
@H_404_2@如果您已经遇到这种情况,那么下列情况之一极有可能：
@H_404_2@>您的数据库处于完全恢复模式,它应该处于简单模式
>您的数据库处于完全恢复模式,您应该进行常规日志备份
>您的数据库处于完全恢复模式,并且由于某种原因您的日志备份失败
>您正在运行大量巨大的事务,这些事务将日志文件扩展到大规模 @H_404_2@每个答案如下： @H_404_2@如果(1),则将数据库切换到简单模式
如果是(2),则安排定期日志备份
如果是(3),则修复计划的日志备份
如果(4),那就不要那样做:)相反,做小批量的工作. @H_404_2@请注意,这些中的任何一个都需要使用(不推荐使用)“备份日志dbname with truncate_only” @H_404_2@相反,一旦使用上述技术之一清除日志文件,然后使用以下方法收缩(现在为空)日志：
>您的数据库处于完全恢复模式,您应该进行常规日志备份
>您的数据库处于完全恢复模式,并且由于某种原因您的日志备份失败
>您正在运行大量巨大的事务,这些事务将日志文件扩展到大规模 @H_404_2@每个答案如下： @H_404_2@如果(1),则将数据库切换到简单模式
如果是(2),则安排定期日志备份
如果是(3),则修复计划的日志备份
如果(4),那就不要那样做:)相反,做小批量的工作. @H_404_2@请注意,这些中的任何一个都需要使用(不推荐使用)“备份日志dbname with truncate_only” @H_404_2@相反,一旦使用上述技术之一清除日志文件,然后使用以下方法收缩(现在为空)日志：
DBCC SHRINKFILE ('log logical name',2000)
@H_404_2@始终指定合理的最终尺寸,否则它将缩小到接近0,并且在下次需要时,将不得不花费时间来增长.
