Sayangnya saat ini tidak ada cara untuk memaksa pengumpulan sampah (GC) data filestream. Ini ditangani oleh tugas latar belakang asinkron yang hanya sering dipanggil dan memiliki batas jumlah file yang dapat diproses dalam satu permintaan. Orang lain telah mengeluh tentang hal ini dan Microsoft telah berjanji untuk mengatasi masalah ini di rilis mendatang.
Meskipun demikian, ada beberapa hal yang dapat Anda lakukan secara proaktif untuk memastikan bahwa semua file yang dihapus memenuhi syarat untuk pengumpulan sampah. File tidak secara otomatis memenuhi syarat untuk pengumpulan sampah saat dihapus dari database - kondisi tambahan tertentu harus dipenuhi.
Kondisi bergantung pada model pemulihan database, oleh karena itu penting bagi Anda untuk mengetahui model pemulihan database Anda. Perhatikan bahwa meskipun model pemulihan (seperti yang ditentukan oleh sys.databases) penuh, tetapi Anda belum mengambil db/log backup sejak mengaktifkan model pemulihan penuh (atau sejak membuat db), database akan berperilaku dalam banyak aspek seolah-olah masih dalam model pemulihan sederhana.
Di bawah model pemulihan sederhana semua yang diperlukan agar file memenuhi syarat untuk dihapus adalah bahwa LSN pos pemeriksaan saat ini (LSN dari pos pemeriksaan terakhir) lebih besar daripada LSN dari operasi penghapusan yang menghapus file. Oleh karena itu, yang dapat Anda lakukan setelah menghapus 40.000 baris adalah mengeluarkan satu pernyataan CHECKPOINT dan menunggu.
Hal-hal menjadi lebih rumit ketika database dalam model pemulihan "benar-benar penuh". Jika demikian halnya, maka selain LSN pos pemeriksaan, LSN cadangan (LSN cadangan log terakhir) harus melewati LSN hapus. Selanjutnya, GC bekerja dalam 2 fase:pada lintasan pertama hanya menandai file untuk dihapus tetapi tidak menghapusnya secara fisik. Hanya ketika GC memproses file untuk kedua kalinya, file itu akan dihapus secara fisik dari disk. Untuk membuat segalanya lebih menarik, lintasan pertama GC "mereset" penghapusan LSN, sehingga lintasan kedua hanya dapat memproses file ketika LSN pos pemeriksaan dan LSN cadangan lebih besar daripada LSN lintasan GC pertama.
Jika Anda ingin tahu persis apa yang terjadi dalam sistem, Anda dapat melacak kemajuan GC saat ini dengan melihat tabel "batu nisan" internal khusus. Setiap kali nilai filestream dihapus dari database, batu nisan dimasukkan ke dalam tabel ini. Batu nisan hanya dihapus setelah file telah dihapus dari disk. Nama tabel batu nisan adalah sys.filestream_tombstone_ di mana beberapa nomor. Anda mungkin mendapatkan nama persisnya menggunakan kueri berikut:
select name from sys.internal_tables where name like '%tombstone%'
Karena ini adalah tabel internal, untuk menanyakannya, Anda harus masuk menggunakan DAC (koneksi admin khusus).
Sebagai contoh, katakanlah saya telah menghapus sebuah baris dengan satu nilai filestream. Sekarang saya dapat melihat status batu nisan dengan mengeluarkan pertanyaan berikut (dari DAC):
select * from sys.filestream_tombstone_2073058421
3 bidang pertama menunjukkan LSN dari operasi penghapusan, tetapi yang paling penting untuk diamati adalah status. Setelah mengeluarkan cadangan log + pos pemeriksaan dan membiarkannya berjalan selama beberapa detik, saya menanyakan tabel batu nisan lagi dan saya mendapatkan:
Perhatikan bahwa status telah berubah (2 bit terakhir berubah dari 1 menjadi 2), menunjukkan bahwa file telah diproses oleh GC pass pertama. Selain itu, LSN telah diperbarui dengan LSN dari GC pass pertama, jadi agar GC pass kedua akhirnya dapat menghapus file, kita perlu membawa LSN pos pemeriksaan dan LSN cadangan di atas LSN baru. Saya mengeluarkan pos pemeriksaan lain + cadangan log, tunggu beberapa detik dan kueri ulang tabel batu nisan. Sekarang kosong dan file telah hilang dari disk.
Ingatlah bahwa ada hal lain (misalnya replikasi, transaksi lain saat pembuatan versi diaktifkan) yang dapat mencegah file tertentu dari pengumpulan sampah, tetapi dalam banyak kasus pos pemeriksaan dan pencadangan log adalah 2 yang utama.
Ups, saya rasa saya mungkin terlalu mendalami detailnya, tapi mungkin ini akan membantu dalam memahami perilaku GC.
