tempdbのブロッキングを解決する方法
サーバーの1つ（SQL Server 2008 R2）でtempdbの競合（少なくとも、おそらく）が発生しています。
ブロッカーとウェイターの両方（そのうちの10）は、データベースtempdbでPAGELATCH_EX待機タイプを持ち、すべてのセッション（ブロッカーとウェイター）のwaitresourceは「2：1：122」です。
SQLコードを確認したところ、ほとんどのセッションでテーブル変数が作成されていることがわかりました。これが原因である可能性があります。
さらに診断し、この問題を軽減する方法についての提案は高く評価されます。
PAGELATCH_XX-これは、SQLがデータベースページへのアクセスを待機しているが、ページが物理IOを実行していないことを示します。このクラスの問題は、同じ物理ページに同時にアクセスしようとする多数のspidが原因で発生します。 wait_resourceは、アクセスされているページ番号（形式はdbid：file：pageno）です。ライブサーバーで診断する場合、パフォーマンスダッシュボードレポートはDBCC PAGEを実行し、出力が表示されて、競合の対象となるオブジェクトとページのタイプ（割り当て、データ、テキストなど）が示されます。
SQLが最も頻繁に待機しているページはtempdbデータベース（dbid 2のページ番号）にあるため、tempdb割り当てラッチの競合に直面している可能性があります。
Tempdb割り当てページラッチの競合は、一時オブジェクト（ソートまたはハッシュ操作用のワークテーブル/ワークファイルを含む）を1秒あたり数百または数千回作成および破棄するワークロードで発生する可能性があります。
解決 -
1.トレースフラグ-T1118を実装します。
2. tempdb内のデータファイルの数を増やして、ディスクの帯域幅を最大化し、割り当て構造の競合を減らします。一般的なルールとして、論理プロセッサの数が8以下の場合は、論理プロセッサと同じ数のデータファイルを使用します。論理プロセッサの数が8より大きい場合は、8つのデータファイルを使用し、競合が続く場合は、競合が許容レベルに減少するか、または競合がなくなるまで、データファイルの数を4の倍数（論理プロセッサの数まで）増やします。ワークロード/コードの変更。