Malheureusement, il n'y a actuellement aucun moyen de forcer la collecte des déchets (GC) des données de filtrage. Elle est gérée par une tâche d'arrière-plan asynchrone qui n'est invoquée que de temps en temps et dont le nombre de fichiers qu'elle peut traiter en une seule invocation est limité. et a une limite dans le nombre de fichiers qu'elle peut traiter en une seule invocation. D'autres personnes se sont déjà plaintes de ce problème et Microsoft a promis de le résoudre dans les prochaines versions.
Cela dit, il y a certaines choses que vous pouvez faire de manière proactive pour vous assurer que tous les fichiers supprimés sont éligibles pour la collecte des déchets. Un fichier ne devient pas automatiquement éligible à la collecte des déchets dès qu'il est supprimé de la base de données - certaines conditions supplémentaires doivent être remplies.
Les conditions dépendent du modèle de récupération de la base de données, il est donc important que vous sachiez dans quel modèle de récupération se trouve votre base de données. Notez que même si le modèle de récupération (tel que spécifié par sys.databases) est complet, mais que vous n'avez pas effectué de sauvegarde de la base de données/du journal depuis l'activation du modèle de récupération complet (ou depuis la création de la base de données), la base de données se comportera à bien des égards comme si elle était toujours dans le modèle de récupération simple.
Selon le modèle de récupération simple, pour qu'un fichier puisse être supprimé, il suffit que le LSN du point de contrôle actuel (le LSN du dernier point de contrôle) soit supérieur au LSN de l'opération de suppression qui a supprimé le fichier. Par conséquent, tout ce que vous pouvez faire après avoir supprimé les 40 000 lignes est d'émettre une seule instruction CHECKPOINT et d'attendre.
Les choses se compliquent lorsque la base de données est en modèle de récupération "vraiment complète". Si c'est le cas, en plus du LSN du point de contrôle, le LSN de la sauvegarde (le LSN de la dernière sauvegarde du journal) doit être supérieur au LSN de la suppression. De plus, le GC fonctionne en 2 phases : lors du premier passage, il marque seulement un fichier pour suppression mais ne le supprime pas physiquement. Ce n'est que lorsque le GC traite le fichier pour la deuxième fois que ce dernier est physiquement supprimé du disque. Pour rendre les choses encore plus intéressantes, la première passe de GC "réinitialise" le LSN de suppression, de sorte que la deuxième passe ne peut traiter le fichier que lorsque le LSN du point de contrôle et le LSN de sauvegarde sont supérieurs au LSN de la première passe GC.
Si vous voulez savoir exactement ce qui se passe dans le système, vous pouvez suivre la progression de la GC en consultant une table interne spéciale "pierres tombales". Chaque fois qu'une valeur de filtrage est supprimée de la base de données, une pierre tombale est insérée dans cette table. La pierre tombale n'est retirée qu'après la suppression du fichier sur le disque. Le nom de la table tombstone est sys.filestream_tombstone_ où est un nombre quelconque. Vous pouvez obtenir le nom exact en utilisant la requête suivante :
select name from sys.internal_tables where name like '%tombstone%'
Comme il s'agit d'une table interne, pour l'interroger, vous devez vous connecter à l'aide du DAC (dedicated admin connection).
Par exemple, disons que j'ai supprimé une ligne avec une seule valeur de filtrage. Maintenant, je peux voir le statut de la pierre tombale en émettant la requête suivante (à partir du CAD) :
select * from sys.filestream_tombstone_2073058421
oplsn_fseqno | oplsn_bOffset | oplsn_slotid | file_id | rowset_guid | column_guid | filestream_value_name | file_id column_guid | filestream_value_name | transaction_sequence_number |status
31 | 239 | 2 | 65537 | CBA21DD0-C36F-4D19-A59B-F5312712A8F6 | 6D2AA35E-692C-4F7D-8412-94475E76AC25 | 0000001f-000000eb-0002 | 0 | 17
Les 3 premiers champs indiquent le LSN de l'opération de suppression, mais le plus important à observer est le statut. Après avoir lancé la sauvegarde du journal + le point de contrôle et l'avoir laissé fonctionner pendant quelques secondes, j'interroge à nouveau la table tombstone et j'obtiens :
oplsn_fseqno | oplsn_bOffset | oplsn_bOffset oplsn_slotid | file_id | rowset_guid | column_guid | filestream_value_name | file_id column_guid | filestream_value_name | transaction_sequence_number |status
31 | 265 | 2 | 65537 | CBA21DD0-C36F-4D19-A59B-F5312712A8F6 | 6D2AA35E-692C-4F7D-8412-94475E76AC25 | 0000001f-000000eb-0002 | 0 | 18
Notez que l'état a changé (les 2 derniers bits passent de 1 à 2), ce qui indique que le fichier a été traité par la première passe GC. De plus, le LSN a été mis à jour avec le LSN de la première passe GC, donc pour que la deuxième passe GC puisse finalement supprimer le fichier, nous devons amener le LSN du point de contrôle et le LSN de sauvegarde au-dessus du nouveau LSN. Je lance un autre point de contrôle + sauvegarde du journal, attends quelques secondes et interroge à nouveau la table des pierres tombales. Elle est maintenant vide et le fichier a disparu du disque.
Gardez à l'esprit qu'il y a d'autres choses (par exemple la réplication, d'autres transactions lorsque le versioning est activé) qui peuvent empêcher des fichiers particuliers d'être garbage collectés, mais dans la plupart des cas, le checkpoint et la sauvegarde du journal sont les deux principaux.
Oups, je suppose que je suis peut-être allé trop loin dans les détails, mais peut-être que cela aidera d'une certaine manière à comprendre le comportement du GC.
