5

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

我能做些什么来自动缩小这些或防止它们变得如此之大?

4

9 回答 9

6

那应该做的工作

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建议的解决方案

于 2008-10-02T16:08:50.600 回答
4

备份事务日志并收缩它。

如果数据库定期备份并在检查点截断,它不应该失控,但是,如果您在这些间隔之间执行大量(大小)事务,它将增长到下一个检查点。

于 2008-10-02T15:47:42.087 回答
3

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

于 2008-10-02T15:47:36.033 回答
2

DBCC 收缩文件。

这里是 2005年。 这里是 2000 年。

于 2008-10-02T15:47:25.597 回答
1

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

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

于 2008-10-03T15:05:32.073 回答
0

您可以尝试的另一件事是将数据库的恢复模式设置为简单(如果还没有),这将防止日志文件快速增长。我们最近遇到了这个问题,我们的事务日志已满,我们不再被允许进行事务。

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

于 2008-10-02T15:56:53.267 回答
0

使用查询分析器:

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

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

DUMP TRAN yourdabatase WITH no_log 
DBCC SHRINKFILE(2,1)  /*(FileID , the new size = 1 Mb)*/
于 2008-10-02T16:04:18.677 回答
0

这是我一直在使用的

BACKUP LOG <CatalogName> with TRUNCATE_ONLY
DBCC SHRINKDATABASE (<CatalogName>, 1)
use <CatalogName>
go
DBCC SHRINKFILE(<CatalogName_logName>,1)
于 2008-10-02T16:34:35.903 回答
-1

试试 sp_force_shrink_log,你可以在这里找到 http://www.rectanglered.com/sqlserver.php

于 2008-10-02T15:48:12.520 回答