在 DBCC CHECKDB 或資料庫快照建立期間,會針對資料庫檔案報告作業系統錯誤1450和665

本文可協助您解決在 DBCC CHECKDB 建立或建立資料庫快照期間,針對資料庫檔案報告作業系統錯誤1450和665的問題。

原始產品版本:   SQL Server 2017,SQL Server 2016,SQL Server 2014,SQL Server 2012,SQL Server 2008
原始 KB 編號:   2002606

徵狀

在 SQL Server 電腦上,假設您執行下列其中一個動作:

  • 您可以在大型資料庫上建立資料庫快照。 之後,您會在來源資料庫中執行許多資料修改作業或維護作業。
  • 您可以在鏡像資料庫上建立資料庫快照。
  • 您可以執行 DBCC CHECKDB 命令族檢查大型資料庫的一致性,也可以在該資料庫中執行大量的資料變更。

在此案例中,您會注意到 SQL Server 錯誤記錄檔中所報告的下列錯誤,取決於執行 SQL Server 的環境。

Windows Server 2003

作業系統傳回錯誤 1450 (系統資源不足,無法完成所要求的服務。在使用 handle 0x0000000000000D5C 的檔案中寫入偏移0x00002a3ef96000 時,) 至 SQL Server。 這通常是暫時性的情況,而且 SQL Server 會繼續重試此作業。 如果此狀況持續存在,則必須採取立即動作才能更正此狀況。

Windows Server 2008、Windows Vista 和更新版本的伺服器及用戶端作業系統

作業系統傳回錯誤 665 (無法完成要求的作業,原因是在檔案 ' Sam: MSSQL_DBCC18 ' 中寫入偏移0x00002a3ef96000 時,對 SQL Server 的檔案系統限制)

除了這些錯誤之外,您還可以注意到 閂鎖超時 錯誤,如下所示:

  • 等候閂鎖時發生超時:類別 ' DBCC_MULTIOBJECT_SCANNER ',id 000000002C61DF40,type 4,Task 0x00000000038089B8:16,waittime 600,旗0x1a,擁有的任務0x0000000006A09828。 繼續等候。

  • 等候閂鎖時發生超時:類別 ' ACCESS_METHODS_HOBT_COUNT ',id 000000002C61DF40,type 4,Task 0x00000000038089B8:16,waittime 600,旗0x1a,擁有的任務0x0000000006A09828。 繼續等候。

此外,您也可能會注意到,當您查看各種動態管理檢視時 (DMV) 如等等) sys.dm_exec_requests sys.dm_os_waiting_tasks

原因

如果需要大量的 ATTRIBUTE_LIST_ENTRY 實例以維護 NFTS 中大量零碎的檔案,便會發生此問題。 這種行為會在下列 KB 文章中說明:

NTFS 磁片區中大量零碎的檔案可能不會增長到超過一定大小

當這些快照檔案的生命週期發生大量資料修改時,SQL Server 針對資料庫快照所建立的稀疏檔案可能會分散到這些層級。

如需 SQL Server 引擎如何使用 NTFS 稀疏檔案和替代資料流程的完整背景,請參閱下列連結:

解決方案

  1. 將大型資料庫分割成較小的檔案。 例如,如果您有 1 8 TB 的資料檔案,您可以將它分割成 8 1 TB 的資料檔。 高層級這些是完成這項作業的步驟:

    1. 將7個新的 1 TB 檔案新增至相同的檔群組。
    2. 重建現有資料表的聚簇索引,這樣會在8個檔案之間自動散佈每個資料表的資料。 如果資料表沒有成簇索引,請先建立一個,然後放下它,以達到相同的目的。
    3. 縮小原始的 8 TB 檔案,現在大約是12-15% 已滿。
  2. 請考慮將資料庫檔案放在不具有 NTFS 所呈現的 ATTRIBUTE_LIST_ENTRY 限制的 ReFS 磁片區上。 您必須使用 ReFS 重新格式化目前的 NTFS 磁片區。

  3. 請考慮對資料庫檔案所在的磁片區進行磁碟重組。 如需詳細資訊,請參閱 作業系統錯誤 (665-檔案系統限制) 不只是 DBCC

  4. 使用 /l 選項格式化磁片區以取得大型的 FRS。

    注意

    針對執行 Windows Server 2008 R2 和 Vista 的系統,在使用/L 選項搭配 format 命令之前,您必須先從 KB 文章967351套用修復程式。

  5. 修正:當您對 SQL Server 2014 中包含列存儲索引的資料庫執行 DBCC CHECKDB 命令時,作業系統錯誤665

  6. 使用效能增強功能縮短 DBCC CHECK 命令的存留期,進而避免665錯誤: DBCC CHECKDB 命令的增強功能可能會在您使用 PHYSICAL_ONLY 選項時產生更快的效能

在某些情況下,即使在套用這些修正後,您仍可能會遇到上述的錯誤。 在此案例中,您可以評估下列博客文章中討論的一些變通方法:

疏鬆檔案錯誤:1450或665由於檔案分散:修復程式和解決方法

如需詳細資訊,請參閱在 SQL Server 資料庫位於 ReFS 磁片區上時的 DBCC CHECKDB 行為