web-dev-qa-db-ja.com

SQL Server2008-R2データベースでの短期間のブロッキングがたくさん

探している専門家は、私たちが今ほぼ1週間見ている短期間のブロッキングについてアドバイスします。

DBは15 TBであり、この表Bには多くのブロッキングがあります-ほぼ300は2TBです。

Sp_whoisactiveを使用していると、クエリが3〜4秒の短い時間でブロックされ、9〜10秒でブロックされることがありますが、これらは2〜3千を超える接続でほぼ一日中発生するため、アプリケーションで多くのエラーが発生します。

トラブルシューティングが完了しました：

  • NCインデックスの統計を更新しました。NCインデックスとCインデックスが1つずつあります。
  • 歩哨から確認すると、これらのブロックされたステートメントはすべて、上記のテーブルの挿入ステートメントであることがわかります。

以下はいくつかの指標です。

  1. ブロッキングがオンになるまで、過去3〜4時間統計を待ちます
    • PAGELATCH_EX-> 51.1％合計待機数730 513 153.5
    • PAGELATCH_SH-> 23％待機合計343 538 769.7
    • THREADPOOL-> 18％合計待機数257222 894.4
  2. 平均でのバッチ/秒：8612.6
  3. CPUとメモリ-> 256個の論理プロセッサと612GBのRAMがあるため、しきい値をはるかに下回っています
  4. チェックポイントページ/秒-> 1706
  5. 怠惰な書き込み-> 0
  6. ログフラッシュ/秒1844.4
  7. トランザクション/秒9074

davidのクエリによる結果：以下のNote @は、ノードフェイルオーバーを実行してから15分後に実行されました。

 wait_type  wait_time_ms_per_sec
PAGELATCH_EX    733024.4
PAGELATCH_SH    328846.4
CPU_USED    7131.4
WRITELOG    6484.4
DBMIRROR_EVENTS_QUEUE   4973.6
DBMIRRORING_CMD 1456.6
OLEDB   990.2
TRACEWRITE  984.2
SOS_SCHEDULER_YIELD 280.6
THREADPOOL  254
ASYNC_NETWORK_IO    45.4
LATCH_EX    9.4
PAGEIOLATCH_EX  7.6
PREEMPTIVE_OS_GETPROCADDRESS    3.4
MSQL_XP 3.2
DBMIRROR_SEND   1.4
PREEMPTIVE_OS_DELETESECURITYCONTEXT 1
PAGELATCH_UP    0.4
PREEMPTIVE_OS_WAITFORSINGLEOBJECT   0.4
PREEMPTIVE_OS_AUTHORIZATIONOPS  0.2
PREEMPTIVE_OS_AUTHENTICATIONOPS 0.2
SOS_RESERVEDMEMBLOCKLIST    0.2
CMEMTHREAD  0.2

追加のトラブルシューティングの提案を提供し、さらに必要なメトリックがあるかどうかをお知らせください。

Edit @ MAXDOP 8を使用しており、par'smのコストしきい値はデフォルトに設定されています-5

更新：そのような変更は行われていません。夜間に接続が切断された場合、今のところチェックされているように、突然問題が消え、ブロックされていないように見えます。以下は現在の統計です

OLEDB   11883.8
WRITELOG    11732.2
DBMIRROR_EVENTS_QUEUE   4969.8
CPU_USED    4093.75
DBMIRRORING_CMD 1457.2
TRACEWRITE  1080.2
PAGEIOLATCH_SH  333.4
PAGELATCH_EX    237.4
PAGELATCH_SH    31.4
ASYNC_NETWORK_IO    30.2
SOS_SCHEDULER_YIELD 6
LATCH_EX    4.4
DBMIRROR_SEND   1.6
PREEMPTIVE_OS_AUTHENTICATIONOPS 1.4
MSQL_XP 1.2
PREEMPTIVE_OS_GETPROCADDRESS    1.2
PAGELATCH_UP    0.4
PREEMPTIVE_OS_DECRYPTMESSAGE    0.4
SOS_RESERVEDMEMBLOCKLIST    0.4
PREEMPTIVE_OS_DELETESECURITYCONTEXT 0.2
PREEMPTIVE_OS_WAITFORSINGLEOBJECT   0.2
CMEMTHREAD  0.2
PREEMPTIVE_OS_AUTHORIZATIONOPS  0.2
PREEMPTIVE_OS_CRYPTACQUIRECONTEXT   0.2
PREEMPTIVE_OS_NETVALIDATEPASSWORDPOLICY 0.2

今日見たときのように、どのように、そしてなぜそれが起こったのかわからないが、それらの多くの接続は見られず、ブロッキングも見られない。しかし、それは確かにすぐにポップアップします

Update @その背中と同じ待機で見えます

enter image description here

sql-serversql-server-2008-r2blockingwaits
2
BeginnerDBA

この：

wait_type  wait_time_ms_per_sec
PAGELATCH_EX    733024.4
PAGELATCH_SH    328846.4
CPU_USED    7131.4
WRITELOG    6484.4

ラッチ競合の問題があり、ラッチ競合の問題のみがあることを示します。

以来

以下の@は、ノードフェイルオーバーを実行してから15分後に実行されました

CPU_USED行は正確である必要があります。そのため、ワークロードは1秒あたり7秒のCPU時間を使用することしかできません。これは、7コアでのみ実行されているようなものです。その間に、1000秒のページラッチ時間があります。つまり、平均して1000セッションがページのラッチを待機しており、有用な作業を実行しているのは7つだけです。

また、非常に大規模なサーバーで非常に古いソフトウェアを実行しています。このサーバーのスループットはかなり高く、サポートする操作が重要であることを示しています。ユーザー名も考慮してください。したがって、マイクロソフトサポートまたはこの種の専門知識を持つパートナーを強く関与させることを検討する必要があります。

そうは言っても、次のステップは、ラッチ待機の原因を特定することです。通常、これらはデータベースのテーブルのホットページ、またはTempDbのシステムページのいずれかにあります。 sys.dm_exec_requests.wait_resourceはどちらを教えてくれるはずです。

Tempdbの場合、 SQL Server tempdbでの割り当ての競合を減らすための推奨事項 。

データベース内のテーブルの場合は、テーブルのDDL（インデックスを含む）とブロックしているクエリの詳細を投稿します。

SQL 2008でのラッチ競合の診断と解決に関するホワイトペーパーがここにあります： SQL Serverでのラッチ競合の診断と解決

5
David Browne - Microsoft

待機の51％はPAGELATCH_EXが原因で、23％はPAGELATCH_SHが原因です。 -）。

この投稿 に、この待機タイプに関するいくつかの貴重な情報があります。ここで少し引用します

この待機タイプは、スレッドがメモリ内のデータファイルページ（通常はテーブル/インデックスからのページ）へのアクセスを待機して、ページ構造を変更できるようにする場合です（EX =排他モード）。右側のサイドバーにあるラッチホワイトペーパーには、すべてのラッチモードと他のラッチモードとの互換性についての説明があります。

PAGELATCH_XX競合の一般的な原因は次のとおりです：

  • Tempdb（同じビットマップを変更しようとする複数のスレッドのPAGELATCH_UP）での割り当てビットマップの競合、および極端な負荷の下で、
    ユーザーデータベース内
  • テーブル/インデックス挿入ホットスポット（同じページに挿入するスレッドの場合はPAGELATCH_EX、そのページから読み取るスレッドの場合はPAGELATCH_SH）
  • ランダム挿入による過剰なページ分割（ページの行を挿入/更新しようとするスレッドの場合はPAGELATCH_EX、場合によってはPAGELATCH_SHの場合）
    そのページから読み取るスレッド）

PAGELATCH_XXがsqlperformance.comで待機するトラブルシューティングに関する長い記事 上記の最初の2つのケースをカバーし、基本的に関連するページリソースから競合の原因を特定し、そこからさらにトラブルシューティングします。 3番目のケースのトラブルシューティングには、どのインデックスがページ分割を受けているかを把握し、通常はフィルファクターと定期的なインデックスメンテナンスを実装することが含まれます。 このブログ投稿 のページリソース（sys.dm_os_waiting_tasksから）からテーブルを識別するためのワークフローを取得できます。

3
Scott Hodgin