残念ながら、現在、ファイルストリームデータのガベージコレクション（GC）を強制する方法はありません。これは、頻繁に呼び出されるだけで、1回の呼び出しで処理できるファイルの数に制限がある非同期バックグラウンドタスクによって処理されます。他の人々はすでにこれについて不平を言っており、Microsoftは将来のリリースでこの問題に対処することを約束しています。
そうは言っても、削除されたすべてのファイルがガベージコレクションの対象となるようにするために積極的に行うことができることがいくつかあります。ファイルがデータベースから削除された瞬間に、ファイルが自動的にガベージコレクションの対象になるわけではありません。特定の追加条件が満たされている必要があります。
条件はデータベースのリカバリモデルによって異なるため、データベースがどのリカバリモデルに含まれているかを知っておくことが重要です。リカバリモデル（sys.databasesで指定）がいっぱいであっても、完全復旧モデルを有効にしてから（またはdbを作成してから）、データベースは多くの面で単純な復旧モデルにあるかのように動作します。
単純な回復モデルでは、ファイルが削除の対象となるために必要なのは、現在のチェックポイントLSN（最後のチェックポイントのLSN）がファイルを削除した削除操作のLSNよりも大きいことだけです。したがって、40,000行を削除した後にできることは、単一のCHECKPOINTステートメントを発行して待機することだけです。
データベースが「真に完全な」リカバリモデルの場合、事態はさらに複雑になります。その場合、チェックポイントLSNに加えて、バックアップLSN（最後のログバックアップのLSN）が削除LSNを通過している必要があります。さらに、GCは2つのフェーズで機能します。最初のパスでは、ファイルに削除のマークを付けるだけで、物理的には削除しません。 GCがファイルを2回処理する場合にのみ、そのファイルはディスクから物理的に削除されます。さらに興味深いことに、GCの最初のパスは削除LSNを「リセット」するため、2番目のパスはチェックポイントLSNとバックアップLSNが最初のGCパスのLSNよりも大きい場合にのみファイルを処理できます。
システムで何が起こっているのかを正確に知りたい場合は、特別な内部「トゥームストーン」テーブルを調べることで、現在のGCの進行状況を追跡できます。ファイルストリーム値がデータベースから削除されるたびに、トゥームストーンがこのテーブルに挿入されます。トゥームストーンは、ファイルがディスクから削除された後にのみ削除されます。トゥームストーンテーブルの名前はsys.filestream_tombstone_です。ここで、はいくつかの番号です。次のクエリを使用して正確な名前を取得できます：
select name from sys.internal_tables where name like '%tombstone%'
これは内部テーブルであるため、クエリを実行するには、DAC（専用の管理者接続）を使用してログオンする必要があります。
たとえば、単一のファイルストリーム値を持つ行を削除したとします。これで、（DACから）次のクエリを発行することで、トゥームストーンのステータスを確認できます。
select * from sys.filestream_tombstone_2073058421
最初の3つのフィールドは、削除操作のLSNを示しますが、観察するのに最も重要なのはステータスです。ログバックアップ+チェックポイントを発行し、それを数秒間実行した後、トゥームストーンテーブルを再度クエリすると、次のようになります。
ステータスが変更され（最後の2ビットが1から2に変更）、ファイルが最初のGCパスによって処理されたことを示していることに注意してください。さらに、LSNは最初のGCパスのLSNで更新されているため、2番目のGCパスで最終的にファイルを削除できるようにするには、チェックポイントLSNとバックアップLSNを新しいLSNの上に配置する必要があります。別のチェックポイントとログバックアップを発行し、数秒待ってからトゥームストーンテーブルを再クエリします。これで空になり、ファイルがディスクから消えました。
特定のファイルがガベージコレクションされるのを妨げる可能性のある他の事柄（レプリケーション、バージョン管理が有効な場合の他のトランザクションなど）があることに注意してください。ただし、ほとんどの場合、チェックポイントとログバックアップが2つの主要なものです。
おっと、私は詳細に深く入り込んだかもしれないと思いますが、おそらくこれはGCの動作を理解するのに何らかの形で役立つでしょう。