SQL Server 日志收缩问题

Question

可能的重复：
为什么事务日志不断增长或空间不足？

我的 SQL Server 中有一个 300 GB 的数据库日志。我想缩小所有日志，但它不允许我这样做。我尝试在 SQL Server 2008 R2 中使用查询和 UI。我用了

USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO

但是没有任何错误，数据库日志不会缩小。

然后我想使用另一种方法，如下所示：

我将从 SQL Server 分离数据库，然后在将特定.LDF文件移动到其他位置后，仅将数据库文件附加回 SQL Server。我能够成功地将所有日志从 SQL Server 移动到其他服务器。

请让我知道这是将事务日志移动到其他驱动器的好习惯。如果没有，请建议一些其他解决方案来从收缩的数据库日志中恢复。

Answer 1

如果您正在缩小日志文件，您将无法将其缩小到活动日志部分。换句话说，如果您处于Full Recovery Model 中，并且您还没有进行任何事务日志备份（这就是它可能会变得如此大的原因），那么运行 aDBCC SHRINKFILE绝对不会做任何事情。

BOL 有一个关于如何执行此操作的示例：

USE AdventureWorks2012;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2012
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2012
SET RECOVERY FULL;
GO

这是直接从DBCC SHRINKFILE 上的 BOL获取的。

在上面的示例中值得注意的是，将恢复模型更改为简单会破坏日志链。因此，一旦此操作完成，您需要立即通过运行数据库备份来启动新的日志链。

还值得注意的是，如果您的日志文件像这样增长，则您没有进行 [足够] 事务日志备份（前提是您确实处于完全恢复模式，因为这只会在简单恢复中非常罕见的情况下发生）。您可能需要开始进行事务日志备份，或者更频繁地备份您的日志，以便它截断 trans 日志并创建可重用的文件的一部分，这样您就不会出现这种文件增长。

Answer 2

其他答案中没有提到的几点。

除了缺少日志备份（尽管通常是这种情况）之外，日志未清除可能还有其他原因，例如数据库镜像或复制。

运行此查询以确定数据库的恢复模式，以及无法清除事务日志的原因：

SELECT
    name,
    log_reuse_wait_desc,
    recovery_model_desc
    FROM sys.databases

log_reuse_wait_desc可以在此处找到完整的值列表。如前所述，您可能会看到LOG_BACKUP，但最好确保在这种情况下没有其他任何事情使事情复杂化。

您可以使用安全的未记录命令DBCC LOGINFO（在目标数据库的上下文中运行）来转储有关事务日志的虚拟日志文件（又名 VLF，在另一个答案中描述）的信息。状态值 2 表示 VLF 正在使用中，0 表示未使用（值 1 是不可能的）。

正如提到的另一个答案，SQL Server 只会将日志文件缩小到上次使用的 VLF。

如果数据库中FULL或BULK_LOGGED恢复你的最后一个看到很多零，但2，您可能需要等待一些事务对数据库获取该日志的环绕，然后取一个日志备份来清除尾随的 VLF，最后再次运行收缩。

如果数据库正在SIMPLE恢复中，您可能必须手动运行 aCHECKPOINT以启动日志清除，然后再尝试再次收缩。

Answer 3

收缩 ldf 文件的安全方法是切换到简单恢复模式，然后执行收缩。

使用 SQL Server Management Studio：

1. 登录 SQL 服务器。
2. 展开“数据库”文件夹，右键单击数据库，选择属性。
3. 在“选项”页面中，将“恢复模式：”更改为“简单”，然后按“确定”按钮。
4. 您可能想要/需要备份数据库（右键单击数据库，任务\备份...）。
5. 右键单击数据库，打开“任务”子菜单，打开“收缩”子菜单并选择“数据库”。
6. 在新窗口中选中“释放未使用的空间之前重新组织文件”。复选框并按“确定”按钮。
7. 右键单击数据库，打开“任务”子菜单，打开“收缩”子菜单并选择“文件”。
8. 对于“文件类型：”，选择“日志”。
9. 确保选择“释放未使用的空间”单选按钮，然后按“确定”按钮。

这将解决您的问题，但您将无法再从事务日志中恢复。查看文档以了解哪种恢复模式最适合您。我通常使用 simple，因为我们进行大量插入，并且每小时/每天备份足以满足我们的需求。另外，如果您使用 simple 那么日志就不会变得那么大。

如果您不想更改恢复类型，请尝试在收缩数据库和数据库文件之前进行完整备份。出于性能原因，建议您在“收缩数据库”屏幕上将“收缩后文件中的最大可用空间”设置为至少 10%。如果您使用的数据库的日志可以很快增长到 300GB，那么您将希望将其保留得更大，并在“收缩文件”屏幕上将“收缩文件为：”设置为 1024 MB。

如果您需要更多帮助，请告诉我们，否则请接受答案。社区不喜欢回答不接受答案的人提出的问题。:)

编辑：上述步骤应该有效。您可能做错了什么（例如选择错误的数据库）。有关执行此操作的替代方法，请参阅本文。

另外，执行备份时请确保“备份类型：”已满，未选中“仅复制备份”复选框，并且在“备份组件：”下选择“数据库”。如果可能，请选择“选项”页面上“事务日志”的“截断事务日志”单选按钮。

尝试使数据库脱机，然后在运行上述步骤之前将其重新联机。如果它无法离线，那么您将需要手动终止 SQL 连接（用户仍然登录到数据库以防止这些更改）。

如果这些选项仍然不起作用，那么您将不得不使用不太安全的方法，例如将数据库备份到文件并将其恢复到现有数据库，然后缩小文件。

其他链接：

• 与我的说明类似，但带有图片。
• 使用脚本（在使用脚本之前始终了解脚本的用途）。
• 另一个图片版本。本文引用了 Microsoft 的一份有关管理 SharePoint 2007和2010服务器的文档（白皮书）。

另外，请确保您正在修改与该文件关联的数据库。您可以通过打开数据库的属性并转到“文件”页面来完成此操作。