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


当前回答

到目前为止,这里的大多数回答都假设您实际上并不需要事务日志文件,但是,如果您的数据库使用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)

其他回答

不推荐John推荐的这种技术,因为没有日志文件就不能保证数据库会附加。将数据库从full更改为simple,强制设置检查点并等待几分钟。SQL Server将清除日志,然后使用DBCC SHRINKFILE收缩日志。

到目前为止,这里的大多数回答都假设您实际上并不需要事务日志文件,但是,如果您的数据库使用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)

略微更新的答案,针对MSSQL 2017,并使用SQL服务器管理工作室。 我基本上是从这些指示https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

我有一个最近的数据库备份,所以我备份了事务日志。然后我又备份了一次。 最后,我缩小了日志文件,从20G减小到7MB,这更符合我的数据大小。 自从2年前安装这个系统以来,我认为交易日志从来没有备份过。所以把这项任务写在家务管理日历上。

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

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

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

首先检查数据库恢复模型。默认情况下,SQL Server Express Edition会为简单恢复创建一个数据库 (如果我没记错的话)。

备份日志DatabaseName With Truncate_Only

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile将为您提供逻辑日志文件名。

请参考:

从SQL Server数据库中的完整事务日志中恢复

如果您的数据库处于完全恢复模式,并且您没有进行TL备份,那么将其更改为SIMPLE。