К сожалению, в настоящее время нет способа форсировать сборку мусора (GC) данных файлового потока.Он обрабатывается асинхронной фоновой задачей, которая вызывается только так часто, и имеет ограничение на количество файлов, которые он может обработать за один вызов.Другие люди уже жаловались на это, и Microsoft пообещала решить эту проблему в будущих выпусках.
При этом есть некоторые вещи, которые вы можете сделать заранее, чтобы гарантировать, что все удаленные файлы пригодны для сбора мусора.Файл не становится автоматически пригодным для сбора мусора в тот момент, когда он удаляется из базы данных - должны выполняться определенные дополнительные условия.
Условия зависят от модели восстановления базы данных, поэтому важно, чтобы вызнать, в какой модели восстановления находится ваша база данных. Обратите внимание, что даже если модель восстановления (как указано в sys.databases) заполнена, но вы не делали резервную копию базы данных db / log с момента включения полной модели восстановления (или с момента создания базы данных).), база данных будет вести себя во многих отношениях так, как если бы она все еще находилась в простой модели восстановления.
В простой модели восстановления все, что необходимо для того, чтобы файл имел право на удаление, заключается в том, что текущая контрольная точка LSN (LSNпоследняя контрольная точка) больше, чем LSN операции удаления, которая удалила файл.Поэтому все, что вы можете сделать после удаления 40000 строк, - это выполнить одну инструкцию CHECKPOINT и ждать.
Все становится сложнее, когда база данных находится в «действительно полной» модели восстановления.Если это так, то в дополнение к контрольной точке LSN резервный LSN (LSN последней резервной копии журнала) должен быть после удаления LSN.Кроме того, GC работает в 2 этапа: на первом проходе он только помечает файл для удаления, но не удаляет его физически.Только когда GC обработает файл во второй раз, этот файл будет физически удален с диска.Чтобы сделать вещи еще более интересными, первый проход GC «сбрасывает» удаленный LSN, поэтому второй проход может обрабатывать файл только тогда, когда контрольная точка LSN и резервный LSN превышают LSN первого прохода GC.
Если вы хотите точно знать, что происходит в системе, вы можете отслеживать текущий прогресс ГХ, просматривая специальную внутреннюю таблицу «надгробий».Каждый раз, когда значение файлового потока удаляется из базы данных, в эту таблицу вставляется надгробная плита.Надгробная плита удаляется только после удаления файла с диска.Имя таблицы захоронения sys.filestream_tombstone_, где указано некоторое число.Вы можете получить точное имя, используя следующий запрос:
select name from sys.internal_tables where name like '%tombstone%'
Поскольку это внутренняя таблица, для запроса необходимо войти в систему с помощью DAC (выделенное административное соединение).
Например, допустим, я удалил строку с одним значением файлового потока.Теперь я могу увидеть состояние надгробной плиты, выполнив следующий запрос (из ЦАП):
select * from sys.filestream_tombstone_2073058421
oplsn_fseqno |oplsn_bOffset |oplsn_slotid |file_id |rowset_guid |column_guid |filestream_value_name |транзакция_последовательность_num | статус
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 |транзакция_последовательность_num | статус
31 |265 |2 |65537 |CBA21DD0-C36F-4D19-A59B-F5312712A8F6 |6D2AA35E-692C-4F7D-8412-94475E76AC25 |0000001f-000000eb-0002 |0 |18
Обратите внимание, что статус изменился (последние 2 бита изменяются с 1 на 2), указывая на то, что файл был обработан первым проходом GC. Кроме того, LSN был обновлен с помощью LSN первого прохода GC, поэтому для того, чтобы второй проход GC мог окончательно удалить файл, нам нужно поместить контрольный пункт LSN и резервный LSN выше нового LSN. Я выдаю другую контрольную точку + резервное копирование журнала, подождите несколько секунд и повторно запросите таблицу надгробий. Теперь он пуст и файл исчез с диска.
Имейте в виду, что существуют другие вещи (например, репликация, другие транзакции, когда управление версиями включено), которые могут препятствовать сборке мусора конкретными файлами, но в большинстве случаев контрольная точка и резервное копирование журнала являются двумя основными.
Упс, наверное, я слишком углубился в детали, но, возможно, это поможет каким-то образом понять поведение GC.