Leider gibt es derzeit keine Möglichkeit, die Garbage Collection (GC) von Filestream-Daten zu erzwingen. Es wird von einer asynchronen Hintergrundaufgabe gehandhabt, die nur gelegentlich aufgerufen wird und eine Begrenzung in der Anzahl der Dateien hat, die sie in einem einzigen Aufruf verarbeiten kann. Andere Leute haben sich bereits darüber beschwert und Microsoft hat versprochen, dieses Problem in zukünftigen Versionen zu beheben.
Davon abgesehen gibt es einige Dinge, die Sie proaktiv tun können, um sicherzustellen, dass alle gelöschten Dateien für die Garbage Collection geeignet sind. Eine Datei ist nicht automatisch für die Garbage Collection geeignet, sobald sie aus der Datenbank gelöscht wird - bestimmte zusätzliche Bedingungen müssen erfüllt sein.
Die Bedingungen hängen vom Wiederherstellungsmodell der Datenbank ab, daher ist es wichtig, dass Sie wissen, in welchem Wiederherstellungsmodell sich Ihre Datenbank befindet. Beachten Sie, dass selbst wenn das Wiederherstellungsmodell (wie von sys.databases angegeben) voll ist, Sie aber keine db/log-Sicherung seit dem Aktivieren des vollständigen Wiederherstellungsmodells (oder seit dem Erstellen der Datenbank) verhält sich die Datenbank in vielen Aspekten so, als ob sie sich noch im einfachen Wiederherstellungsmodell befände.
Beim einfachen Wiederherstellungsmodell ist alles, was erforderlich ist, damit eine Datei gelöscht werden kann, dass die LSN des aktuellen Prüfpunkts (die LSN des letzten Prüfpunkts) größer ist als die LSN des Löschvorgangs, der die Datei entfernt hat. Daher können Sie nach dem Löschen der 40.000 Zeilen nur eine einzige CHECKPOINT-Anweisung ausgeben und warten.
Die Dinge werden komplizierter, wenn sich die Datenbank im „wirklich vollen“ Wiederherstellungsmodell befindet. Wenn dies der Fall ist, muss zusätzlich zur Prüfpunkt-LSN die Sicherungs-LSN (die LSN der letzten Protokollsicherung) hinter der Lösch-LSN liegen. Darüber hinaus arbeitet der GC in 2 Phasen:Beim ersten Durchlauf markiert er eine Datei nur zum Löschen, löscht sie jedoch nicht physisch. Erst wenn GC die Datei zum zweiten Mal verarbeitet, wird diese Datei physisch von der Festplatte gelöscht. Um die Sache noch interessanter zu machen, „setzt“ der erste Durchgang von GC die Lösch-LSN zurück, sodass der zweite Durchgang die Datei möglicherweise nur verarbeitet, wenn die Prüfpunkt-LSN und die Backup-LSN größer als die LSN des ersten GC-Durchgangs sind.
Wenn Sie genau wissen möchten, was im System vor sich geht, können Sie den aktuellen GC-Fortschritt verfolgen, indem Sie sich eine spezielle interne "Tombstones"-Tabelle ansehen. Jedes Mal, wenn ein Filestream-Wert aus der Datenbank gelöscht wird, wird ein Tombstone in diese Tabelle eingefügt. Der Tombstone wird erst entfernt, nachdem die Datei von der Platte gelöscht wurde. Der Name der Tombstone-Tabelle lautet sys.filestream_tombstone_, wobei eine Zahl steht. Sie können den genauen Namen mit der folgenden Abfrage erhalten:
select name from sys.internal_tables where name like '%tombstone%'
Da es sich um eine interne Tabelle handelt, müssen Sie sich zum Abfragen über DAC (dedizierte Admin-Verbindung) anmelden.
Nehmen wir zum Beispiel an, ich habe eine Zeile mit einem einzelnen Filestream-Wert gelöscht. Jetzt kann ich den Status des Grabsteins sehen, indem ich die folgende Abfrage (von DAC) ausführe:
select * from sys.filestream_tombstone_2073058421
Die ersten 3 Felder geben die LSN des Löschvorgangs an, aber am wichtigsten ist der Status. Nachdem ich log backup + checkpoint ausgegeben und einige Sekunden laufen gelassen habe, frage ich die Tombstone-Tabelle erneut ab und erhalte:
Beachten Sie, dass sich der Status geändert hat (die letzten 2 Bits ändern sich von 1 auf 2), was anzeigt, dass die Datei vom ersten GC-Durchgang verarbeitet wurde. Darüber hinaus wurde die LSN mit der LSN des ersten GC-Durchlaufs aktualisiert. Damit der zweite GC-Durchlauf die Datei endgültig löschen kann, müssen wir die Prüfpunkt-LSN und die Sicherungs-LSN über die neue LSN bringen. Ich führe ein weiteres Checkpoint + Log-Backup aus, warte ein paar Sekunden und frage die Tombstones-Tabelle erneut ab. Es ist jetzt leer und die Datei ist von der Festplatte verschwunden.
Denken Sie daran, dass es andere Dinge gibt (z. B. Replikation, andere Transaktionen, wenn die Versionsverwaltung aktiviert ist), die verhindern können, dass bestimmte Dateien von der Garbage Collection erfasst werden, aber in den meisten Fällen sind Prüfpunkt- und Protokollsicherung die beiden wichtigsten.
Hoppla, ich denke, ich bin vielleicht zu tief in die Details gegangen, aber vielleicht hilft dies in gewisser Weise beim Verständnis des GC-Verhaltens.
