Sql FILESTREAM 垃圾回收問題
更新了 3 倍
我正在使用 FILESTREAM，但在垃圾收集方面遇到了問題。當我將該列設置為空時，未清理 FILESTREAM 文件。
- 在事件日誌中，有大量這樣的錯誤：
Internal FILESTREAM error: failed to access the garbage collection table.- 這是此頁面上的錯誤號 5571：http: //msdn.microsoft.com/en-us/library/cc645602.aspx
- 使用這篇博文，我已經確認存在一個“墓碑”表，但我無法查詢它（
Invalid object name 'sys.filestream_tombstone_xxxxxxx'.）- 我沒有刪除行，而是將 FILESTREAM 列設置為 null，根據這篇msdn 文章：“當 FILESTREAM 欄位設置為 NULL 時，與該欄位關聯的 BLOB 數據將被刪除。”
- 數據庫位於本地驅動器上。
- 數據庫正在使用簡單恢復。
CHECKPOINT當活動非常低時，我執行了許多s。這似乎什麼也沒做。該錯誤消息似乎表明 FILESTREAM 垃圾收集器正在嘗試進行垃圾收集，但無法訪問該表以找出該做什麼。- SQL Server 2008（10.0.2531.0，SP1，企業版
- 我可以在 SQL Server 日誌或事件日誌中看到 5571 錯誤之前沒有其他錯誤。
DBCC CHECKDB
檢測到錯誤。我該怎麼辦？
DBCC results for 'sys.filestream_tombstone_1819153526'. Msg 8951, Level 16, State 1, Line 1 Table error: table 'sys.filestream_tombstone_1819153526' (ID 1819153526). Data row does not have a matching index row in the index 'FSTSNCIdx' (ID 2). Possible missing or invalid keys for the index row matching: Msg 8955, Level 16, State 1, Line 1 Data row (4:4712151:3) identified by (oplsn_fseqno = 62856 and oplsn_bOffset = 82647 and oplsn_slotid = 2) with index values 'file_id = 65537 and rowset_guid = '3F972309-9B0B-4C4F-939A-5618897050B4' and column_guid = '4A143C0D-B877-494E-B1E6-B70B0A834BB6' and oplsn_fseqno = 62856 and oplsn_bOffset = 82647 and oplsn_slotid = 2'. There are 209624 rows in 3382 pages for object "sys.filestream_tombstone_1819153526".問題：
- 應該如何設置權限才能使 FILESTREAM 工作？其他人可以訪問此伺服器，並且此數據庫可能已在某個時候從備份中恢復。
- 如何檢查 FILESTREAM (Windows) 共享/容器帳戶權限以及執行 SQL Server 的帳戶？
感謝@vgv8 提示提供更多資訊和想法。
似乎沒有足夠的資訊來明確地說明一些事情。例如，您是通過 Transact-SQL 刪除還是通過 Win32API 等進行刪除？
FILESTREAM 數據不會立即從文件系統中刪除，因為完全和批量恢復模式下的 SQL Server 事務日誌記錄允許崩潰恢復。
你用 CHECKPOINT 刪除了嗎
delete from tablename CHECKPOINT或嘗試執行 CHECKPOINT 語句或使用簡單恢復模式？
此外，國際海事組織：
- 更改 FILESTREAM（重新）配置需要重新啟動 SQL Server
- FILESTREAM 數據僅限於本地驅動器
- FILESTREAM 操作取決於硬體，請參閱Paul Randal 的白皮書
- “直接通過文件系統刪除或重命名任何 FILESTREAM 文件將導致數據庫損壞”
檢查Paul Randal 白皮書的安全性和可靠性部分
包含許多子引用的相關討論：
更新：
您是否檢查了 FILESTREAM (Windows) 共享/容器與執行 SQL Server 的帳戶的權限。它應該具有本地管理員權限。建議不要授予其他帳戶對數據容器的權限
Update2：
- “文件系統訪問打開操作不等待任何鎖。相反，如果由於事務隔離而無法訪問數據，則打開操作會立即失敗。如果由於隔離違規而無法繼續打開操作，則流式 API 呼叫將失敗並顯示 ERROR_SHARING_VIOLATION”
- “防病毒軟體……將阻止訪問受影響文件中的 BLOB 數據，並且對於 SQL Server，該文件似乎已被刪除。”
- “請注意，對於具有一個或多個 FILESTREAM 列的表，它還必須具有具有 ROWGUIDCOL 屬性的 uniqueidentifier 數據類型的列。此列不得允許空值，並且必須具有 UNIQUE 或 PRIMARY KEY 單列約束”
- “任何可以防止事務日誌截斷的東西也可能會阻止 FILESTREAM 文件被物理刪除。一些例子是：”
- FILESTREAM 數據容器不能嵌套
執行
DBCC CHECKDB
更新3：
我不能線上指導你。這是問答板。我已經被禁止多次違反 StackExchange 的規則進行討論而不是發布問題或答案
跑步
DBCC CheckDB（QPS8，repair_rebuild）
DBCC CheckDB (QPS8) WITH No_INFOMSGS, ALL_ERRORMSGS並將輸出放在這裡。
檢查/設置 NTFS 權限：右鍵點擊 Windows 中的文件夾 –> 屬性 –> 安全
檢查/設置 MSSQLServer：在命令行類型中
SQLServerManager10.msc導航到 SQL Server 服務並點兩下相應的 SQL Server 實例
更新 3b：
可能，您應該刪除並重新創建索引，或者您有更深層次的問題，您應該從備份中恢復數據庫或執行數據庫修復以允許失去數據。這是完全不同的主題/問題。
我不想承擔任何責任來指導你。