系統會針對 SQL Server 檔案報告操作系統錯誤 665 和 1450

本文可協助您解決在執行 DBCC CHECKDB、建立資料庫快照集或檔案成長時，資料庫檔案回報 OS 錯誤 1450 和 665 的問題。

原始產品版本： SQL S
原始 KB 編號： 2002606

徵狀

假設您執行 SQL Server 的電腦上執行下列其中一個動作：

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

注意事項

SQL Server 針對這些作業使用疏鬆檔案：資料庫快照集和 DBCC CHECKDB。

• 備份或還原資料庫。
• 您可以使用平行 BCP 執行並寫入至相同的磁碟區，透過 BCP 對多個檔案執行大量複製。

由於這些作業，您可能會注意到 SQL Server 錯誤記錄檔中報告的其中一或多個錯誤，視執行環境 SQL Server 而定。

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

除了這些錯誤之外，您也可能會注意到下列閂鎖逾時錯誤：

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

此外，當您檢視 DMV) (各種動態管理檢視時，您可能也會注意到封鎖，例如 sys.dm_exec_requests 和 sys.dm_os_waiting_tasks。

在極少數情況下，您可能會發現 SQL Server 錯誤記錄檔中回報的未產生排程器問題，而且 SQL Server 產生記憶體轉儲。

原因

如果需要大量 ATTRIBUTE_LIST_ENTRY 實例才能在NTFS中維護高度分散的檔案，就會發生此問題。 如果空間位於檔系統已追蹤的叢集旁邊，則屬性會壓縮成單一專案。 不過，如果空間分散，則必須使用多個屬性來追蹤。 因此，大量檔案片段可能會導致屬性耗盡和產生的 665 錯誤。 下列 KB 文章說明此行為： NTFS 磁碟區中高度分散的檔案可能不會成長到超過特定大小。

當這些快照集檔案的生命周期發生大量數據修改時，SQL Server 或其他應用程式所建立的一般和疏鬆檔案可能會分散到這些層級。

如果您在位於相同磁碟區的一組等量檔案之間執行資料庫備份，或是要大量複製 (BCP-ing) 數據複製到相同磁碟區上的多個檔案，則寫入最後可能會位於相鄰的位置，但屬於不同的檔案。 例如，一個數據流寫入位移介於 201 到 400 之間，另一個數據流寫入從 401 到 600，第三個數據流可以從 601 寫入到 800。 此程式也會針對其他數據流繼續進行。 這會導致相同實體媒體上的檔案片段。 每個備份檔或 BCP 輸出數據流都可以耗盡屬性記憶體，因為沒有任何備份檔會取得相鄰的記憶體。

如需 SQL Server 引擎如何使用NTFS疏鬆檔案和替代數據流的完整背景，請參閱詳細資訊。

解決方案

請考慮使用下列一或多個選項來解決此問題：

1. 將資料庫檔案放在復原文件系統 (ReFS) 磁碟區上，此磁碟區沒有 NTFS 所呈現的相同ATTRIBUTE_LIST_ENTRY限制。 如果您想要使用目前的NTFS磁碟區，您必須在暫時將資料庫檔案移至別處之後，使用ReFS重新格式化。 使用 ReFS 是處理此問題的最佳長期解決方案。

   注意事項

   SQL Server 2012 和舊版使用具名檔案數據流，而不是使用疏鬆檔案來建立CHECKDB快照集。 ReFS 不支援檔案數據流。 DBCC CHECKDB在 ReFS 的 SQL Server 2012 檔案上執行可能會導致錯誤。 如需詳細資訊，請參閱 DBCC CHECKDB 如何從 2014 SQL Server 開始建立內部快照集資料庫中的附注。

2. 刪除資料庫檔案所在的磁碟區。 請確定您的重組公用程式是交易式。 如需重組 SQL Server 檔案所在磁碟驅動器的詳細資訊，請參閱重組資料庫磁碟驅動器時 SQL Server 預防措施和建議。 您必須關閉 SQL Server，才能在檔案上執行此作業。 建議您先建立完整資料庫備份，再將檔案重組為安全措施。 重組在 SSD) 媒體 (固態硬碟上的運作方式不同，通常無法解決問題。 將檔案複製 () ，並允許 SSD 韌體重新封裝實體記憶體通常是較好的解決方案。 如需詳細資訊，請參閱操作系統錯誤 (665 - 檔案系統限制) 不只是針對 DBCC。

3. 檔案複製 - 執行檔案複本可能會允許更好的空間擷取，因為位元組可能會緊密地封裝在程式中。 將檔案複製 (或移至不同的磁碟區) 可能會減少屬性使用量，並可防止操作系統錯誤 665。 將一或多個資料庫檔案複製到另一個磁碟驅動器。 然後，您可以將檔案保留在新的磁碟區上，或將它複製回原始磁碟區。

4. 使用 /L 選項來格式化 NTFS 磁碟區，以取得大型 FRS。 此選擇可能會減輕此問題，因為它會變 ATTRIBUTE_LIST_ENTRY 大。 此選擇在使用 DBCC CHECKDB 時可能沒有幫助，因為後者會建立資料庫快照集的疏鬆檔案。

   注意事項

   針對執行 Windows Server 2008 R2 和 Vista 的系統，您必須先從 KB 文章 套用 Hotfix 967351，再搭配 命令使用 /L 選項 format 。

5. 將大型資料庫分成較小的檔案。 例如，如果您有一個 8 TB 的數據檔，您可以將它分成八個 1 TB 的數據檔。 此選項可能會有所幫助，因為較小的檔案上會發生較少的修改，因此較不可能造成屬性耗盡。 此外，在四處移動數據的程式中，檔案會以精簡的方式組織，並減少片段。 以下是概述程式的高階步驟：

   1. 將七個新的 1 TB 檔案新增至相同的檔案群組。
   2. 重建現有數據表的叢集索引，這會自動將每個數據表的數據分散到八個檔案之間。 如果數據表沒有叢集索引，請建立一個並卸除它以完成相同的作業。
   3. 壓縮原始的 8 TB 檔案，現在大約已滿 12%。

6. 資料庫自動成長設定：調整自動 成長增量 資料庫設定，以取得符合生產效能和NTFS屬性封裝的大小。 自動成長發生頻率愈低，且成長增量大小愈大，檔案片段的可能性就越小。

7. 使用效能增強功能來降低命令的 DBCC CHECK 存留期，因而避免 665 錯誤： 當您使用 PHYSICAL_ONLY 選項時，DBCC CHECKDB 命令的改善可能會導致更快的效能。 請記住，DBCC CHECKDBPHYSICAL_ONLY使用 參數執行 並不保證您能夠避免此錯誤，但會降低在許多情況下的可能性。

8. 如果您要跨多個檔案執行資料庫備份 (等量集合) ，請仔細規劃檔案數目， MAXTRANSFERSIZE (BLOCKSIZE 請參閱 BACKUP) 。 目標是減少文件系統上的片段，通常會藉由將較大的位元組區塊一起寫入檔案來完成。 您可以考慮跨多個磁碟區分割檔案，以加快效能並減少片段。

9. 如果您使用 BCP 同時寫入多個檔案，請調整公用程式寫入大小，例如增加 BCP 批次大小。 此外，請考慮將多個數據流寫入不同的磁碟區，以避免片段化，或減少平行寫入的數目。

10. 若要執行 DBCC CHECKDB，您可以考慮設定可用性群組或記錄傳送/待命伺服器。 或使用第二部伺服器，您可以在其中執行 DBCC CHECKDB 命令來卸除工作，並避免遇到疏鬆檔案大量分散所造成的問題。

11. 當您執行 DBCC CHECKDB時，如果您在資料庫伺服器上活動很少時執行命令，則疏鬆檔案會稍微填入。 寫入檔案的次數越少，就會降低NTFS上屬性耗盡的可能性。 如果可能的話，活動較少是在第二部只讀伺服器上執行的另一個原因 DBCC CHECKDB 。

12. 如果您執行 SQL Server 2014，請升級至最新的 Service Pack。 如需詳細資訊，請參閱 FIX：當您在 2014 SQL Server 中針對包含資料行存放區索引的資料庫執行 DBCC CHECKDB 命令時，操作系統錯誤 665。

其他相關資訊

• 運作方式：SQL Server 2005 資料庫快照集 (複本)
• SQL Server 回報作業系統錯誤 1450 或 1452 或 665 (重試)
• 運作方式：SQL Server 重新流覽 DBCC 和快照集資料庫 (疏鬆檔案)
• 資料庫快照集的運作方式
• DBCC CHECKDB (Transact-SQL) [請參閱一節]
• 追蹤快照式疏鬆檔案寫入的新擴充事件
• 疏鬆檔案錯誤：1450 或 665，因為檔案分散：修正和因應措施