我有一个在 SQL Server 2005 上运行的数据库。数据库为 20GB，LDF 文件为 35GB！我现在磁盘空间不足，想缩小日志文件。
我该怎么做？如何阻止这种情况再次发生？
答案1
嗯，基本上，您的 SQL Server 日志文件需要定期备份 - 每隔几个小时或几天。当您这样做时，它们会缩小。
现在，就您而言，您可以做两件事：
将数据库的“恢复模式”切换为“简单”。这意味着：你可以将数据库恢复到上次完整或差异数据备份，但此后将无法恢复 - 不过，日志会减少
使用
BACKUP LOG (yourDB) WITH TRUNCATE_ONLY立即截断日志（您将无法恢复上次数据备份和现在之间的任何内容）
答案2
摘要：如果您遇到这种情况，您可能需要下面的选项 1。跳过此处以解决问题，或继续阅读以了解更多说明。
Microsoft SQL Server 中的数据库具有不同的“恢复模式”，可配置为：
简单。您可以在简单恢复模式下对数据库进行完整备份和差异备份。 完整备份包含某一时间点的整个数据库，而差异备份包含自上次完整备份以来发生的所有内容。
此类数据库的备份计划可能是“每周日进行一次完整备份，外加每日进行一次差异备份”。这样差异备份就相对较小，因为它们仅包含自上周日以来更改的数据。如果发生崩溃，您丢失的数据不会超过 1 天。
完整备份。您仍然可以同时进行完整备份和差异备份，但您也必须定期进行事务日志备份。差异备份包含自上次完整备份以来的数据库更改，而日志备份仅包含数据自上次日志备份以来，因此日志备份应该小而快。
完整恢复数据库的备份计划可能是“每周进行一次完整备份，每天进行一次差异备份，每 5 分钟进行一次事务日志备份”。这意味着您永远不会丢失超过 5 分钟的数据。还原此类数据库时，您将还原到最新的差异备份，然后应用自该点以来进行的每个日志备份。
批量记录。这有点像“完整恢复模式，除非我另有说明”。
完全恢复非常棒，因为您可以将数据库恢复到几乎崩溃时的状态，但这也要求您进行日志备份。为什么？因为只有在进行日志备份后，事务日志文件中的日志才会被标记为“已截断”。一旦日志被截断，新的日志就可以覆盖它。
如果您从未进行过日志备份，那么事务日志中就不会有任何内容被标记为截断，因此日志文件必须随着每次数据库更改而增长。
有关事务日志如何工作的更多信息，请阅读 Paul Randal 的精彩文章：
现在，当你发现自己拥有一个巨大的事务日志时，有两个实际的选择：
选项 1：切换到简单恢复模式
您可能不需要进行日志备份（因为您现在没有这样做），因此您可以切换到简单恢复模型：
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE
这会将事务日志中的所有内容标记为已截断，因此日志文件不会再变大。完成此操作后，要缩小物理日志文件，请执行以下操作：
DBCC SHRINKFILE N'MyDatabase.ldf'
这意味着日志文件将在每次事务后自动截断自身。因此，其大小不会失控增长。您可能根本不需要管理事务日志；但是，您将无法恢复最新完整或差异备份以外的数据库。
选项 2：开始进行事务日志备份
如果您确实需要完全恢复，那么您必须开始进行事务日志备份。
首先，为了摆脱糟糕的局面，您需要截断整个日志，然后缩小它：
BACKUP LOG [MyDatabase] WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE N'MyDatabase.ldf'
GO
现在您的事务日志文件应该具有合理的大小。但是，它会立即再次开始增长。您现在必须开始定期进行日志备份。您可以通过维护计划或定期运行以下命令来执行此操作：
BACKUP LOG [MyDatabase] TO DISK = N'C:\Backups\MyDatabase_Log_Backup1.bak' WITH INIT
边注
DBCC SHRINKFILE不宜经常使用：
- 根据数据库活动和日志备份的频率，日志文件将恢复到稳定的大小。
- 缩小数据文件会使您的索引完全碎片化。
如果您发现自己定期缩小日志文件，那么您可能应该切换到简单恢复模型，或者更频繁地进行日志备份。