tempdbにファイルを追加するコンテキストでのホットスポットとは何ですか？

SQL Serverサービスを再起動せずにtempdbファイルをSQL Serverに追加できるかどうかを確認しようとしています。私はここでデータベース管理者にこの答えを見ました：

• Tempdbファイルの追加には再起動が必要

そして1つの答えは次のとおりです。

追加-停止は不要です。MicrosoftのSeanが指摘したように、SQLはより低い値のファイルを使用することを好みます。1つのデータファイルから追加する場合、SQLはしばらくの間新しいデータファイルを使用しますが、ファイルが1つしかない場合よりもパフォーマンスは低下しません。ただし、すでに2+があり、もう1つ追加すると、新しいホットスポットにホットスポットが追加され、パフォーマンスが低下します。

ただし、コメントでは次の点に注意してください。

「追加」の部分に補遺を追加します。「追加：いいえ。ただし、不均衡になる可能性が高いため、ホットスポットになり、事態がさら​​に悪化する可能性があります。」

私はそのコメントについて次の質問を持っていますが、その質問の回答のコメントを介してコメンターに質問するのではなく、自分の新しい質問（この質問）で質問するように指示されました。

具体的には：

1. ホットスポットとは何ですか？（Google経由で情報を入手しましたが、ファイルを追加した後にtempdbでホットスポッティングを行うと何が起こるか詳細に説明しませんでした）
2. ホットスポットはtempdbの状況をさらに悪化させますか？
3. DBのどの特定のものがさらに悪化しますか？

1. ホットスポットとは何ですか？

   このコンテキストでの「ホットスポット」とは、tempdbに複数のファイルがある場合でも、すべてのI / O作業が単一のファイルで実行されることを意味します。tempdbがファイルの追加を正当化するのに十分なほどビジーである場合、ホットスポッティング（プロポーショナルフィルによる）につながる不均衡は短命になるため、警告は少しチキンリトルかもしれません。私の経験では、とにかく。

2. ホットスポットはtempdbの状況をさらに悪化させますか？

   tempdbでは、ほとんどのワークロードで書き込みアクティビティの負荷がかかるため、これはさらに悪いと考えられます。ユーザーデータベースでも同様の問題が発生する可能性がありますが、既にtempdbの問題を解決しようとしているので...

3. DBのどの特定のものがさらに悪化しますか？

   主に書き込み時間。近くに7台の他のATMがある場合でも、全員が同じATMを使用しようとしていると想像してください。いつでも書けるのはそんなに多くありません。他のすべては待たなければなりません。より多くのファイル（および作業をスケジュールするのに十分なコア）により、I / Oをより均等に分散できます。

   確認してください：

   • 偶数個のファイルがあります
   • すべてのファイルは同じサイズです
   • すべてのファイルに同じ自動拡張設定があります
   • ファイルの数はコアの数によって何らかの形で駆動されます
   • バージョンに応じて（これらはより新しいバージョンのSQL Serverでデフォルトで有効になっています）、トレースフラグ 1117（すべてのデータファイルを一度に成長）と1118（混合割り当てエクステントを使用しない）を使用しています。

1. ホットスポットとは何ですか？

アーロンは正しいですし、彼が上で言ったことを再ハッシュするつもりはありませんが、それはディスクIOだけではありません。ほとんどの人がTempDBで問題を抱えている主な部分は、特定の追跡構造の競合によるものです。

複数のtempdbファイルを使用すると、割り当て間で比例したフィルおよびラウンドロビンアルゴリズムが効果的に「公平」に実行されるため、割り当てのない新しいファイルを追加すると、少しばかりスローされます。PAGELATCH_*上記の新しいファイルを待機し、他のファイルの多くまたはいずれも待機していない場合は、「チキンリトル」警告（以下の製品アップデートを参照）であることに同意しません。これは一般に、 TempDBアクティビティが高く、すでに複数のファイルがあるシステムで発生します。

SQL Server 2019には、基盤となるシステムテーブルの一部をインメモリテーブルに変更するオプションがあり、メモリ内オブジェクトはディスクベイクテーブルとは異なる方法で割り当てられるため、改善できるオプションがあることに注意してください。ディスクベースのテーブルは、私たち全員が長年にわたって取り組んできた伝統的なテーブルです。SQL Server 2014では、メモリ最適化テーブルが導入されました。SQL Server 2019は、メモリ最適化テーブルの一部の割り当てメタデータを処理できます。

SQL Server 2019では、同時PFS変更を支援するために別の変更が行われました。これは一般に、割り当てのメモリ内構造の競合がPAGELATCH_*待機しているものです。

2. ホットスポットはtempdbの状況をさらに悪化させますか？

私見は何もありません。あり ただし、データ変更率の面で非常に忙しいユーザーデータベースも同様に悪いです。TempDBだけに限定されません。

3. DBのどの特定のものがさらに悪化しますか？

アーロンのアナロジーが本当に好きです！それが何が起こっているかの本質です。実際に悪化するのは、データベース内のオブジェクトのスペースの割り当てと追跡です。ユーザーデータベースの大部分が静的（変更率が低い）であるか、TempDBが実際に使用されていない場合、何も気付かないでしょう。ただし、かなりビジーなサーバーの場合は、ページラッチの待機を開始または悪化させる可能性があり、コンボイのブロックにつながる可能性があります。

アーロンは、以前のバージョンには均一なエクステントが使用され、ファイルグループ内のすべてのファイルが一緒に成長することを確認するためのトレースフラグがあることを既に指摘しました（アーロンは2016+のNOPである1117と1118を指摘しています）。もう1つ指摘したいのは、これはTempDBだけでなく任意のデータベースのためのものであり、物理レイアウトはニーズに応じて検討する必要があるということです。

これは、ホットスポッティングの問題だけでなく、バ​​ックアップ/復元、ファイル管理、ファイルシステムメタデータの断片化など、システムの他の部分にも適用できます。これらはすべて、複数のファイルを持つことで役立ちます。

waitresourcePFSページ（ページ1、次に8088ページごと）を検索することにより、割り当て構造の競合を確認できます。すべてが同じファイル（2：file：page）にある場合は、これが発生していることがわかります。