我每天在我的桌子上测试批量插入以进行正在进行的项目，批量文件每天大约有1200000条记录。 事务日志不断增加。我推卸了一次9 gb的事务日志，但还没有备份。 像这样缩小事务日志是明智的吗？ 完全备份后是否可以缩小日志，还是需要单独备份日志？ 感谢
答案 0 :(得分：2)
这是很棒的链接，这是信息摘要：
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
答案 1 :(得分：0)
备份事务日志（我假设数据库处于完全恢复状态），然后收缩文件
DBCC SHRINKFILE (2, x)
（x是以MB为单位的目标大小）
确保在文件中留出一些空闲空间以避免自动增长。
如果没有按预期工作，您也可以在缩小之前切换到简单恢复，然后切换回完全恢复。
如果日志继续增长，请检查
select log_reuse_wait_desc from sys.databases
对于有问题的数据库。