奇妙な動作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行：
2番目のサンプル時間サンプル期間（秒）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コアのEdgeがありません。
ただし、ローカルPCにはローカルI/Oレイテンシの利点があります（ローカルディスク、つまりSANに複数回アクセスする必要がない）。