インデックスを再構築するときにsort_in_tempdbを使用する場合


22

DWテーブルにSORT_IN_TEMPDBオプションを使用するかどうかを議論しています。私の理解では、このオプションを使用した場合、書き込みはより多くなりますが、それらはよりシーケンシャルです。SANがあります(これは時々悪名高くなっています)。この場合、書き込みの数を可能な限り制限したいと思います。tempdbは別のLUN(ディスクのセット)上にあると思います。

データファイルとtempdbファイルに十分なディスク領域があります。この場合、SORT_IN_TEMPDBを使用するメリットはありますか?

私を驚かせたのは、この回答に対するこのコメントです

インデックスを再構築する場合、ソートにインデックスの2倍のスペース+ 20%が必要になります。したがって、一般に、データベース内のすべてのインデックスを再構築するには、データベース内の最大インデックスの120%のみが必要です。SORT_IN_TEMPDBを使用する場合、20%しか勝ちませんが、データファイルにはさらに100%が必要です。さらに、tempdbでsortを使用すると、データファイルに1回インデックスを書き込む代わりに、tempdbに1回書き込み、データファイルに書き込むため、IO負荷が大幅に増加します。だから、それは常に理想的ではありません。

SANの構成が遅い/構成が間違っている可能性があるため、IO負荷を絶対に増やしたくありません。

これをテストする最良の方法は何でしょうか?オプションを使用して、または使用せずにテーブルを再構築し、時間を記録するだけですか?

編集:8つのtempdbファイルがあり、それぞれ15GBです。TF 1117/1118フラグが設定されており、IFIが有効になっています。現在、sort_in_tempdbオプションを使用する場合と使用しない場合の再構築を混合しています。

ありがとう!

SQL Server 2012エンタープライズ

回答:


22

SORT_IN_TEMPDBtempdb、インデックスが再構築されているユーザーデータベースにスペースを割り当てるのではなく、SQLサーバーが一時スペースの割り当てに使用することを意味します。これは、インデックスの再構築操作中にユーザーデータベースに必要な空き領域が少なくなり、tempdbに空き領域が増えることを意味します。

tempdbがユーザーデータベースとは異なるディスク(LUN)のセット上にある場合、より優れた利点が得られます。

SORT_IN_TEMPDBオプション-BOLから:

場合SORT_IN_TEMPDBオプションをONに設定し、tempdbのは、ディスクの別のセットになっている先のファイルグループから、第一段階の間に、ページがtempdbの中のソート作業領域への書き込みとは別のディスクに発生したデータを読み込みます。つまり、データキーのディスク読み取りは通常、ディスク全体でより連続的に続行され、tempdbディスクへの書き込みも通常、最終インデックスを作成するための書き込みと同様に連続します。他のユーザーがデータベースを使用して別々のディスクアドレスにアクセスしている場合でも、SORT_IN_TEMPDBが指定されている場合はそうでない場合よりも、読み取りおよび書き込みの全体的なパターンがより効率的です。

SORT_IN_TEMPDBがONの場合ディスク容量の要件を必ずお読みください。

低速/おそらくSANの設定ミス

あなたは痛みのポイントを知っています。SAN管理者と協力して修正しませんか?SANの構成が間違っていたり、低速であったりすると、低速などのあらゆる種類の問題が発生します。

注意すべき重要な点:

これをテストする最良の方法は何でしょうか?

はい、インデックスの有無にかかわらず、インデックスを再構築するときにwaitstatsを分析してテストする必要がありますSORT_IN_TEMPDB。実行時間も測定し、PRODで実行する場合は、メンテナンスウィンドウまたはサーバーアクティビティが少ない時間に実行してください。また、読み取り/書き込みデータとログ遅延を確認します

私はあなたが持っていないですインスタントファイルの初期化を、それは、データファイルの自動拡張時に、復元するときと(ちょうど完全性のために言及する)新しいデータベースを作成するときに利益になります。


tempdb構成でコメントを編集しました。おかげで、シリアルオンライン再構築のヒントについては知りませんでした。さらにテストを行って、残念ながら歓迎されていないSAN管理者とのやり取りを試みます。比較する必要のある特定のwaitstats(たとえば、PageIOLatch)はありますか?tempdbの書き込みは非常に高く(4000ミリ秒)、これは恐ろしいです。メインDBで40ミリ秒未満。それはまた別の質問かもしれません...!
ゲイブ

@Gabe SAN管理者に、それが実際にSANの問題-読み取り/書き込みの遅延-sys.dm_io_virtual_file_statsであるという適切な事実を示す必要があります。tempdbは別のLUNにありますか?
キンシャー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.