主页 / dba / 问题 / 40833
Accepted
Elijah W. Gagne
Asked: 2013-04-25 12:02:52 +0800 CST

如何最好地维护 SQL 日志文件大小

  • 772

我有点像一个新的 DBA，我正在管理一个有大量活动的 SQL Server 2012 实例。我在完全恢复模式下运行，因为我们需要时间点恢复。

现在，我每天早上 5 点对数据库和日志进行完整备份。一些日志文件已经膨胀到 300gb，即使在进行备份后，它们的大小也不会减小。我可以通过运行类似于以下内容来减小它们的大小：

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

当我检查备份文件的 LSN 时，我看到如下内容：

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

我不相信我会通过缩小日志文件来破坏我的日志链。阅读此内容后，我确实相信我正在损害我的表现，因为那些缩小的日志文件必须重新增长自己。

问题：

  1. 为什么备份后日志文件没有缩小？是因为有未提交的交易吗？
  2. 起初我想我应该在每 5:00 AM 备份后缩小日志文件。在阅读了这对性能有何不利影响后，我现在认为我需要在一天中每隔几个小时定期进行一次日志备份。那是对的吗？
  3. 我每天早上 5:00 对数据库/日志进行正常的完整备份，有时需要 3 个小时。如果我将日志备份安排为每小时发生一次，那么当日志备份与 5:00 AM 备份冲突时会发生什么？
sql-server sql-server-2012

3 个回答

  1. Best Answer
    1. 为什么备份后日志文件没有缩小？是因为有未提交的交易吗？

    实际的 NTFS 日志文件不会从事务日志备份中“缩小”，但事务日志中的 VLF（虚拟日志文件）被标记为可重用（因为它们现在已备份并保存在媒体上），从而允许环绕事务日志使用发生。如果您没有备份事务日志，或者不够频繁，那么将没有可用的 VLF，这将导致事务日志增长（假设设置了自动增长）以容纳额外的事务日志条目。

    2.起初我想我应该在每 5:00 AM 备份后缩小日志文件。在阅读了这对性能有何不利影响后，我现在认为我需要在一天中每隔几个小时定期进行一次日志备份。那是对的吗？

    例行和计划的文件收缩不是一个好主意。只有当您需要回收急需的空间时，您才应该考虑使用DBCC SHINKFILE. 此外，当您不断增加事务日志时，您可能会阻碍其他事情，例如数据库的恢复。由于事务日志中的 VLF 太多（事务日志仅以很小的存储增量增长时的常见问题），恢复数据库的时间可能比预期的要长。

    3.我每天早上 5:00 对数据库/日志进行正常的完整备份，有时需要 3 个小时。如果我将日志备份安排为每小时发生一次，那么当日志备份与 5:00 AM 备份冲突时会发生什么？

    什么都不会发生，这是完全合法的操作。请参阅MSDN的下图。有黑点的地方，这两个操作不能同时发生。如您所见，允许同时进行数据库备份和事务日志。

    在此处输入图像描述

    这里的要点是您应该更频繁地备份您的事务日志。如果不更频繁地备份事务日志，NTFS 文件增长并不是唯一可能遇到的问题。如果您遇到存储故障并且您的事务日志丢失，那么您只能恢复到上次事务日志备份的时间点。如果事务日志丢失，您将无法备份日志尾部并恢复到故障的时间点。在您的情况下，您可能会丢失 24 小时的数据。但是，如果您每隔 30 分钟备份一次事务日志，那么您的最大数据丢失时间将是 30 分钟。在这种情况下，如果您的事务日志消失了，并且您拥有完整备份和完整的日志链，您可以恢复到最后一个日志备份。

    关于事务日志截断的 TechNet 文档

    • 10

  2. 您要处理的主要问题是您每天备份一次日志。引擎的行为是日志文件中的日志记录（已用空间）只有在日志备份成功后才会被删除。发生检查点时会回收此空间，但如果您的数据库处于完全/批量日志恢复状态，则只有在成功备份日志记录后才会删除日志记录。

    日志备份旨在与完整备份结合使用，并且应在完整备份之间定期运行。这个间隔可以是任何时间段，尽管我通常每 15 分钟运行一次日志备份。您的时间间隔取决于您的恢复点目标 (RPO) 以及在恢复时您能够丢失多少数据。

    如果您正在执行定期日志备份，则不必执行定期文件收缩，因为您将在日志文件空间被迫增长之前对其进行管理。

    • 5

  3. 我以前也遇到过和你一样的问题。我的日志文件总是增加，而不是我每晚都使用完整的数据库备份。所以这是我的解决方案：

    1. 备份您当前的日志文件。

    2. 将数据库设置为简单恢复

      • 因为在完全恢复中 -> 日志文件不会删除已提交的事务，它只是重新排列您的数据 -> 新文件影响不大 -> 简单恢复反之亦然。

    3. 将您的日志文件缩小到 1 MB 或更少（由您决定）

    4. 将您的数据库设置回完全恢复。

    希望有帮助

    蓬陈

    • -1

相关问题