我不是SQL专家,每当我需要做一些基本之外的事情时,我就会想起这个事实。我有一个测试数据库,它的大小不是很大,但是事务日志确实很大。如何清除事务日志?


当前回答

试试这个:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

其他回答

如果不使用事务日志进行恢复(即只进行完全备份),可以将恢复模式设置为“简单”,那么事务日志很快就会缩小,再也不会被填满。

如果您使用SQL 7或2000,您可以在数据库选项选项卡中启用“截断检查点日志”。这有同样的效果。

显然,在生产环境中不建议这样做,因为您将无法恢复到某个时间点。

根据我在大多数SQL server上的经验,没有事务日志的备份。 完全备份或差异备份是常见的实践,但事务日志备份确实很少。 因此事务日志文件会一直增长(直到磁盘满为止)。 在这种情况下,恢复模型应该设置为“simple”。 不要忘记修改系统数据库“model”和“tempdb”。

数据库“tempdb”的备份没有任何意义,因此这个数据库的恢复模型应该总是“简单”的。

下面是收缩事务日志的脚本,但是我强烈建议在收缩之前备份事务日志。

如果你只是缩小文件,你将失去大量的数据,这些数据在灾难发生时可能会成为救星。事务日志包含大量有用的数据,可以使用第三方事务日志读取器读取(可以手动读取,但需要付出很大的努力)。

当涉及到时间点恢复时,事务日志也是必须的,所以不要把它扔掉,而是要确保事先备份它。

以下是人们使用存储在事务日志中的数据来完成恢复的几篇文章:

如何查看SQL Server 2008的事务日志 读取SQL Server 2008中的日志文件(*.LDF)

 

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

当执行上面的命令时,您可能会得到类似这样的错误

"不能收缩日志文件(日志文件名),因为逻辑 位于文件末尾的日志文件正在使用"

这意味着正在使用TLOG。在这种情况下,尝试在一行中多次执行该命令,或者找到减少数据库活动的方法。

这是一种简单且不优雅且有潜在危险的方法。

备份数据库 分离数据库 重命名日志文件 附加数据库 将重新创建新的日志文件 删除重命名日志文件。

我猜您没有做日志备份。(截断日志)。我的建议是将恢复模式从完全恢复改为简单恢复。这将防止日志膨胀。

到目前为止,这里的大多数回答都假设您实际上并不需要事务日志文件,但是,如果您的数据库使用FULL恢复模型,并且您希望保留备份以备需要恢复数据库时使用,那么不要像许多回答所建议的那样截断或删除日志文件。

删除日志文件(通过截断它、丢弃它、擦除它等)将破坏备份链,并将阻止您恢复到上一次完整、差异或事务日志备份以来的任何时间点,直到进行下一次完整或差异备份。

来自微软关于备份的文章

我们建议不要手动使用NO_LOG或TRUNCATE_ONLY 截断事务日志,因为这会中断日志链。直到 下一次全量或差异数据库备份时,数据库不备份 防止媒体故障。仅在very中使用手动日志截断 特殊情况,并立即创建数据备份。

要避免这种情况,请在收缩日志文件之前将其备份到磁盘。语法应该是这样的:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)