我有几个数据库，其中事务日志(.LDF)比数据库文件(.MDF)大很多倍。

我该怎么办才能自动缩小或者防止它们变大？

解决方案

DBCC缩略文件。

这里是2005年。
这是2000年。

右键单击企业管理器>所有任务>收缩数据库中的数据库。

备份事务日志并缩小它。

如果数据库定期备份并在检查点处被截断，则它不应失去控制，但是，如果我们在这些间隔之间进行大量(大小)事务，它将一直增长到下一个检查点。

尝试sp_force_shrink_log，我们可以在这里找到
http://www.rectanglered.com/sqlserver.php

我们可以尝试做的另一件事是将数据库的恢复模式设置为简单(如果尚未设置)，这将使日志文件的增长不会很快。我们最近遇到了这个问题，因为我们的交易日志已满，并且我们不再被允许交易。

具有多个答案的收缩文件和简单的恢复模式的组合确保了我们的日志文件保持合理的大小。

使用查询分析器：

USE yourdabatase
SELECT * FROM sysfiles

我们应该找到类似于以下内容的内容：

FileID    …  
1             1             24264    -1            1280      1048578               0             yourdabatase_Data    D:\MSSQL_Services\Data\yourdabatase_Data.MDF
2             0             128         -1            1280      66           0                             yourdabatase_Log      D:\MSSQL_Services\Data\yourdabatase_Log.LDF

检查日志文件的文件ID(大多数情况下为2)。
执行2或者3次checkpoint命令以将每个页面写入硬盘驱动器。

Checkpoint
GO
Checkpoint
GO

执行以下transactional命令将日志文件中继到1 MB

DUMP TRAN yourdabatase WITH no_log 
DBCC SHRINKFILE(2,1)  /*(FileID , the new size = 1 Mb)*/

那应该做的

use master
go
dump transaction <YourDBName> with no_log
go
use <YourDBName>
go
DBCC SHRINKFILE (<YourDBNameLogFileName>, 100) -- where 100 is the size you may want to shrink it to in MB, change it to your needs
go
-- then you can call to check that all went fine
dbcc checkdb(<YourDBName>)

一句警告

我们只会在不需要适当备份策略的测试/开发数据库上真正使用它，因为转储日志将导致丢失事务历史记录。在实时系统中，我们应该使用Cade Roux推荐的解决方案

这是我一直在使用的

BACKUP LOG <CatalogName> with TRUNCATE_ONLY
DBCC SHRINKDATABASE (<CatalogName>, 1)
use <CatalogName>
go
DBCC SHRINKFILE(<CatalogName_logName>,1)

这里没有人说过，所以我将：永远不要缩小事务日志。从SQL Server的角度来看，这是一个坏主意。

通过每日执行数据库备份和每小时(或者更少)事务日志备份来保持事务日志较小。事务日志备份间隔取决于数据库的繁忙程度。