Malheureusement, il n'existe actuellement aucun moyen de forcer la récupération de place (GC) des données filestream. Il est géré par une tâche d'arrière-plan asynchrone qui n'est appelée que de temps en temps et qui 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 cela et Microsoft a promis de résoudre ce problème dans les prochaines versions.
Cela étant 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 récupération de place. Un fichier ne devient pas automatiquement éligible à la récupération de place 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 (comme spécifié par sys.databases) est plein, mais que vous n'avez pas pris de sauvegarde db/log depuis l'activation du modèle de récupération complète (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 encore dans le modèle de récupération simple.
Dans le modèle de récupération simple, tout ce qui est nécessaire pour qu'un fichier puisse être supprimé est 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 dans un modèle de récupération "vraiment complet". Si tel est le cas, en plus du LSN du point de contrôle, le LSN de sauvegarde (le LSN de la dernière sauvegarde du journal) doit être au-delà du LSN de suppression. De plus, le GC fonctionne en 2 phases :lors du premier passage, il marque uniquement un fichier à supprimer mais ne le supprime pas physiquement. Ce n'est que lorsque GC traite le fichier pour la deuxième fois que ce fichier sera 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 de point de contrôle et le LSN de sauvegarde sont supérieurs au LSN de la première passe de GC.
Si vous voulez savoir exactement ce qui se passe dans le système, vous pouvez suivre les progrès actuels du GC en consultant un tableau interne spécial des "pierres tombales". Chaque fois qu'une valeur filestream est supprimée de la base de données, une pierre tombale est insérée dans cette table. La pierre tombale n'est supprimée qu'après la suppression du fichier du disque. Le nom de la table tombstone est sys.filestream_tombstone_ où est un certain nombre. Vous pouvez obtenir le nom exact en utilisant la requête suivante :
select name from sys.internal_tables where name like '%tombstone%'
Puisqu'il s'agit d'une table interne, pour l'interroger, vous devez vous connecter à l'aide de DAC (connexion administrateur dédiée).
Par exemple, disons que j'ai supprimé une ligne avec une seule valeur filestream. Maintenant, je peux voir l'état de la pierre tombale en lançant la requête suivante (du DAC) :
select * from sys.filestream_tombstone_2073058421
Les 3 premiers champs indiquent le LSN de l'opération de suppression, mais le plus important à observer est le statut. Après avoir émis la sauvegarde du journal + point de contrôle et l'avoir laissé s'exécuter pendant quelques secondes, j'interroge à nouveau la table de désactivation et j'obtiens :
Notez que l'état a changé (les 2 derniers bits passent de 1 à 2), indiquant 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 de point de contrôle et le LSN de sauvegarde au-dessus du nouveau LSN. J'émets un autre point de contrôle + sauvegarde du journal, attends quelques secondes et réinterroge la table des pierres tombales. Il est maintenant vide et le fichier a disparu du disque.
Gardez à l'esprit qu'il existe d'autres éléments (par exemple, la réplication, d'autres transactions lorsque la gestion des versions est activée) qui peuvent empêcher le nettoyage de certains fichiers, mais dans la plupart des cas, le point de contrôle 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 manière ou d'une autre à comprendre le comportement du GC.
