為什麼“DbccFilesCompact”狀態為“Suspended”？

我在 600G 數據文件上執行 SHRINK 文件。

目前，狀態報告為“暫停”，sys.dm_exec_requests.percent_complete命令DbccFilesCompact報告它正在執行（但非常慢）

有沒有辦法檢查它為什麼被暫停以及如何使它執行更順暢？

僅供參考- 用於檢查狀態的 SQL 查詢

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
      , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
      cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

不，您無法檢查它為什麼執行緩慢，但我可以給您一些提示：

1）在SQL 2005中，非聚集索引的管理從儲存引擎（我的團隊）變成了查詢處理器。這有許多副作用，其中之一是堆數據頁可以通過收縮移動的速度。所有非聚集索引記錄都包含指向它們正在索引的數據記錄的反向連結——在堆的情況下，這是指向特定數據頁上記錄號的物理連結。當堆數據頁通過收縮移動時，所有反向連結到該頁上記錄的非聚集索引記錄都必須更新為該頁的新位置。在 2000 年，儲存引擎本身非常有效地完成了這項工作。從 2005 年開始，這必須通過呼叫查詢處理器來更新非聚集索引記錄來完成。這有時比 2000 年慢 100 倍。

2. 行外 LOB 值（實際 LOB 數據類型或行溢出數據）不包含指向它們所屬的數據或索引記錄的反向連結。當一頁 LOB 記錄被移動時，必須掃描它們所屬的整個表或索引，以確定哪些數據/索引記錄指向它們，以便使用新位置更新它們。這也非常非常慢。

3. 可能有另一個使用數據庫的程序導致收縮阻塞等待它需要移動頁面的鎖。

4）您可能啟用了快照隔離，並且在需要舊版本的事務完成之前，收縮無法移動帶有版本儲存連結的頁面。

5. 您的 I/O 子系統可能功率不足。磁碟隊列長度高於低個位數意味著您的 I/O 子系統處於瓶頸狀態。

任何或所有這些都可能導致收縮執行時間變慢。

不過，一般來說，您不想執行收縮。有關詳細資訊，請參閱此部落格文章：為什麼不應該縮小數據文件。

希望這可以幫助！

引用自：https://serverfault.com/questions/33252