Rất tiếc, hiện tại không có cách nào để buộc thu thập dữ liệu luồng dữ liệu luồng rác (GC). Nó được xử lý bởi một tác vụ nền không đồng bộ chỉ được gọi thường xuyên và có giới hạn về số lượng tệp mà nó có thể xử lý trong một lần gọi. Những người khác đã phàn nàn về điều này và Microsoft đã hứa sẽ giải quyết vấn đề này trong các bản phát hành trong tương lai.
Tuy nhiên, có một số điều bạn có thể chủ động làm để đảm bảo rằng tất cả các tệp đã xóa đều đủ điều kiện để thu gom rác. Một tệp không tự động đủ điều kiện để thu gom rác ngay khi bị xóa khỏi cơ sở dữ liệu - một số điều kiện bổ sung nhất định phải được đáp ứng.
Các điều kiện phụ thuộc vào mô hình khôi phục của cơ sở dữ liệu, do đó, điều quan trọng là bạn phải biết cơ sở dữ liệu của mình đang ở trong mô hình khôi phục nào. Lưu ý rằng ngay cả khi mô hình khôi phục (như được chỉ định bởi sys.databases) đã đầy, nhưng bạn chưa thực hiện Sao lưu db / log kể từ khi bật mô hình khôi phục đầy đủ (hoặc kể từ khi tạo db), cơ sở dữ liệu sẽ hoạt động theo nhiều khía cạnh như thể nó vẫn ở trong mô hình khôi phục đơn giản.
Theo mô hình khôi phục đơn giản, tất cả những gì cần thiết để tệp đủ điều kiện xóa là LSN của điểm kiểm tra hiện tại (LSN của điểm kiểm tra cuối cùng) lớn hơn LSN của thao tác xóa đã xóa tệp. Do đó, tất cả những gì bạn có thể làm sau khi xóa 40.000 hàng là phát hành một câu lệnh CHECKPOINT và đợi.
Mọi thứ trở nên phức tạp hơn khi cơ sở dữ liệu ở trong mô hình khôi phục "thực sự đầy đủ". Nếu đúng như vậy, thì ngoài LSN điểm kiểm tra, LSN sao lưu (LSN của bản sao lưu nhật ký cuối cùng) phải vượt qua LSN xóa. Hơn nữa, GC hoạt động theo 2 giai đoạn:trong lần vượt qua đầu tiên, nó chỉ đánh dấu một tệp để xóa nhưng không xóa nó về mặt vật lý. Chỉ khi GC xử lý tệp lần thứ hai thì tệp đó mới bị xóa khỏi đĩa. Để làm cho mọi thứ thú vị hơn nữa, pass đầu tiên của GC "đặt lại" LSN xóa, vì vậy pass thứ hai chỉ có thể xử lý tệp khi LSN điểm kiểm tra và LSN sao lưu lớn hơn LSN của pass GC đầu tiên.
Nếu bạn muốn biết chính xác những gì đang diễn ra trong hệ thống, bạn có thể theo dõi tiến độ GC hiện tại bằng cách xem một bảng "bia mộ" nội bộ đặc biệt. Mỗi khi một giá trị dòng filestream bị xóa khỏi cơ sở dữ liệu, một bia mộ sẽ được chèn vào bảng này. Bia mộ chỉ được gỡ bỏ sau khi tệp đã được xóa khỏi đĩa. Tên của bảng bia mộ là sys.filestream_tombstone_ đây là một số. Bạn có thể nhận được tên chính xác bằng cách sử dụng truy vấn sau:
select name from sys.internal_tables where name like '%tombstone%'
Vì đây là một bảng nội bộ, để truy vấn nó, bạn cần đăng nhập bằng DAC (kết nối quản trị chuyên dụng).
Ví dụ:giả sử tôi đã xóa một hàng có một giá trị dòng filestream. Bây giờ tôi có thể xem trạng thái của bia mộ bằng cách đưa ra truy vấn sau (từ DAC):
select * from sys.filestream_tombstone_2073058421
3 trường đầu tiên biểu thị LSN của thao tác xóa, nhưng điều quan trọng nhất cần quan sát là trạng thái. Sau khi tạo bản sao lưu nhật ký + điểm kiểm tra và để nó chạy trong vài giây, tôi truy vấn lại bảng bia mộ và nhận được:
Lưu ý rằng trạng thái đã thay đổi (2 bit cuối cùng thay đổi từ 1 thành 2), cho biết rằng tệp đã được xử lý bởi đường chuyền GC đầu tiên. Ngoài ra, LSN đã được cập nhật với LSN của thẻ GC đầu tiên, vì vậy để thẻ GC thứ hai có thể xóa tệp cuối cùng, chúng ta cần mang LSN điểm kiểm tra và LSN sao lưu phía trên LSN mới. Tôi đưa ra một điểm kiểm tra khác + sao lưu nhật ký, đợi vài giây và truy vấn lại bảng bia mộ. Bây giờ nó trống và tệp đã biến mất khỏi đĩa.
Hãy nhớ rằng có những thứ khác (ví dụ:sao chép, các giao dịch khác khi bật phiên bản) có thể ngăn các tệp cụ thể bị thu thập rác, nhưng trong hầu hết các trường hợp, điểm kiểm tra và sao lưu nhật ký là 2 thứ chính.
Rất tiếc, tôi đoán có thể tôi đã đi quá sâu vào chi tiết, nhưng có lẽ điều này sẽ giúp ích một phần nào đó trong việc hiểu hành vi GC.
