「DbccFilesCompact」ステータスが「Suspended」になるのはなぜですか？

600GデータファイルでSHRINKファイルを実行しています。

現在、ステータスは「一時停止」として報告されsys.dm_exec_requests.percent_complete、DbccFilesCompactコマンドレポートの場合は実行されている（ただし非常に遅い）

それが中断されている理由とそれをよりスムーズに実行する方法を確認する方法はありますか？

FYI-ステータスをチェックするための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では、非クラスター化インデックスの管理がストレージエンジン（私のチーム）からクエリプロセッサに変更されました。これには多くの副作用があり、そのうちの1つは、縮小によってヒープデータページを移動できる速度です。すべての非クラスター化インデックスレコードには、インデックスを作成するデータレコードへのバックリンクが含まれています。ヒープの場合、これは特定のデータページのレコード番号への物理リンクです。ヒープデータページが縮小によって移動されると、そのページのレコードにバックリンクするすべての非クラスター化インデックスレコードは、ページの新しい場所で更新される必要があります。2000年に、これはストレージエンジン自体によって非常に効率的に行われました。2005年以降は、クエリプロセッサを呼び出して非クラスター化インデックスレコードを更新することにより、これを行う必要があります。これは、2000年よりも最大で100倍遅くなることがあります。

2）行外LOB値（実際のLOBデータ型または行オーバーフローデータ）には、それらが属するデータまたはインデックスレコードへのバックリンクが含まれていません。LOBレコードのページを移動するときは、それらが含まれるテーブルまたはインデックス全体をスキャンして、どのデータ/インデックスレコードがそれらを指しているかを調べ、新しい場所で更新できるようにする必要があります。これも非常に遅いです。

3）データベースを使用する別のプロセスが原因で、ページを移動するために必要なロックを待機しているシュリンクをブロックしている可能性があります。

4）スナップショット分離が有効になっている可能性があり、古いバージョンを必要とするトランザクションが完了するまで、バージョンストアリンクのあるページを縮小できません。

5）I / Oサブシステムの能力が低下している可能性があります。低い1桁より長いディスクキューの長さは、I / Oサブシステムがボトルネックになっていることを意味します。

これらのいずれかまたはすべてが、実行時間の短縮の原因となっている可能性があります。

ただし、一般的には、縮小を実行する必要はありません。詳細については、このブログ記事を参照してください：あなたは、あなたのデータファイルを縮小してはならないのはなぜ。

お役に立てれば！

このスクリプトを実行して、完了率を確認できます。

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

SQL Server 2008 SP1でデータベースを縮小しています。Shrinkコマンドの進行状況を確認する方法の1つは、sp_lock spidを実行することです。ほとんどの場合、ファイル1にロックが設定されていることがわかります。ファイルID 2をロックします。これにより、最後のファイルIDで動作していることを確認できます。これは、ほぼ完了していることを示しています。

おかげで、

アレックス・アギラー

（私の場合）問題が何であるかを発見し、ここで私が使用したソリューションを提供します。

データベースを使用することは何もありません。masterはセッションのデフォルトデータベースでした。sp_who2を使用してそれを確認しました。次に、データベースを右クリックし、[タスク]、[縮小]、[OK]の順に選択します。sp_who2で再度チェックすると、ステータスは数分「一時停止」され、その後「排他ロックを取得できない」ために中止されます。あなた自身を推測してください、しかし私は対話自体がそれを引き起こすものであると確信しています。

だから私はコマンドライン経由で行くことにしました：

DBCC SHRINKDATABASE（myDataBase）

（魔女はどこにでも文書化されています）、その後、収縮はほんの数秒かかりました。