sql server - name - ¿Cómo forzar al recolector de basura filestream a completar su trabajo con la más alta prioridad?
store file in sql server (3)
Después de hacer esta pregunta, me queda claro que necesito poder realizar la recolección de basura en el menor tiempo posible.
¿Cómo es posible decirle al recolector de basura de SQL Server filestream que elimine todos los archivos con alta prioridad?
Intenté con la instrucción CHECKPOINT, incluso estableciendo una duración (CHECKPOINT 100), pero nada cambia.
Después de eliminar 40000 filestream records veo que el recolector de basura elimina 4-5 archivos por segundo. ¿Cómo decirle "borrarlos todos ahora"?
No tengo un entorno en el que pueda probar, pero ¿ha intentado cambiar al modo de recuperación simple?
Lamentablemente, actualmente no hay forma de forzar la recolección de basura (GC) de los datos de la ruta de archivos. Se maneja mediante 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.
Una vez dicho esto, hay algunas cosas que puede hacer proactivamente para asegurarse de que todos los archivos eliminados sean elegibles para la recolección de basura. Un archivo no se vuelve automáticamente elegible para la recolección de basura en el momento en que se borra 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 (especificado por sys.databases) está lleno, pero no ha tomado una Copia de seguridad de db / log ya que habilita el modelo de recuperación completa (o desde la creación de 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 punto de control actual LSN (el LSN del último punto de control) es 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 vuelven más complicadas cuando la base de datos está en un modelo de recuperación "verdaderamente completo". Si ese es el caso, además del punto de control LSN, el LSN de respaldo (el LSN de la última copia de respaldo de registro) debe pasar 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 procesa el archivo por segunda vez, ese archivo se eliminará físicamente del disco. Para hacer las cosas aún más interesantes, la primera pasada de GC "restablece" el LSN de eliminación, por lo que la segunda pasada solo puede procesar el archivo cuando el punto de control LSN y el LSN de respaldo son mayores que el LSN del primer pase de GC.
Si desea saber exactamente lo que está sucediendo en el sistema, puede hacer un seguimiento del progreso actual de GC al observar una tabla interna especial de "lápidas". Cada vez que se elimina un valor de la ruta de archivos de la base de datos, se inserta una lápida sepulcral en esta tabla. La piedra sepulcral solo se elimina después de que el archivo se haya eliminado del disco. El nombre de la tabla Tombstone es sys.filestream_tombstone_ donde hay algún número. Puede obtener el nombre exacto con la siguiente consulta:
select name from sys.internal_tables where name like ''%tombstone%''
Como se trata de una tabla interna, para consultarla debe iniciar sesión utilizando DAC (conexión de administrador dedicada).
Por ejemplo, supongamos que eliminé una fila con un único valor de la ruta de archivos. Ahora puedo ver el estado de la piedra sepulcral emitiendo la siguiente consulta (desde DAC):
select * from sys.filestream_tombstone_2073058421
oplsn_fseqno | oplsn_bOffset | oplsn_slotid | archivo_id | rowset_guid | column_guid | filestream_value_name | transaction_sequence_num | status
31 | 239 | 2 | 65537 | CBA21DD0-C36F-4D19-A59B-F5312712A8F6 | 6D2AA35E-692C-4F7D-8412-94475E76AC25 | 0000001f-000000eb-0002 | 0 | 17
Los primeros 3 campos denotan 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 de registro + punto de control y de permitir que se ejecute durante unos segundos, vuelvo a consultar la tabla Tombstone y obtengo:
oplsn_fseqno | oplsn_bOffset | oplsn_slotid | archivo_id | rowset_guid | column_guid | filestream_value_name | transaction_sequence_num | status
31 | 265 | 2 | 65537 | CBA21DD0-C36F-4D19-A59B-F5312712A8F6 | 6D2AA35E-692C-4F7D-8412-94475E76AC25 | 0000001f-000000eb-0002 | 0 | 18
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 ha actualizado con el LSN del primer pase de GC, por lo que para que el segundo pase de GC pueda finalmente eliminar el archivo, debemos traer el punto de control LSN y el LSN de respaldo por encima del nuevo LSN. Emito otro punto de control + copia de seguridad de 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 sean recolectados, pero en la mayoría de los casos el punto de control y la copia de seguridad del registro son los 2 principales.
Ups, creo que pude haber profundizado demasiado en los detalles, pero quizás esto ayude de alguna manera a entender el comportamiento del GC.
Aparentemente ahora hay una manera, al usar
sp_filestream_force_garbage_collection
en SQL Server 2012