SQL Server 檔案報告 OS 錯誤 665 和 1450
本文可協助您解決在執行 DBCC CHECKDB、建立資料庫快照集或檔案成長時，針對資料庫檔案回報 OS 錯誤 1450 和 665 的問題。
原始產品版本：SQL Server
原始 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.
此外，當您檢視各種動態管理檢視時，您可能也會注意到封鎖，例如 sys.dm_exec_requests 和 sys.dm_os_waiting_tasks。
在罕見的情況下，您可能會發現 SQL Server 錯誤記錄檔中回報的非產生排程器問題，而且 SQL Server 會產生記憶體轉儲。
原因
如果需要大量的 ATTRIBUTE_LIST_ENTRY 實例，才能在NTFS中維護大量分散的檔案，就會發生此問題。 如果空間位於檔系統已追蹤的叢集旁邊，則屬性會壓縮成單一專案。 不過，如果空間已分散，則必須使用多個屬性來追蹤。 因此，大量檔案片段可能會導致屬性耗盡和產生的 665 錯誤。 此行為會在下列知識庫文章中說明： NTFS 磁碟區中大量分散的檔案可能不會成長超過特定大小。
SQL Server 或其他應用程式所建立的一般和疏鬆檔案，當這些快照集檔案的存用期發生大量數據修改時，可能會分散到這些層級。
如果您在相同磁碟區上的所有等量檔案集上執行資料庫備份，或如果您要大量複製 （BCP-ing） 數據到相同磁碟區上的多個檔案，則寫入可能會最終位於相鄰的位置，但屬於不同的檔案。 例如，一個數據流寫入到 201 到 400 之間的位移，另一個數據流會從 401 寫入到 600，第三個數據流可以從 601 寫入到 800。 此程式也會繼續處理其他數據流。 這會導致相同實體媒體上的檔案片段。 每個備份檔或 BCP 輸出數據流都可以耗盡屬性記憶體，因為沒有任何備份檔會取得相鄰的記憶體。
如需 SQL Server 引擎如何使用 NTFS 疏鬆檔案和替代數據流的完整背景，請參閱 詳細資訊。
解決方法
請考慮使用下列一或多個選項來解決此問題：
將資料庫檔案放在復原文件系統 （ReFS） 磁碟區上，該磁碟區沒有 NTFS 所呈現的相同
ATTRIBUTE_LIST_ENTRY限制。 如果您想要使用目前的NTFS磁碟區，則必須在將資料庫檔案暫時移至其他地方之後，使用ReFS重新格式化。 使用 ReFS 是處理此問題的最佳長期解決方案。注意
SQL Server 2012 和舊版使用具名 檔案數據流 ，而不是疏鬆檔案來建立
CHECKDB快照集。 ReFS 不支援檔案數據流。 在 ReFS 中的 SQL Server 2012 檔案上執行DBCC CHECKDB可能會導致錯誤。 如需詳細資訊，請參閱 DBCC CHECKDB 如何從 SQL Server 2014 開始建立內部快照集資料庫的附注。將資料庫檔案所在的磁碟區解除片段。 請確定您的重組公用程式是交易式。 如需有關重組 SQL Server 檔案所在磁碟驅動器的詳細資訊，請參閱 重組 SQL Server 資料庫磁碟驅動器和建議時的預防措施。 您必須關閉 SQL Server，才能在檔案上執行這項作業。 建議您先建立完整資料庫備份，再將檔案重組為安全性措施。 重組在固態硬碟 （SSD） 媒體上的運作方式不同，而且通常無法解決問題。 複製檔案，並允許 SSD 韌體重新封裝實體記憶體通常是更好的解決方案。 如需詳細資訊，請參閱作業系統錯誤 (665 - 檔案系統限制) 不再只是 DBCC 的問題。
檔案複製 - 執行檔案複本可能會允許更好的空間擷取，因為位元組可能會在程式中緊密封裝在一起。 複製檔案（或將它移至不同的磁碟區）可能會減少屬性使用量，並可能會防止OS錯誤665。 將一或多個資料庫檔案複製到另一個磁碟驅動器。 然後，您可以將檔案保留在新的磁碟區上，或將其複製到原始磁碟區。
使用 /L 選項來格式化 NTFS 磁碟區，以取得大型 FRS。 這個選擇可能會為這個問題提供緩解，因為它會變
ATTRIBUTE_LIST_ENTRY大。 使用DBCC CHECKDB此選項可能沒有幫助，因為後者會建立資料庫快照集的疏鬆檔案。注意
針對執行 Windows Server 2008 R2 和 Vista 的系統，您必須先從知識庫文章967351套用 Hotfix，然後再搭配
format命令使用/L選項。將大型資料庫分成較小的檔案。 例如，如果您有一個 8 TB 的數據檔，您可以將它分成八個 1 TB 的數據檔。 這個選項可能會有所幫助，因為較小的檔案會進行較少的修改，因此不太可能引入屬性耗盡。 此外，在移動數據的過程中，檔案會精簡組織，並減少片段。 以下是概述程式的高階步驟：
- 將七個新的 1 TB 檔案新增至相同的檔案群組。
- 重建現有數據表的叢集索引，這會自動將每個數據表的數據分散到八個檔案中。 如果數據表沒有叢集索引，請建立一個，然後卸除以完成相同的作業。
- 壓縮原始的 8 TB 檔案，現在已滿約 12%。
資料庫自動成長設定：調整自動 成長增量 資料庫設定，以取得有利於NTFS屬性生產效能和封裝的大小。 自動成長發生次數越少，成長增量大小愈大，檔案片段的可能性就越小。
使用效能增強功能減少命令的
DBCC CHECK存留期，以避免發生 665 錯誤： DBCC CHECKDB 命令的改善可能會在您使用 [PHYSICAL_ONLY] 選項時產生更快的效能。 請記住，使用PHYSICAL_ONLY參數執行DBCC CHECKDB不會提供您避免此錯誤的保證，但在許多情況下會降低可能性。如果您要跨許多檔案執行資料庫備份（等量集），請仔細規劃檔案數目，
MAXTRANSFERSIZE以及BLOCKSIZE（請參閱 BACKUP）。 目標是減少文件系統上的片段，通常是藉由將較大的位元組區塊一起寫入檔案來完成。 您可以考慮將檔案等量分割到多個磁碟區，以加快效能並減少片段。如果您使用 BCP 同時寫入多個檔案，請調整公用程式寫入大小，例如增加 BCP 批次大小。 此外，請考慮將多個數據流寫入不同的磁碟區，以避免分散，或減少平行寫入的數目。
若要執行
DBCC CHECKDB，您可以考慮設定可用性群組或記錄傳送/待命伺服器。 或者，使用第二部伺服器DBCC CHECKDB來執行命令來卸除工作，並避免發生大量疏鬆檔案分散所造成的問題。當您執行
DBCC CHECKDB時，如果您在資料庫伺服器上沒有活動時執行 命令，則疏鬆檔案會稍微填入。 對檔案的寫入較少會降低NTFS上耗盡屬性的可能性。 較少的活動是盡可能在第二部唯讀伺服器上執行DBCC CHECKDB的另一個原因。如果您執行 SQL Server 2014，請升級至最新的 Service Pack。 如需詳細資訊，請參閱 FIX：當您針對 SQL Server 2014 中包含資料行存放區索引的資料庫執行 DBCC CHECKDB 命令時，OS 錯誤 665。