如何清除SQL Server事务日志？
我不是SQL专家，每次我需要做一些超出基础知识的事情时，都会想起这个事实。我有一个规模不大的测试数据库，但是事务日志肯定是这样。如何清除交易日志？
解决方案
回答
这是一种简单且非常微妙且潜在危险的方式。
- 备份数据库
- 分离数据库
- 重命名日志文件
- 添加数据库
- 新的日志文件将被重新创建
- 删除重命名的日志文件。
我猜我们没有在进行日志备份。 (截断日志)。我的建议是将恢复模式从完全更改为简单。这样可以防止日志膨胀。
回答
截断日志文件：
- 备份数据库
- 通过使用企业管理器或者通过执行以下操作来分离数据库：Sp_DetachDB [DBName]
- 删除事务日志文件。 (或者重命名文件，以防万一)
- 使用以下方法再次添加数据库：Sp_AttachDB [DBName]
- 添加数据库后，将创建一个新的事务日志文件。
缩小日志文件：
- 带有No_Log的备份日志[DBName]
- 通过以下任一方法收缩数据库：使用企业管理器：-右键单击数据库，所有任务，收缩数据库，文件，选择日志文件，确定。使用T-SQL：-Dbcc Shrinkfile([Log_Logical_Name])
我们可以通过运行sp_helpdb或者在企业管理器中查找数据库的属性来找到日志文件的逻辑名称。
回答
如果我们不使用事务日志进行还原(即，我们只做过完整备份)，则可以将恢复模式设置为"简单"，事务日志将很快收缩并且永远不会再填充。
如果使用的是SQL 7或者2000，则可以在数据库选项选项卡中启用"在检查点上截断日志"。这具有相同的效果。
显然，在生产环境中不建议这样做，因为我们将无法还原到某个时间点。
回答
根据我在大多数SQL Server上的经验，没有事务日志的备份。
完全备份或者差异备份是常见的做法，但是事务日志备份确实很少。
因此，事务日志文件将永远增长(直到磁盘已满)。
在这种情况下，恢复模型应设置为"简单"。
不要忘记修改系统数据库" model"和" tempdb"。
数据库" tempdb"的备份没有意义，因此该数据库的恢复模型应始终为"简单"。
回答
免责声明：请仔细阅读以下评论，我认为我们已经阅读了接受的答案。正如我近5年前所说：
if anyone has any comments to add for situations when this is NOT an adequate or optimal solution then please comment below
- 右键单击数据库名称。
- 选择任务缩小数据库
- 然后点击"确定"！
我通常打开包含数据库文件的Windows资源管理器目录，因此可以立即看到效果。
实际上，我对此感到很惊讶！通常，我以前使用过DBCC，但是我只是尝试了一下，但它并没有缩小任何内容，所以我尝试了GUI(2005)，它在10秒内释放17GB的内存时效果很好
在完全恢复模式下，这可能无法正常工作，因此我们必须先备份日志，或者更改为简单恢复，然后收缩文件。 [为此感谢@onupdatecascade]
--
PS：我很高兴有人对这种做法的危害发表了评论，但是在我的环境中，我自己这样做没有任何问题，尤其是因为我总是首先进行完整备份。因此，在继续之前，请考虑环境以及它如何影响备份策略和作业安全性。我所做的只是向人们指出Microsoft提供的功能！
回答
不推荐John推荐的这项技术，因为不能保证没有日志文件就可以添加数据库。将数据库从完全更改为简单，强制执行检查点并等待几分钟。 SQL Server将清除日志，然后可以使用DBCC SHRINKFILE缩小日志。
回答
首先检查数据库恢复模型。默认情况下，SQL Server Express Edition创建用于简单恢复的数据库
型号(如果我没记错的话)。
带有Truncate_Only的备份日志DatabaseName：
DBCC ShrinkFile(yourLogical_LogFileName, 50)
SP_helpfile将为我们提供逻辑日志文件名。
参考：
从SQL Server数据库中的完整事务日志中恢复
如果数据库处于完全恢复模型中，并且没有进行TL备份，则将其更改为SIMPLE。
回答
例子：
DBCC SQLPERF(LOGSPACE) BACKUP LOG Comapny WITH TRUNCATE_ONLY DBCC SHRINKFILE (Company_log, 500) DBCC SQLPERF(LOGSPACE)
回答
使用DBCC ShrinkFile({logicalLogName}，TRUNCATEONLY)命令。如果这是一个测试数据库，而我们正在尝试节省/回收空间，则将有所帮助。
请记住，尽管TX日志确实具有一定的最小/稳定状态大小，它们会逐渐增长。根据恢复模式的不同，我们可能无法缩小日志(如果处于"完整"状态)，并且我们不发行TX日志备份，则无法缩小日志，日志将永远增长。如果不需要TX日志备份，请将恢复模式切换为"简单"。
请记住，在任何情况下都绝对不要删除日志(LDF)文件！我们几乎会立即遇到数据库损坏。煮熟了！完毕！数据丢失！如果"未修复"，则主MDF文件可能会永久损坏。
永远不要删除事务日志，我们将丢失数据！如果我们分离并"重命名"有效删除部分数据库的TX日志文件，则部分数据位于TX日志中(与恢复模型无关)。
对于那些删除了TX日志的用户，我们可能需要运行一些checkdb命令并修复损坏，然后再丢失更多数据。
查看Paul Randal的博客文章，关于这个话题，不好的建议。
另外，通常不要在MDF文件上使用收缩文件，因为它会严重碎片化数据。查阅他的不良建议部分以获取更多信息("为什么不应该收缩数据文件")
查看Paul的网站，他涵盖了这些问题。上个月，他在"神话一天"系列中探讨了许多这些问题。
回答
- 备份数据库
- 分离数据库
- 重命名日志文件
- 添加数据库(添加添加删除重命名的.ldf(日志文件)。选择它并按"删除"按钮删除)
- 新的日志文件将被重新创建
- 删除重命名的日志文件。
这将起作用，但是建议我们首先备份数据库。
