Server日志收缩问题

Question

可能重复: 为什么事务日志不断增长或耗尽空间？

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

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

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

然后我想再使用一个方法，如下所示：

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

请让我知道这是一个很好的做法，将事务日志移动到其他驱动器。如果不是，请建议一些其他解决方案，以便从收缩的数据库日志中恢复。

Answer 1

如果正在缩小日志文件，则无法将其缩小到比活动日志部分更小的范围。换句话说，如果您处于完全恢复模型中，并且没有进行任何事务日志备份(这就是为什么它会变得那么大)，那么运行DBCC 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拿来的。

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

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

Answer 2

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

除了缺少日志备份(尽管通常是这样)之外，日志没有清除可能还有其他原因，例如数据库镜像或复制。

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

SELECT
    name,
    log_reuse_wait_desc,
    recovery_model_desc
    FROM sys.databases

log_reuse_wait_desc值的完整列表可以找到这里。正如前面提到的，您可能会看到LOG_BACKUP，但是很好地确保在这种情况下没有任何事情会使事情复杂化。

您可以使用一个安全的、无文档的命令DBCC LOGINFO (在目标数据库的上下文中运行)来转储有关事务日志虚拟日志文件(也称为VLFs，另一个答案中描述)的信息。状态值为2表示VLF正在使用，而0表示它没有在使用(值1是不可能的)。

另一个答案是，Server只会缩小日志文件，直到最后一次使用VLF为止。

如果数据库处于FULL或BULK_LOGGED恢复中，并且您看到了大量的零，但在最后一个数据库中为2，则可能需要等待数据库上的一些事务才能使日志包装起来，然后进行日志备份以清除尾随的VLFs，最后再次运行收缩。

如果数据库处于SIMPLE恢复中，则在尝试再次收缩之前，可能必须手动运行CHECKPOINT以启动日志清除。

Answer 3

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

使用：

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

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

如果不想更改恢复类型，请尝试在收缩DB和DB文件之前执行完全备份。出于性能原因，建议您将“收缩后文件中的最大空闲空间”设置为至少10%。如果您使用的是一个日志，日志可以相当快地增长到300 MB，那么您将希望它更大，并在“收缩文件”屏幕上将“收缩文件”设置为: 1024 MB。

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

编辑:上面的步骤应该是有效的。您可能做错了什么(比如选择错误的数据库)。关于另一种方法，请参见这篇文章。

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

尝试将数据库从线上删除，然后在运行上述步骤之前将其重新联机。如果它不能正常运行，那么您将需要手动终止SQL连接(用户仍然登录到数据库中，防止这些更改)。

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

其他链接

• 类似于我的指示，但有图片。
• 使用脚本(在使用脚本之前，始终要了解脚本的功能)。
• 另一个图片版本。这篇文章引用了微软关于管理SharePoint、2007年年和2010年年服务器的文档(白皮书)。

此外，请确保您正在修改与文件关联的数据库。您可以通过打开数据库的属性并转到"Files“页面来做到这一点。