收缩镜像生产数据库上的事务日志文件的最简单方法

Question

在镜像生产数据库上收缩事务日志文件的最简单方法是什么？

我不得不这么做，因为我的磁盘空间快用完了。

在执行此操作之前，我将进行一个完整的数据库备份，因此我不需要保存事务日志中的任何内容(对吗？)我每天都有完整的数据库备份，可能永远不需要实时恢复，不过如果可以的话，我会继续打开选项--这就是.ldf真正要做的，对吧？)。

已解决：

好的，在通过仅通过日志的SSMS (而不是TSQL)进行2次备份之后，创建了一个全新的备份集，SSMS中的收缩-文件-日志对话框终于工作了，释放了一些磁盘空间。

不确定为什么需要2个备份，或者为什么TSQL不能工作，并且收缩对话框中报告的“可用空间可再生”(第一次备份后所有收缩尝试的空间也在99%，但仍然没有释放任何空间)没有区别，但目前解决了问题。谢谢大家。

Answer 1

执行事务日志备份，用任何你觉得最舒服的方法。

这将导致已提交到数据库的事务日志从磁盘中删除。理想情况下，您应该创建一个数据库维护任务，以便在重复的基础上为您执行这个任务--消除旧的事务日志，这样就不会填满磁盘。

根据你问题的另一部分..。不，不完全是。是的，他们履行这一职能，但不仅仅是这一职能。

数据库不像其他文件那样以传统的方式备份(或写入)，因为数据库文件本身一直在使用和不断变化。因此，一个单一的“时间点”备份要么要求离线将数据库“冻结”到一致状态，要么导致备份的不同部分包含与备份启动时不同的数据。

事务日志是数据库执行的每个“事务”的记录。这些操作不是每次更改、更新、添加、删除记录时都写入数据库文件，而是写入单独的文件、事务日志，然后在SQL服务器确定安全时提交到数据库文件中，而不会使任何活动停止。因此，事务日志实际上是在对数据库文件进行更改之前对数据库进行更改的。

因此，如果您需要回到给定的数据库状态或时间点，事务日志将被“重放”。本质上，不是复制文件数据，而是进入为数据库找到的最近的时间点状态，然后执行使数据库达到指定的后来状态的所有相同的事情。但是，需要注意的是，在任何给定的时间，您的事务日志都将包含尚未提交到数据库的事务。因此，它们不仅仅是执行实时恢复的能力。它们包含正在进行或不久将对数据库进行的一些更改。

这就是为什么您被迫在清除事务日志之前执行备份--一旦完成了备份，系统就有一个数据库的实时副本来引用将来的任何恢复，并且能够确定哪些事务已经提交给数据库，哪些事务没有提交。有了这些信息，系统就知道要为您删除哪些过时的事务日志，哪些不应该删除。

但是，这可能会花费一些时间，这取决于事务日志的大小。如果你以前从来没有做过一次，那就准备好这需要一段时间。

Answer 2

这是一个较老的问题，但有一些事情没有得到很好的解释，这将有希望提供一些启示。如何收缩的答案，大部分，但这将解释“为什么”的一部分，你实际上正在做的事情。

备份，特别是日志备份，做了几件事。数据作为备份集写入磁盘，以便在以后需要时使用或丢弃。随后的每个备份都将添加到该集中，在一个完全记录的DB中。截断日志或启动新的备份集会破坏链并抑制，或者在许多情况下，会使您无法恢复到链被破坏之前的某个时间点。

日志中的数据实际上没有被删除，在备份期间日志文件也没有缩小。活动VLFs标记为非活动，但不能完全提交的除外--它们仍然处于活动状态。不活动的VLFs可以重写，使您的日志循环，实际上就像蛇吃自己的尾巴。发出一个检查点，作为备份的一部分，它告诉DB在当前VLF填满之后，开始写入日志的开头。如果此时执行收缩操作，您将获得日志末尾的所有空间，直到活动的VLF为止。

第二次备份似乎是“完成任务”的原因，因为活跃的VLF通常在这段时间内被填满，日志从一开始就被写入。当您进行第二次备份时，活动的VLF作为备份集的一部分写入磁盘(或不写入备份集)，并且VLF被标记为非活动。由于这是由于以前的收缩日志的尾部，执行收缩现在释放所有的空间到日志的开始，直到当前活动的VLF。

所有这些都假设有几件事，1)。你没有庞大的VLFs，需要几个小时或几天的时间来填满和2)。您的数据库非常不活跃，没有一堆事务被写入日志。如果这些条件之一对您是一个问题，缩小您的日志也将是一个问题。

对于未镜像和镜像的数据库，所有这些都是正确的。不同之处在于，假设镜像是相同构建的，那么您只需要在镜像场景中对主服务器执行维护。

Answer 3

镜像特性使用日志来跟踪事情，直到它知道另一台服务器有这些更改。所以，不，ldf不仅仅是为了及时恢复。(这对于一些复制方案也很重要，但您没有这样做。)即使是TRUNCATE_ONLY也不会为了SQL可能需要的内容而丢弃记录的更改。典型的例子是一些大型或长期运行的事务。如果您已经完成了一个小时的事务，并且DBA运行的是TRUNCATE_ONLY，那么您的东西就不会从LDF中清除。地方土地基金可能继续增长或经历其他问题。如果DBA终止了连接，等待回滚完成，然后运行TRUNCATE_ONLY，那么日志应该释放。

你试过使用：

select log_reuse_wait_desc from sys.databases where name = 'mydb' 

看看为什么木头这么大？微软文档系统表这里。

您还可以运行：

dbcc opentran() 

这有点老生常谈，但它应该会显示数据库中任何长期运行的事务。微软记录了那个这里的命令。

我要做的是确保有一个日志备份在一个时间表上进行。

我会确保给TRUNCATE_ONLY命令一点时间来工作，有时需要一段时间才能开始向LDF文件前面写入VLF。如果LDF文件中的最后一个VLF是要写入的VLF，那么SQL不能缩短该文件。如果做不到这一点，我就会做一个完整的备份数据库(使用COPY_ONLY，或者等到常规备份发生，如果这在将来不会太远的话)。有时，这似乎启动了一些事情，但它可能只是一个备份分散了我的注意力，而等待当前的VLF移动到LDF文件的前面。在当前VLF移动到LDF文件的前面之后，您应该能够使用dbcc缩缩文件()并获得预期的结果。我建议你先把小块去掉，而不是一次就把它做完。

此外，您也希望避免定期这样做，因为进入重复收缩-自动增长周期可能是一个性能杀手。(它可能导致文件碎片，而实际的增长过程可能会花费惊人的时间，在此期间没有事务能够提交。将您的文件扩展到足够大，这样它们就不会自动增长。自动增长应该是一个故障安全的东西，而不是依赖。