sql-server - 如何强制文件流垃圾收集器以最高优先级完成其工作？

Question

询问后this question我很清楚我需要能够在尽可能快的时间内执行垃圾收集。

如何告诉 SQL Server 文件流的垃圾收集器删除所有具有高优先级的文件？

我尝试使用 CHECKPOINT 语句，即使设置了持续时间(CHECKPOINT 100)，但没有任何变化。

删除 40000 条文件流记录后，我看到垃圾收集器每秒删除 4-5 个文件。如何告诉他“现在全部删除”？

Answer 1

不幸的是，目前无法强制对文件流数据进行垃圾回收 (GC)。它由一个异步后台任务处理，该任务仅在每次调用时调用
如此频繁，并且在一次调用中可以处理的文件数量有限制。其他人已经对此进行了提示，Microsoft 已 promise 在 future 版本中解决此问题。

话虽如此，您可能会主动采取一些措施来确保所有已删除的文件都符合垃圾收集条件。文件在从数据库中删除时不会自动成为垃圾收集的资格 - 必须满足某些附加条件。

这些条件取决于数据库的恢复模式，因此了解数据库所在的恢复模式很重要。请注意，即使恢复模式(由 sys.databases 指定)已满，但您还没有采取db/log 备份自从启用完整恢复模型(或自创建 db 以来)，数据库将在许多方面表现得好像它仍处于简单恢复模型中一样。

在简单恢复模型下，文件要符合删除条件所需要的只是当前检查点 LSN(最后一个检查点的 LSN)大于删除该文件的删除操作的 LSN。因此，在删除 40,000 行后，您所能做的就是发出单个 CHECKPOINT 语句并等待。

当数据库处于“真正完整”的恢复模式时，事情会变得更加复杂。如果是这种情况，那么除了检查点 LSN 之外，备份 LSN(上次日志备份的 LSN)必须经过删除 LSN。此外，GC 分两个阶段工作:在第一次通过时，它只将文件标记为要删除，但不会物理删除它。只有当 GC 第二次处理该文件时，该文件才会从磁盘中物理删除。更有趣的是，GC 的第一遍“重置”了删除 LSN，因此第二遍可能仅在检查点 LSN 和备份 LSN 大于第一遍 GC 的 LSN 时处理文件。

如果您想确切地知道系统中发生了什么，您可以通过查看一个特殊的内部“墓碑”表来跟踪当前的 GC 进度。每次从数据库中删除文件流值时，都会在此表中插入一个墓碑。只有在从磁盘中删除文件后才会删除逻辑删除。墓碑表的名称是 sys.filestream_tombstone_ 其中是一些数字。您可以使用以下查询获得确切名称:

select name from sys.internal_tables where name like '%tombstone%'

由于它是一个内部表，要查询它，您需要使用 DAC(专用管理连接)登录。

例如，假设我删除了具有单个文件流值的行。现在我可以通过发出以下查询(来自 DAC)来查看墓碑的状态:

select * from sys.filestream_tombstone_2073058421

oplsn_fseqno | oplsn_bOffset | oplsn_slotid | file_id | rowset_guid | column_guid | filestream_value_name | transaction_sequence_num |status

31 | 239 | 2 | 65537 | CBA21DD0-C36F-4D19-A59B-F5312712A8F6 | 6D2AA35E-692C-4F7D-8412-94475E76AC25 | 0000001f-000000eb-0002 | 0 | 17

前 3 个字段表示删除操作的 LSN，但最需要观察的是状态。发出日志备份+检查点并让它运行几秒钟后，我再次查询墓碑表，我得到:

oplsn_fseqno | oplsn_bOffset | oplsn_slotid | file_id | rowset_guid | column_guid | filestream_value_name | transaction_sequence_num |status

31 | 265 | 2 | 65537 | CBA21DD0-C36F-4D19-A59B-F5312712A8F6 | 6D2AA35E-692C-4F7D-8412-94475E76AC25 | 0000001f-000000eb-0002 | 0 | 18

注意状态发生了变化(最后2位从1变为2)，说明文件已经被第一次GC pass处理了。此外，LSN 已更新为第一次 GC 传递的 LSN，因此为了第二次 GC 传递能够最终删除文件，我们需要将检查点 LSN 和备份 LSN 置于新的 LSN 之上。我发出另一个检查点 + 日志备份，等待几秒钟并重新查询墓碑表。它现在是空的，文件已经从磁盘上消失了。

请记住，还有其他事情(例如复制、启用版本控制时的其他事务)可能会阻止特定文件被垃圾收集，但在大多数情况下，检查点和日志备份是两个主要的。

糟糕，我想我可能已经深入细节了，但也许这在某种程度上有助于理解 GC 行为。