Infelizmente, atualmente não há como forçar a coleta de lixo (GC) de dados de fluxo de arquivos. Ele é tratado por uma tarefa em segundo plano assíncrona que só é invocada de vez em quando e tem um limite no número de arquivos que pode processar em uma única chamada. Outras pessoas já reclamaram sobre isso e a Microsoft prometeu resolver esse problema em versões futuras.
Dito isto, há algumas coisas que você pode fazer proativamente para garantir que todos os arquivos excluídos sejam elegíveis para coleta de lixo. Um arquivo não se torna automaticamente elegível para coleta de lixo no momento em que é excluído do banco de dados - certas condições adicionais devem ser atendidas.
As condições dependem do modelo de recuperação do banco de dados, portanto, é importante que você saiba em qual modelo de recuperação seu banco de dados está. Observe que, mesmo que o modelo de recuperação (conforme especificado por sys.databases) esteja cheio, mas você não db/log backup desde a habilitação do modelo de recuperação completo (ou desde a criação do banco de dados), o banco de dados se comportará em muitos aspectos como se ainda estivesse no modelo de recuperação simples.
No modelo de recuperação simples, tudo o que é necessário para que um arquivo seja elegível para exclusão é que o LSN do ponto de verificação atual (o LSN do último ponto de verificação) seja maior que o LSN da operação de exclusão que removeu o arquivo. Portanto, tudo o que você pode fazer depois de excluir as 40.000 linhas é emitir uma única instrução CHECKPOINT e aguardar.
As coisas ficam mais complicadas quando o banco de dados está no modelo de recuperação "verdadeiramente completo". Se for esse o caso, além do LSN do ponto de verificação, o LSN de backup (o LSN do último backup de log) deve passar pelo LSN de exclusão. Além disso, o GC funciona em 2 fases:na primeira passagem, ele apenas marca um arquivo para exclusão, mas não o exclui fisicamente. Somente quando o GC processar o arquivo pela segunda vez, esse arquivo será excluído fisicamente do disco. Para tornar as coisas ainda mais interessantes, a primeira passagem do GC "reinicia" o LSN de exclusão, de modo que a segunda passagem só pode processar o arquivo quando o LSN do ponto de verificação e o LSN de backup forem maiores que o LSN da primeira passagem do GC.
Se você quiser saber exatamente o que está acontecendo no sistema, você pode acompanhar o progresso atual do GC consultando uma tabela interna especial de "lápides". Cada vez que um valor de fluxo de arquivos é excluído do banco de dados, uma marca de exclusão é inserida nessa tabela. A marca de exclusão só é removida após a exclusão do arquivo do disco. O nome da tabela de exclusão é sys.filestream_tombstone_ onde é algum número. Você pode obter o nome exato usando a seguinte consulta:
select name from sys.internal_tables where name like '%tombstone%'
Como é uma tabela interna, para consultá-la você precisa fazer logon usando DAC (conexão de administrador dedicada).
Por exemplo, digamos que eu excluí uma linha com um único valor de fluxo de arquivos. Agora posso ver o status da lápide emitindo a seguinte consulta (do DAC):
select * from sys.filestream_tombstone_2073058421
Os primeiros 3 campos denotam o LSN da operação de exclusão, mas o mais importante a ser observado é o status. Depois de emitir backup de log + checkpoint e deixá-lo rodar por alguns segundos, eu consulto a tabela de tombstone novamente e recebo:
Observe que o status mudou (os últimos 2 bits mudam de 1 para 2), indicando que o arquivo foi processado pela primeira passagem do GC. Além disso, o LSN foi atualizado com o LSN da primeira passagem do GC, portanto, para que a segunda passagem do GC possa excluir o arquivo, precisamos trazer o LSN do ponto de verificação e o LSN de backup acima do novo LSN. Eu emito outro checkpoint + backup de log, espero alguns segundos e consulto novamente a tabela de tombstones. Agora está vazio e o arquivo desapareceu do disco.
Lembre-se de que existem outras coisas (por exemplo, replicação, outras transações quando o controle de versão está ativado) que podem impedir que arquivos específicos sejam coletados como lixo, mas na maioria dos casos o checkpoint e o backup de log são os 2 principais.
Ops, acho que me aprofundei demais nos detalhes, mas talvez isso ajude de alguma forma a entender o comportamento do GC.
