web-dev-qa-db-ja.com

「DbccFilesCompact」のステータスが「一時停止」になっているのはなぜですか？

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

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

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


[〜＃〜] 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
sql-serversql-server-2005maintenancedbcc
11
dance2die

いいえ、なぜ動作が遅いのかは確認できませんが、ヒントをいくつか示します。

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

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

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

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

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

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

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

お役に立てれば！

10
Paul Randal

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

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

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

おかげで、

アレックスアギラール

2
Alex

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

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

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

DBCC SHRINKDATABASE（myDataBase）

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

0
Luis Siquot