tempdbへのハッシュ/ソートの流出の頻度はどのくらいですか？
私たちのエンタープライズアプリケーションはデータストレージにSQL Serverを使用し、主にOLTPシステムです。ただし、アプリケーションの重要なコンポーネントは重要なOLAPワークロードを生成します。
Tempdbへの書き込み待ち時間は約100msです。この傾向は長期にわたって保持され、ALLOW_SNAPSHOT_ISOLATIONをオンにしますoff。私たちはこれに関して問題のトラブルシューティングを行っていますが、これまでに見つかった唯一の興味深いことは、tempdbへのハッシュとソートの流出が非常に多いことです。これは、OLAPワークロードによるものと考えられます。
質問
流出の頻度はどの程度ですか？どれか？ 1秒あたりの流出回数は？予備データによると、毎秒約2回のハッシュ流出と1分あたり25回のソート流出があります。
この流出の頻度が、tempdbの書き込み待ち時間が長い主な原因である可能性はありますか？
その他の情報
コアの数ごとに推奨されているように、tempdbには複数のファイルを使用しています。 tempdbファイルはRAID 1 + 0上にありますSAN（高性能SSDを使用）非常にまれです。トレースフラグ1117または1118を使用していません。別の変数は、このセットアップが、すべて中程度から高い負荷がかかる多数の異なるデータベースで共有されていることです。
100ミリ秒の書き込みレイテンシは、MSDN、SQLスキル、その他のサイトで見つかったtempdb書き込みレイテンシの許容範囲よりもはるかに大きくなっています。ただし、他のデータベースの書き込みレイテンシは良好です（10ミリ秒未満）。他の統計によると、特に内部オブジェクトに対してtempdbを多用しているようです。したがって、アプリケーションが内部オブジェクトを非常に多く使用している理由を調べるために掘り下げています。
私たちのプラットフォームには、さまざまな形で現れる実際のパフォーマンスの問題があります。私たちはパフォーマンスカウンターを監視し、DM=ビューを確認し、アプリの動作を分析して、システムのリソース使用特性を掘り下げようとしています。現在、流出に焦点を当てています。流出はメモリ内ではなくディスク上で実行されるため、劇的な悪影響があることを読んだことがあります。流出数は非常に多いようですが、人々が「高」と見なしていることについて何らかの情報を得たいと思いました。
このような頻度の流出が、tempdbの書き込み待ち時間が長くなる主な原因である可能性はありますか？
はい、それは可能ですですが、通常は流出の平均サイズとその深さ（つまり、再帰ハッシュ流出、マルチパスソート）です。それ自体が周波数よりも重要です。
SQL Serverは、tempdb圧力に対するさまざまな要因のトラブルシューティングに役立つさまざまなメトリックとDMV情報を提供します。これらの多くは、Microsoftの技術記事 "SQL Server 2005でのtempdbの使用" で説明されています。 （2005以降のすべてのバージョンに適用されます）。
そのドキュメントに含まれているガイダンスと診断クエリを使用して、tempdbの圧力の主な原因の特定を開始できるはずです。無視しないでください。バージョンストアアクティビティは単にALLOW_SNAPSHOT_ISOLATIONが有効になっていません。スナップショット分離の他に、多くの機能がバージョンストア（トリガー、MARS、RCSIなど）を使用します。
並べ替えとハッシュの流出が高レベルで重大であることが判明した場合は、おそらくこれについて特定の監視を設定する必要があります。 SQL Serverのバージョンによって多少異なりますが、これは必ずしも簡単なことではありません。並べ替えとハッシュの流出を、それらを引き起こした特定のクエリに関連付けるには、イベント通知または拡張イベントが必要です。 SolidQの記事「 ソートの警告の特定と解決 」には、詳細と、一般的な原因の解決に関するいくつかの優れた一般的なアドバイスが含まれています。
また、ストレージチームと協力して、ワークロードに起因する高レイテンシの大きさ、他の共有使用によるもの、および再構成のためのオプションを特定する必要があります。 SQL Serverのメトリックの分析は、SANの人々が提供できるすべてのメトリックと同様に、このディスカッションの通知に役立ちます。