Sql服务器收缩事务日志

Question

我每天在我的表上测试批量插入的正在进行的项目，批量文件每天大约有1200000条记录。 事务日志不断增加。我忘记了一次9GB的事务日志，还没有备份。 像这样收缩事务日志是明智的做法。 可以在完整备份后收缩日志，还是需要单独备份日志？ 感谢

Answer 1

这是莫大的联系，这是信息的摘要：

How do you clear the SQL Server transaction log?

你不想TRUNCATE_ONLY选项做

• 备份日志有些东西然后SHRINKFILE。首先，这个TRUNCATE_ONLY选项已被弃用，并且在当前版本的SQL Server中不再可用。其次，如果您使用的是FULL恢复模式，则会破坏您的日志链并需要新的完整备份。

• 分离数据库，删除日志文件，并重新附加。我无法强调这可能会有多危险。你的数据库可能不回来了，就可能出现为可疑，你可能要恢复到一个备份（如果有的话），等等，等等

• 使用“收缩数据库”选项。 DBCC SHRINKDATABASE和维护计划选项来做同样的事情是不好的想法，特别是如果你真的只需要解决日志问题。定位您要调整的文件并使用DBCC SHRINKFILE或ALTER DATABASE ... MODIFY FILE（上面的示例）单独进行调整。

• 将日志文件缩小到1 MB。这看起来很诱人，因为，嘿，SQL Server会让我在某些情况下执行它，并查看它释放的所有空间！除非数据库是只读的（并且它应该使用ALTER DATABASE来标记），否则这绝对会导致许多不必要的增长事件，因为日志必须适应当前事务，而不管恢复模式如何。暂时释放这个空间的意义是什么？正如SQL Server能够缓慢而痛苦地回收这些空间一样？

• 创建第二个日志文件。这将暂时缓解已经充满磁盘的驱动器，但这就像试图用创可贴修复被刺破的肺部。你应该直接处理有问题的日志文件，而不是仅仅增加另一个潜在的问题。除了将某些事务日志活动重定向到另一个驱动器之外，第二个日志文件确实对您没有任何帮助（与第二个数据文件不同），因为一次只能使用其中一个文件。 Paul Randal also explains why multiple log files can bite you later。

How do you clear the SQL Server transaction log?

Answer 2

备份事务日志（我假设数据库处于完全恢复），然后收缩文件

DBCC SHRINKFILE (2, x) 

（x是一个以MB为单位的目标大小）

确保留有一定的自由文件中的空间以避免自动增长。

如果没有按预期工作，您也可以在收缩之前切换到简单恢复，然后切换回完全。

如果日志继续增长，检查

select log_reuse_wait_desc from sys.databases 

有问题的数据库。