SQL Serverエラーは30日、12日目のTempDBのファイル数と必要はCPUの数と一致していると語った。
誤認認⻠12:TempDBのファイル数と必要はCPU数と一致している。
エラー
えっと、上記の落とし穴はマイクロソフトの「公式」の提案で、しかもこの観点を堅持する多くの博文があります。
しかし、困ったことにSQL CATチームが提案したのは1対1です。しかし、この提案は、一般的な法則ではなく、拡張面の原理から来たものです。彼らが直面している大型顧客データ量サーバーとIOサブシステムはほとんどの人が会う機会がないからです。
各例ではTempDbは一つしか許されていませんが、TempDBを使うところはたくさんありますので、TempDBは性能のボトルネックになりやすいです。皆さんはこの点を知っていると思いますが、ほとんどの人は知らないはずです。どのような状況で追加のTempDBファイルが必要ですか？
PAGELATCHタイプのブロックを見たら、メモリにビットマップを割り当てる際の争用問題が発生しました。PAGEIOLATCHを見て、I/Oサブシステムレベルの争用問題に遭遇したと説明しました。ラッチについては通常のロックと同じものと見なしても良いですが、より軽く、より短く、エンジン内部でのみ使用されます。
MVP Glenn Berryの一編は記事にsys.dm_を調べています。オズwaitスタンツのDMV。このブログであなたのサーバーが一番渋滞している原因は何ですか？もしあなたがPAGELATCH型の待ち時間を発見したら、このスクリプトを使ってFPS、GAMまたはSGAMの争いによる問題点を確認してもいいです。
ラッチ争いに遭ったら、追跡マーク1118またはTempDBファイルをもう一つ作ってこの状況を緩和できます。なぜ追跡マーク1118が依然として必要とされているのかについての長いブログを書きました。リンク：KB 328551。
SQL SERVER 2000時代には、TempDBのファイル数はCPUコア数と1：1の関係を維持する必要があり、SQL SERVER 2005と2008バージョンでもこの提案は適用されますが、SQL SERVER 2005＋後の最適化対策（詳細は私のMisconceptions around TF 1118をご覧ください）のため、CPUコアとTempDBファイル数を厳密に設定する必要はありません。ファイル数とCPUコアの比率を1:2または1:4に維持すればいいです。
[余談：SQL PASS 2011で私の親友のボブWardはSQL CSSの一番偉い人です。新しい数式を示しました。CPUコアが8以下の場合、その比率を1:1に維持します。CPUコアが8以上の場合、8つのファイルを使用します。ラッチ競合現象を発見した場合、毎回4つのファイルを追加します。
でも、これも一概には言えません。先週問題がありました。クライアントのTempDB負荷が32個のCPUと64個のTempDBファイルが必要になってから、ラッチ争いを軽減できます。これはこれが一番いい実践だということを意味していますか？もちろんです。
なぜ1：1の割合が悪いかという疑問があるかもしれませんが、それは多すぎるTempDBが他の性能問題を引き起こす可能性があるからです。いくつかの操作（例えば、並べ替え）にメモリが必要ですが、メモリが足りない場合は、これらをTempDBに割り当てる必要があります。TempDBファイルが複数存在する場合には、TempDBの循環配分メカニズムにより、性能が引きずられる可能性があり、比較的大きな仮テーブルについても同様である。
なぜ循環配分メカニズムはTempDBに大量のファイルがある時に性能問題が発生するのですか？次のような可能性があります。 サイクル割り当てアルゴリズムはファイルグループに対して、TempDBには一つのファイルグループしか存在しない。このファイル群が16または32のファイルを含む場合、巡回割り当てアルゴリズムのスレッドは有限であるが、大量のファイルのTempDBに対してはまだいくつかの追加の同期作業が必要であるため、この部分の作業は性能損失をもたらす。
TempDBのファイルサイズが一致しないと、ある個別ファイルの自動的な増加を招き、ホットスポットIOを引き起こす可能性があります。
バッファがLazyWriterによって若干の空間を解放する必要がある場合（TempDBのCheckpointは書き込み操作を行わない）、複数のTempDBファイルがIOサブシステムのランダムな読み書き問題を引き起こす可能性があり、IO側の性能問題が発生する。 だから、この選択はあなたを進めてもいいです。どのぐらいのTempDBファイルが適切ですか？私もあなたに具体的な解答をあげることができませんが、長年のコンサルティング経験と各種大会に出席した経験に基づいて、ロック争いを解決するために、TempDBのために複数のファイルを作成する時は注意してください。必要な場合だけ、TempDBファイルを追加します。つまり、拡張性と性能のバランスが必要です。
上の指導方針があなたの役に立ちますように。
PS：コメントに答えます。TempDBのファイルは複数のメモリ間に分布する必要がありません。PAGELATCHタイプを見たら、分布しても性能は改善されません。PAGEIOLATCH型の場合、複数のメモリが必要かもしれませんが、これは必然ではありません。TempDB全体を別の記憶システムに移行する必要があります。これはあなたがよく分析してから決めてください。
エラー
えっと、上記の落とし穴はマイクロソフトの「公式」の提案で、しかもこの観点を堅持する多くの博文があります。
しかし、困ったことにSQL CATチームが提案したのは1対1です。しかし、この提案は、一般的な法則ではなく、拡張面の原理から来たものです。彼らが直面している大型顧客データ量サーバーとIOサブシステムはほとんどの人が会う機会がないからです。
各例ではTempDbは一つしか許されていませんが、TempDBを使うところはたくさんありますので、TempDBは性能のボトルネックになりやすいです。皆さんはこの点を知っていると思いますが、ほとんどの人は知らないはずです。どのような状況で追加のTempDBファイルが必要ですか？
PAGELATCHタイプのブロックを見たら、メモリにビットマップを割り当てる際の争用問題が発生しました。PAGEIOLATCHを見て、I/Oサブシステムレベルの争用問題に遭遇したと説明しました。ラッチについては通常のロックと同じものと見なしても良いですが、より軽く、より短く、エンジン内部でのみ使用されます。
MVP Glenn Berryの一編は記事にsys.dm_を調べています。オズwaitスタンツのDMV。このブログであなたのサーバーが一番渋滞している原因は何ですか？もしあなたがPAGELATCH型の待ち時間を発見したら、このスクリプトを使ってFPS、GAMまたはSGAMの争いによる問題点を確認してもいいです。
ラッチ争いに遭ったら、追跡マーク1118またはTempDBファイルをもう一つ作ってこの状況を緩和できます。なぜ追跡マーク1118が依然として必要とされているのかについての長いブログを書きました。リンク：KB 328551。
SQL SERVER 2000時代には、TempDBのファイル数はCPUコア数と1：1の関係を維持する必要があり、SQL SERVER 2005と2008バージョンでもこの提案は適用されますが、SQL SERVER 2005＋後の最適化対策（詳細は私のMisconceptions around TF 1118をご覧ください）のため、CPUコアとTempDBファイル数を厳密に設定する必要はありません。ファイル数とCPUコアの比率を1:2または1:4に維持すればいいです。
[余談：SQL PASS 2011で私の親友のボブWardはSQL CSSの一番偉い人です。新しい数式を示しました。CPUコアが8以下の場合、その比率を1:1に維持します。CPUコアが8以上の場合、8つのファイルを使用します。ラッチ競合現象を発見した場合、毎回4つのファイルを追加します。
でも、これも一概には言えません。先週問題がありました。クライアントのTempDB負荷が32個のCPUと64個のTempDBファイルが必要になってから、ラッチ争いを軽減できます。これはこれが一番いい実践だということを意味していますか？もちろんです。
なぜ1：1の割合が悪いかという疑問があるかもしれませんが、それは多すぎるTempDBが他の性能問題を引き起こす可能性があるからです。いくつかの操作（例えば、並べ替え）にメモリが必要ですが、メモリが足りない場合は、これらをTempDBに割り当てる必要があります。TempDBファイルが複数存在する場合には、TempDBの循環配分メカニズムにより、性能が引きずられる可能性があり、比較的大きな仮テーブルについても同様である。
なぜ循環配分メカニズムはTempDBに大量のファイルがある時に性能問題が発生するのですか？次のような可能性があります。
上の指導方針があなたの役に立ちますように。
PS：コメントに答えます。TempDBのファイルは複数のメモリ間に分布する必要がありません。PAGELATCHタイプを見たら、分布しても性能は改善されません。PAGEIOLATCH型の場合、複数のメモリが必要かもしれませんが、これは必然ではありません。TempDB全体を別の記憶システムに移行する必要があります。これはあなたがよく分析してから決めてください。