Desafortunadamente, actualmente no hay forma de forzar la recolección de basura (GC) de datos de flujo de archivos. Es manejado por una tarea en segundo plano asincrónica que solo se invoca cada cierto tiempo y tiene un límite en la cantidad de archivos que puede procesar en una sola invocación. Otras personas ya se han quejado de esto y Microsoft ha prometido abordar este problema en versiones futuras.
Dicho esto, hay algunas cosas que puede hacer de manera proactiva para asegurarse de que todos los archivos eliminados sean elegibles para la recolección de elementos no utilizados. Un archivo no se vuelve elegible automáticamente para la recolección de basura en el momento en que se elimina de la base de datos; se deben cumplir ciertas condiciones adicionales.
Las condiciones dependen del modelo de recuperación de la base de datos, por lo tanto, es importante que sepa en qué modelo de recuperación se encuentra su base de datos. Tenga en cuenta que incluso si el modelo de recuperación (según lo especificado por sys.databases) está lleno, pero no ha tomado una Copia de seguridad de db/log desde que se activó el modelo de recuperación completa (o desde que se creó la base de datos), la base de datos se comportará en muchos aspectos como si todavía estuviera en un modelo de recuperación simple.
En el modelo de recuperación simple, todo lo que se necesita para que un archivo sea elegible para la eliminación es que el LSN del punto de control actual (el LSN del último punto de control) sea mayor que el LSN de la operación de eliminación que eliminó el archivo. Por lo tanto, todo lo que puede hacer después de eliminar las 40 000 filas es emitir una sola instrucción CHECKPOINT y esperar.
Las cosas se complican más cuando la base de datos está en un modelo de recuperación "realmente completo". Si ese es el caso, además del LSN del punto de control, el LSN de la copia de seguridad (el LSN de la última copia de seguridad del registro) debe superar el LSN de eliminación. Además, el GC funciona en 2 fases:en la primera pasada solo marca un archivo para su eliminación pero no lo elimina físicamente. Solo cuando GC procese el archivo por segunda vez, ese archivo se eliminará físicamente del disco. Para hacer las cosas aún más interesantes, el primer paso de GC "restablece" el LSN de eliminación, por lo que el segundo paso solo puede procesar el archivo cuando el LSN del punto de control y el LSN de copia de seguridad son mayores que el LSN del primer paso de GC.
Si desea saber exactamente lo que está sucediendo en el sistema, puede realizar un seguimiento del progreso actual de GC consultando una tabla interna especial de "lápidas". Cada vez que se elimina un valor de secuencia de archivos de la base de datos, se inserta un desecho en esta tabla. El tombstone solo se elimina después de que el archivo se haya eliminado del disco. El nombre de la tabla de desecho es sys.filestream_tombstone_ donde es un número. Puede obtener el nombre exacto mediante la siguiente consulta:
select name from sys.internal_tables where name like '%tombstone%'
Dado que es una tabla interna, para consultarla debe iniciar sesión con DAC (conexión de administración dedicada).
Por ejemplo, supongamos que eliminé una fila con un único valor de secuencia de archivos. Ahora puedo ver el estado de la lápida emitiendo la siguiente consulta (desde DAC):
select * from sys.filestream_tombstone_2073058421
Los primeros 3 campos indican el LSN de la operación de eliminación, pero el más importante a observar es el estado. Después de emitir la copia de seguridad del registro + punto de control y dejar que se ejecute durante unos segundos, vuelvo a consultar la tabla de desecho y obtengo:
Tenga en cuenta que el estado ha cambiado (los últimos 2 bits cambian de 1 a 2), lo que indica que el archivo ha sido procesado por el primer pase de GC. Además, el LSN se actualizó con el LSN del primer pase de GC, por lo que para que el segundo pase de GC pueda eliminar el archivo en última instancia, debemos llevar el LSN del punto de control y el LSN de respaldo por encima del nuevo LSN. Ejecuto otro punto de control + copia de seguridad del registro, espero unos segundos y vuelvo a consultar la tabla de lápidas. Ahora está vacío y el archivo ha desaparecido del disco.
Tenga en cuenta que hay otras cosas (por ejemplo, la replicación, otras transacciones cuando el control de versiones está habilitado) que pueden evitar que determinados archivos se recopilen como elementos no utilizados, pero en la mayoría de los casos, el punto de control y la copia de seguridad de registros son los 2 principales.
Ups, creo que pude haber profundizado demasiado en los detalles, pero tal vez esto ayude de alguna manera a comprender el comportamiento del GC.
