Sfortunatamente al momento non è possibile forzare la raccolta dei rifiuti (GC) dei dati del flusso di file. È gestito da un'attività in background asincrona che viene invocata solo ogni tanto e ha un limite nel numero di file che può elaborare in una singola chiamata. Altre persone si sono già lamentate di questo e Microsoft ha promesso di affrontare questo problema nelle versioni future.
Detto questo, ci sono alcune cose che puoi fare in modo proattivo per assicurarti che tutti i file eliminati siano idonei per la raccolta dei rifiuti. Un file non diventa automaticamente idoneo per la raccolta dei rifiuti nel momento in cui viene eliminato dal database:devono essere soddisfatte determinate condizioni aggiuntive.
Le condizioni dipendono dal modello di ripristino del database, quindi è importante sapere in quale modello di ripristino si trova il database. Nota che anche se il modello di ripristino (come specificato da sys.databases) è completo, ma non hai eseguito un backup db/log da quando è stato abilitato il modello di ripristino completo (o dalla creazione del db), il database si comporterà sotto molti aspetti come se fosse ancora in un modello di ripristino semplice.
In un modello di ripristino semplice, tutto ciò che è necessario affinché un file sia idoneo per l'eliminazione è che l'LSN del checkpoint corrente (l'LSN dell'ultimo checkpoint) sia maggiore dell'LSN dell'operazione di eliminazione che ha rimosso il file. Pertanto tutto ciò che puoi fare dopo aver eliminato le 40.000 righe è emettere una singola istruzione CHECKPOINT e attendere.
Le cose si complicano quando il database è nel modello di ripristino "veramente completo". In tal caso, oltre all'LSN del checkpoint, l'LSN di backup (l'LSN dell'ultimo backup del registro) deve essere passato all'LSN di eliminazione. Inoltre, il GC funziona in 2 fasi:al primo passaggio contrassegna solo un file da eliminare ma non lo elimina fisicamente. Solo quando GC elabora il file per la seconda volta, quel file verrà eliminato fisicamente dal disco. Per rendere le cose ancora più interessanti, il primo passaggio di GC "reimposta" l'LSN di eliminazione, quindi il secondo passaggio può elaborare il file solo quando l'LSN del checkpoint e l'LSN di backup sono maggiori dell'LSN del primo passaggio GC.
Se vuoi sapere esattamente cosa sta succedendo nel sistema, puoi tenere traccia dell'avanzamento corrente del GC osservando una speciale tabella "tombstones" interna. Ogni volta che un valore del flusso di file viene eliminato dal database, in questa tabella viene inserita una rimozione. La rimozione definitiva viene rimossa solo dopo che il file è stato eliminato dal disco. Il nome della tabella tombstone è sys.filestream_tombstone_ dove è un numero. Puoi ottenere il nome esatto utilizzando la seguente query:
select name from sys.internal_tables where name like '%tombstone%'
Poiché si tratta di una tabella interna, per interrogarla è necessario accedere utilizzando DAC (connessione amministratore dedicata).
Ad esempio, supponiamo di aver eliminato una riga con un singolo valore di filestream. Ora posso vedere lo stato della lapide emettendo la seguente query (da DAC):
select * from sys.filestream_tombstone_2073058421
I primi 3 campi denotano l'LSN dell'operazione di eliminazione, ma il più importante da osservare è lo stato. Dopo aver eseguito il backup del registro + checkpoint e averlo lasciato in esecuzione per alcuni secondi, eseguo nuovamente una query sulla tabella tombstone e ottengo:
Si noti che lo stato è cambiato (gli ultimi 2 bit cambiano da 1 a 2), indicando che il file è stato elaborato dal primo passaggio GC. Inoltre, l'LSN è stato aggiornato con l'LSN del primo passaggio GC, quindi affinché il secondo passaggio GC possa eliminare definitivamente il file, è necessario portare l'LSN del checkpoint e l'LSN di backup al di sopra del nuovo LSN. Emetto un altro checkpoint + backup del registro, aspetto alcuni secondi e riinterrogo la tabella delle lapidi. Ora è vuoto e il file è scomparso dal disco.
Tieni presente che ci sono altre cose (ad es. la replica, altre transazioni quando il controllo delle versioni è abilitato) che potrebbero impedire la raccolta dei dati inutili di determinati file, ma nella maggior parte dei casi il backup del checkpoint e del registro sono i 2 principali.
Oops, immagino di essere andato troppo in profondità nei dettagli, ma forse questo aiuterà in qualche modo a comprendere il comportamento del GC.
