Applies ToSQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

徵狀

請試想下列案例:

  • 在 Microsoft SQL Server 2014 中有兩個分區式資料表,第一個資料表的分區是使用相同的分區配置和函數,對應至不同的檔案和檔組。

  • 您將其中一個分區切換成第二個數據表,然後截斷第二個數據表。

  • 您會刪除對應到已切換分區的檔案和檔案組。

  • 您在第二個數據表上執行 SELECT 語句。

在此案例中,您收到下列錯誤訊息:

Msg 606,等級21,狀態1Metadata 不一致。 為 table <資料表名稱指定的 [檔組識別碼]<的 filegroup id>> 不存在。 執行 DBCC CHECKDB 或 CHECKCATALOG。

當您執行 DBCC CHECKDB/CHECKTABLE 時,會收到下列錯誤訊息:

無法處理 table <TableName> 的索引 <IndexName>,因為 filegroup (filegroup ID <FileGroupNumber>)無效。

解決方案

此問題首先是在 SQL Server 的下列累積更新中修正:

每個新的 SQL Server 累計更新都包含所有的修正程式,以及前一個累積更新中所包含的所有安全性修正程式。 我們建議您下載並安裝最新的 SQL Server 累積更新:

注意: 這個修正程式只會防止將來出現此問題。 如果您已經遇到這個問題,請將您的資料匯出至新資料庫,而不會有任何現有的中繼資料損毀。 若要執行這項操作,請依照下列步驟執行:

  1. 若要判斷分區是否有不正確檔案組,請執行下列查詢,查看它是否傳回結果:

    SELECT * FROM sys.allocation_units AS au WHERE au.data_space_id NOT IN (SELECT data_space_id FROM sys.filegroups)
  2. 使中繼資料損毀的資料表再次可見。如果步驟1的查詢傳回結果,則含有已損毀中繼資料的分區將會阻止您從表格中的任何列進行查看(選取 [* 寄件者])。 若要解決此問題,請移除該損壞的分區。注意: 不正確的磁碟分割應該是空的。 否則,檔案和其所在的檔案組將無法刪除或刪除。 若要這樣做,請將此分區移到另一個使用相同分區配置的資料表中。 此表格可以只是一個虛擬資料表。 在步驟1中使用查詢的 container_id,並將它與 sys. 分區的 partition_id 相符。 (請務必注意 partition_number。) 使用 partition_number 從 unviewable 至虛擬資料表的資料表中執行 ALTER TABLE 開關分區。 虛擬資料表應該有相同的一組資料行,並使用相同的分區配置。 您的查詢可尋找不一致的分區,可能如下所示:

    SELECT au.container_id, au.data_space_id, p.partition_number FROM sys.partitions AS p JOIN sys.allocation_units AS au ON p.partition_id = au.container_id LEFT JOIN sys.filegroups AS fgs ON fgs.data_space_id = au.data_space_id WHERE object_id = OBJECT_ID('MyTableName') AND fgs.data_space_id IS NULL;
  3. 從先前的 unviewable 資料表將資料複製到新資料庫中。

狀態

Microsoft 已確認<適用於>一節所列的 Microsoft 產品確實有上述問題。

需要更多協助嗎?

想要其他選項嗎?

探索訂閱權益、瀏覽訓練課程、瞭解如何保護您的裝置等等。

社群可協助您詢問並回答問題、提供意見反應,以及聆聽來自具有豐富知識的專家意見。