tempdbにファイルを追加する場合のホットスポットとは何ですか？
SQL Serverサービスを再起動せずにtempdbファイルをSQL Serverに追加できるかどうかを確認しようとしています。私はここでデータベース管理者にこの答えを見ました：
そして一つの答えは次のように述べています：
追加-停止は必要ありません。 MicrosoftのSeanが指摘したように、SQLは低い方のファイルを使用することを好みます。 1つのデータファイルから追加する場合、SQLは新しいデータファイルをしばらく使用しますが、ファイルが1つしかない場合よりパフォーマンスは低下しません。ただし、すでに2+があり、もう1つ追加すると、新しいものにホットスポットが発生し、パフォーマンスが低下します。
ただし、コメントは次のことを警告しています。
「追加」の部分に補遺を追加します。「追加：いいえ。ただし、アンバランスになる可能性が高いので、ホットスポットが発生し、事態がさらに悪化する可能性があります。」
私はそのコメントについて次の質問がありますが、その質問の回答のコメントからコメントを求めるのではなく、自分自身（これ）の新しい質問でそれらの質問をするように指示されました。
具体的には：
- ホットスポッティングとは何ですか？ （私はいくつかの情報をGoogle経由で取得しましたが、ファイルを追加した後のtempdbのホットスポットで何が起こるか詳細ではありません）
- Tempdbのホットスポッティングについてはどうでしょうか？
- DBのどの特定のものがはるかに悪化しますか？
ホットスポッティングとは何ですか？
この文脈での「ホットスポッティング」とは、tempdbに複数のファイルがある場合でも、すべてのI/O作業が1つのファイルで実行されていることを意味します。 tempdbがファイルの追加を正当化するのに十分なほどビジーである場合、ホットスポットにつながる不均衡（ プロポーショナルフィル による）は一時的なものになるため、警告は少しチキンリトルかもしれません。私の経験では、とにかく。
tempdbのホットスポッティングについてはどうでしょうか？
Tempdbでは、ほとんどのワークロードで書き込みアクティビティの矢面に立つため、これはより悪いと思われます。ユーザーデータベースでも同様の問題が発生する可能性がありますが、tempdbの問題を解決しようとしているためです...
DBのどの特定のものがはるかに悪化しますか？
時間を書きます。近くに他の7つのATMがある場合でも、全員が同じATMを使おうとしていると想像してください。いつでも書き込めるのはそれほど多くありません。他のすべては待つ必要があります。より多くのファイル（および作業をスケジュールするのに十分なコア）を使用すると、I/Oをより均等に分散できます。
ただ確認してください：
- あなたは偶数のファイルを持っています
- すべてのファイルは同じサイズです
- すべてのファイルに同じ自動拡張設定があります
- ファイルの数は コアの数によって決まります
- バージョンに応じて（これらはデフォルトで有効になっています SQL Serverのより新しいバージョンでは ）、あなたは トレースフラグを使用 1117（すべてのデータファイルを一度に拡張します）および 1118 （混合割り当てエクステントは使用しないでください）。
- ホットスポッティングとは何ですか？
アーロンは正しいです、そして私は彼が上で言ったことをリハッシュするつもりはありません、しかしそれは単にディスクIOについてではありません。 TempDBでほとんどの人が問題を抱えている主な部分は、特定の追跡構造の競合によるものです。
複数のtempdbファイルを使用すると、プロポーショナルフィルおよびラウンドロビンアルゴリズムを割り当て全体で効果的に実行できるため、割り当てのない新しいファイルを追加すると、ビットが少し失われます。 PAGELATCH_*が新しいファイルを待機していて、他のファイルで待機していない場合、「チキンリトル」警告（以下の製品の更新を参照）であることに同意しません。これは一般には、TempDBアクティビティが高く、すでに複数のファイルがあるシステムで発生します。
SQL Server 2019には、基盤となる システムテーブルをインメモリテーブルに を変更するオプションがあることに注意してください。これは、メモリ内オブジェクトがディスクベイクテーブルとは異なる方法で割り当てられるため、改善される可能性があります。ディスクベースのテーブルは、私たち全員が長年にわたって取り組んできた従来のテーブルです。 SQL Server 2014では、メモリ最適化テーブルが導入されました。 SQL Server 2019は、メモリ最適化テーブルの一部の割り当てメタデータを処理できます。
SQL Server 2019では、同時PFSの変更を支援するために別の変更が行われました。これは、通常、割り当てにおけるメモリ内構造の競合がPAGELATCH_*待機しているものです。
- Tempdbのホットスポッティングについてはどうでしょうか？
何も私見。はい、TempDBには、直接使用しないと書き込みを引き起こす可能性のある項目が多いため、一部の項目が妨げられる可能性があります。ただし、データ変更率の観点から見ると、非常にビジーなユーザーデータベースも同様に悪いです。 TempDBだけに限定されません。
- DBのどの特定のものがはるかに悪化しますか？
私はアーロンのアナロジーが本当に好きです！それが何が起こっているかの本質です。実際に悪化するのは、データベース内のオブジェクトの領域の割り当てと追跡です。ユーザーデータベースがほとんど静的である（変更率が低い）場合、またはTempDBが実際に使用されていない場合は、何もわかりません。ただし、それがかなりビジーなサーバーである場合は、ページラッチの待機を開始または悪化させ、コンボイをブロックする可能性があります。
Aaronは、以前のバージョンでは、均一なエクステントが使用され、ファイルグループ内のすべてのファイルが一緒に成長することを確認するトレースフラグがあることをすでに指摘しています（Aaronは、2016 +ではNOPである1117および1118を指摘しています）。もう1つ指摘しておきたいのは、これはTempDBだけでなく、どのデータベースの場合もあり、物理レイアウトはニーズに応じて十分に検討する必要があることです。
これはホットスポットの問題だけでなく、バックアップ/復元、ファイル管理、ファイルシステムメタデータの断片化など、システムの他の部分にも当てはまります。これらはすべて、複数のファイルがあると役立ちます。
PFSページ（ページ1、次に8088ページごと）でwaitresourceを検索すると、割り当て構造の競合を確認できます。同じファイル（2：file：page）にすべてが表示されている場合、これが発生していることがわかります。