奇妙な動作DBCC Shrinkfile

データの95％がアーカイブおよび削除されているデータベースに対して、1 GBのチャンクでdbcc圧縮ファイルを実行しようとしています。9GBがデータ/インデックスである235GBファイルを使用しています。これを50GBに縮小したいと思います。データベースファイルの圧縮は悪いことです。断片化などが発生します。データのパージ/圧縮の一部として、idnexスクリプトを再構築することもできます。

自分のワークステーション（クアッドコア、12GB RAM、2 x SATAドライブ）のデータベースに対してdbcc圧縮ファイルスクリプトを実行すると、圧縮に約8〜10分かかります。

データベースポストデータパージの同じコピーに対して同じコードを実行すると、テスト環境（80以上のコア、128GB RAM、SSD SAN）では、70分かかります。注目すべきは、縮小ファイルの実行時にこのサーバーでアクティビティがほとんどないことです。同じ結果で4回実行されました。

次に、別のアプローチをとり、残りの9GBを別のファイルグループと物理ファイルに移動しました。自分のワークステーションで空の230GBファイルに対してdbccrinkfileを実行して50GBに圧縮すると、1分未満かかります。

これと同じアプローチで、テスト環境では、70分以上かかります。

テスト環境での70分間の実行中に、Brent Ozarのスクリプトに従って前後に待機統計のスナップショットを撮りました。下の上位3行：

秒単位のサンプル時間秒単位のサンプル期間wait_type待機時間（秒）待機数待機あたりの平均ミリ秒
2013-05-28 11：24：22.893 3600 WRITELOG 160.8 143066 1.1
2013-05-28 11：24：22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11：24：22.893 3600 PAGELATCH_EX 11.1 443038 0.0

Windowsイベントログに異常は何も表示されません。私はこの時点でスクラッチに向かっています。スタンドアロンワークステーションと比較して、忍者ハードウェアでこれほど時間がかかるのはなぜですか。

データファイルのShrinkfileはシングルスレッド操作であり、小さなメモリバッファを再利用します。

したがって、Ninjaハードウェアは、追加のメモリと80コアを備えていません。

ただし、ローカルPCにはローカルI / Oレイテンシの利点があります（ローカルディスク、つまりSANに何度もアクセスする必要がない）。