我在 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
我们有一个 SQL 2000 DB。由于 Raid 阵列故障，服务器崩溃。现在，当我们运行 DBCC CHECKDB 时，我们得到一个错误，即 9 个页面中有 27 个一致性错误。
当我们在这些页面上运行 DBCC PAGE 时，我们得到：
Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.
由于指示的索引是非聚集的，并且是由包含 2 列的唯一 constarint 创建的，因此我们尝试删除并重新创建索引。这导致了以下错误：
CREATE UNIQUE …我们混合使用 SQL 2000、2005 和 2008 服务器，并且我们总是在完全备份之前每晚运行一次 DBCC CHECKDB，理论上您希望在备份之前确保数据库处于良好状态. （显然，备份的完整验证只能通过测试还原来完成，但这是一个稍微不同的主题。）
假设我无法将 DBCC 卸载到备份服务器或其他东西（这将是理想的），那么 DBCC CHECKDB 后跟 FULL BACKUP 是最佳顺序吗？
我发现讨论此问题的唯一“最佳实践”文档是我在 TechNet 上找到的 2006 年SAP SQL Server 维护的最佳实践：
理想情况下，应该在执行联机数据库备份之前运行使用 DBCC CHECKDB 的一致性检查。
这个建议正确吗？它是否适用于所有版本的 SQL？
（如果这有帮助，提出这个问题的部分动机是 DBCC 运行时似乎每晚都有相当大的变化，所以我们不能确切地依赖备份何时完成，这使得我们的磁带存档计划工作困难。另外，如果维护时间很长并且由于任何原因必须取消，我宁愿备份可靠地完成而不是 DBCC。）