CheckDB 操作失敗並返回錯誤
我們有一個數據庫，在過去幾個月中，當我們在維護視窗期間對其執行 CheckDB 時，它開始出現故障。當我們在失敗後重新執行它時，它每次都會很好地完成。
在我詳細介紹正在發生的事情以及到目前為止我們所做的事情之前，請先了解一些有關環境的資訊。
我們在 SQL Server 2008 R2 SP3 Enterprise / Windows Server 2008 R2 Enterprise 上執行。此實例包含我們的傳統 DW（具有構成維度設計的視圖的關係設計）。每次 CheckDB 失敗時，它都會在同一個數據庫和同一個文件組上失敗。數據庫大小為 7.5 TB，由 218 個文件組組成。每次失敗時都會有一個文件組出現問題，它是 641GB。文件組位於 I: 驅動器上，該驅動器目前為 2.7 TB 驅動器。
以下是我們遇到的一些錯誤——
在文件“I:\MSSQL\SQLDATA\FG_A.ndf:MSSQL_DBCC13”中的偏移量 0x0000002ece0000 處寫入期間，作業系統向 SQL Server 返回錯誤 665（請求的操作因文件系統限製而無法完成）。
SQL Server 錯誤日誌和系統事件日誌中的其他消息可能會提供更多詳細資訊。這是威脅數據庫完整性的嚴重系統級錯誤情況，必須立即糾正。完成完整的數據庫一致性檢查 (DBCC CHECKDB)。這個錯誤可能是由許多因素引起的；有關詳細資訊，請參閱 SQL Server 聯機叢書。
I:\MSSQL\SQLDATA\FG_A.ndf:MSSQL_DBCC13：遇到作業系統錯誤 665（由於文件系統限制，無法完成請求的操作）。
命令：DBCC CHECKDB (
$$ DatabaseA $$) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Msg 5269, Level 16, State 1, Server ServerA, Line 1
檢查終止。由於 IO 操作失敗，數據庫“DatabaseA”（數據庫 ID 6）的臨時數據庫快照已被標記為可疑。有關詳細資訊，請參閱 SQL Server 錯誤日誌。
Sqlcmd：錯誤：Microsoft SQL Native Client：未指定的錯誤。
內部數據庫快照具有拆分點 LSN = 003f2ecc:00003498:0001 和第一個 LSN = 003eb426:00002f58:0001。
我要注意的第一件事是，無論何時我們在失敗後手動重新執行它（並且有很多），這永遠不會失敗。這顯然需要很長時間，但它會毫無錯誤地完成。
現在對我來說，錯誤表明由於文件系統限製而失敗。當 CheckDB 執行時，它需要一個一致的數據庫視圖來檢查。為此，它會創建一個隱藏的數據庫快照。消息：
內部數據庫快照具有拆分點 LSN = 003f2ecc:00003498:0001 和第一個 LSN = 003eb426:00002f58:0001"
..表示創建快照的點。
這個錯誤發生在我們失敗的同時，所以看起來我們失敗了，因為驅動器上沒有足夠的空間來創建臨時快照。查看我們的監控，我們沒有看到在故障期間使用的空間增加了，但是，如果它首先檢查有多少可用空間，我們可能永遠不會看到空間增加。儘管當我們手動執行 CheckDB 時，我們也沒有看到空間使用率出現巨大的峰值。
文件組位於 I: 驅動器上，我們在驅動器上執行的空間有點低，因此我們將其擴展以創建一個舒適的間隙。目前，2.7 TB 驅動器上有 515GB 的可用空間。在我們這樣做之後，我們仍然有問題。
我們著眼於創建更小的驅動器並將文件組分散到更多，但我們有大量的 SQL 事務複製到這個數據庫。因此，如果我們分離、移動文件並重新附加，我相信我們會破壞複製，所以沒有這樣做。但是，不確定這是否能解決問題。
我也跑了
DBCC CheckDB WITH ESTIMATEONLY，它返回 1.5GB 作為所需的 Estimated TempDB 空間CHECKALLOC和 1 KB 作為所需的估計 TempDB 空間CHECKTABLES。我相信在舊版本的 SQL 中這不是很準確，但繼續檢查。我們還為此伺服器使用 SAN 儲存。我們開始在我們的舊儲存設備上遇到問題，然後我們將它移到了一個我們目前正在移動所有 SQL Server 的新設備上，問題消失了幾個星期，然後又開始了。因此，我們在 2 個完全獨立的儲存設備上進行了此操作，並且兩者都存在問題。此外，我們在這些儲存設備上執行了一些東西，而在其他任何地方都沒有看到這個問題。
在做了一些研究之後，我們為該產品做了一個修補程序，似乎它可能有助於解決這個問題：
我們經歷了應用此程序的過程，但是，它並沒有解決問題。
這些錯誤似乎表明故障是由於文件系統限製造成的，但是，我們無法確定該限制是什麼。或者，如果像一些警報一樣，我們只是得到一個一般性錯誤，並不能真正表明實際問題。
我們與系統管理員和儲存管理員進行了核對，以確保在後台沒有發生可能影響這一點的繁重操作，到目前為止還沒有確定任何內容。
我們剛剛盡可能多地調整了周末的日程安排，看看這是否會有所不同，但不確定是否會有所不同。想和你們核實一下，看看是否還有其他地方我們應該尋找，或者看看是否有我們可能遺漏的東西。謝謝
我檢查了錯誤的歷史記錄，發現 CheckDB 在一周中的同一天大約在同一時間失敗，並出現相同的錯誤。打算再次與管理員核實，看看此時是否有任何事情發生。
我不想複製@Nic 的資訊，所以這將是對他的建議的補充。
作業系統返回錯誤 665 …
NTFS 上稀疏文件的常見問題。等等，這個答案會好很多。
在進行了一些研究之後，我們為該產品做了一個熱修復，似乎它可能有助於解決這個問題……我們經歷了應用這個的過程，但是，它並沒有解決問題。
這就是我所期望的。這是因為該修補程序添加了對NTFS 文件系統的 /L 選項（大屬性描述符）的支持。這是很棒的部分，您只能通過使用此選項格式化卷來啟用它。因此，當然它沒有幫助，因為該卷沒有使用此選項進行格式化。
您可以創建一個新卷，使用 /L 格式化，複製文件，或者您可以嘗試使用 3rd 方應用程序來嘗試壓縮文件（這也應該壓縮元數據）並查看是否有效。此外，更大的 NTFS 分配單元大小將導致（對於 SQL Server）更少的 NTFS 元數據碎片。
您的問題，而不是損壞問題，是由
DBCC命令獲取數據庫的內部快照（出於一致性原因）並檢查它引起的稀疏文件限制。實際上只有兩種方法可以解決這個問題：
- 執行
DBCC CHECKDB WITH TABLOCK將在數據庫中的對像上使用排他鎖而不是快照。這樣做的缺點是，您將在數據庫中阻塞正在檢查的對象，這會嚴重影響您的事務流程- 將您的支票分解為每張桌子
DBCC CHECKDB WITH PHYSICAL_ONLY，然後再分解DBCC CHECKTABLE為每張桌子。這減少了快照的生存時間。這裡的困難在於管理它們，CHECKTABLE以便您最終不會真正快速地執行它們（對於小表），因為它可能導致執行緒池問題。我建議你看看像Minionware CheckDB (free) 這樣的東西，它可以為你做很多繁重的工作。