高PAGELATCH_ *およびWRITELOG待機。それらは関連していますか？
非常に高いPAGELATCH_EXおよびPAGELATCH_SH待機タイプと、高いWRITELOG待機が見られます。 PAGELATCH待機を引き起こすクエリを診断しました。IDENTITY値で定義されたビジーなクラスター化された主キーへの挿入率を下げることで、それらを排除できます。この現象は、最終ページ挿入ラッチ競合として知られていると理解しています。
ただし、私の質問は、新しいレコードが挿入されたとき、SQL Serverがバッファーページで排他的なPAGELATCH_EXを取得し、レコードをバッファーページに挿入しますトランザクションログにレコードを書き込みます次に、詳細なPAGELATCH_EXを解放します https://www.Microsoft.com/en-ie/download/details.aspx?id=26665 ページ24.または、「非常に並行性の高いINSERTのワークロードでのPAGELATCH競合の解決-バックグラウンド情報 SQLCATガイド：リレーショナルエンジン 」のように、PAGELATCH_EXを取得する前に、最初にトランザクションログにレコードを書き込みます
レコードがラッチメカニズムの外部のログに書き込まれる場合、PAGELATCH待機が高くなる原因として、ディスクへの遅い書き込みを除外できます。しかし、レコードがログに記録できるようになるまでラッチが保持される場合は、おそらくWRITELOGを考慮する必要があります。
また、複数の非クラスター化インデックスがあると、PAGELATCH_ *ラッチがより長く保持されます。つまり、テーブルにクラスター化されていて、複数の非クラスター化インデックスがラッチに追加され、各インデックスバッファーページに同時に解放される場合はどうでしょうか
Update 1読んだ後 confio-sql-server-writelog-wait スライド2と一般的なWALアーキテクチャ。両方のホワイトペーパーで説明されている「行が変更されたログエントリを記録する」手順は、SQL Serverがディスクではなくトランザクションログキャッシュに変更を記録することを指していることを理解しました。トランザクションが完了するか、バッファがいっぱいになると、すべてのレコードがすぐにディスクにフラッシュされます。
ただし、私の質問は、新しいレコードが挿入されたとき、SQL Serverがバッファーページで排他的なPAGELATCH_EXを取得し、レコードをバッファーページに挿入し、レコードをトランザクションログに書き込んでから、排他的なPAGELATCH_EXを解放することです。
ラッチは、ページがメモリ内にあるときにのみページの物理的な整合性を保護するため、ページがメモリ内にあるときにラッチが取得されることに注意してください。レコードが挿入されており、そのページをフェッチする必要があるとします。最初に、ページがロックされてメモリに読み込まれ、次にラッチされて情報が書き込まれます。この後のプロセスは
ログレコードを生成する
ログレコードのページLSNと一致するようにページLSNを更新する
データの変更（ページの汚れ）
リリースラッチ
トランザクション開始のコミット
コミットのFlushToLSN
ロックを解除する
トランザクションのコミットが完了しました
上記の手順の詳細と説明については、 Bob DorrのI/Oプレゼンテーションブログをご覧ください
Pagelatch *の待機は非I/O待機であり、割り当ての競合のために、これらの待機が目立つようになることがよくあります。私の直感は、それがtempdb is configured。 tempdbはどのように構成されていますか？tempdbデータファイルはどのくらい存在しますか？ 確認してくださいそれらは同じ自動拡張と同じサイズを持っています。新しいページが作成されると GAM、SGAMおよびPFSページ などのシステムページが更新またはアクセスされる必要があり、SQL Serverがこれらのページへのアクセスで競合を検出すると、このような待機が発生します。