R2SP1へのアップグレード後にピークに達するSLEEP_TASKおよびPAGELATCH_XX
この質問にコメントを追加したかっただけです： SQL ServerのSLEEP_TASK待機タイプ-それは何を示していますか？ しかし、私はSLEEP_TASK待機だけでなくPAGELATCH_SHも持っていますおよびPAGELATCH_EX待機タイプ。また、データが多すぎるため、新しい質問をする必要があると思いますが、重複していると見なされるリスクが存在することはわかっています。
参照された質問と同様に、数週間前にいくつかのサーバーをSQL Server 2008SP3から2008R2SP1（10.52.2500.0）にアップグレードしました。この時点から、データベース要求のタイムアウトに気づき始めました。ますます多くのタイムアウトが発生しているため、昨日はすでに問題になっています。監視には、 Adam Machanic sp_whoisActive と Kendra結果をログに記録するための小さな手順 を使用しています。 @delta_interval=2を使用して4分ごとにwhoisactiveを実行するようにジョブを構成しましたが、20秒ごとに5回実行されます。また、2分ごとに実行されるテーブルの待機統計を取得するジョブを設定しました。
以下に投稿する結果から、sleep_taskとpagelatch_xxの待機タイプがたくさんあることに気づきました。他に何も変更されておらず、開発プラットフォームに新しいリリースもありません。 SQLServerを2008R2SP1に更新するだけで、システム管理者はWinSvr2012R2Standardに現在のwindwosパッチを適用しました。
Tempdの競合、待機タイプなどに関する多くの参照を確認しました。
- 統計を待つか、どこが痛いのか教えてください
- ページ1,2,3の競合
- トラブルシューティング：Tempdbの競合
- tempdbには常にプロセッサコアごとに1つのデータファイルが必要です （はい、すでにいくつかあります）
何が起こったのかを理解しようと夢中になっています。何か案が？
WhoIsActiveの結果の一部：
| collection_time | dd hh:mm:ss.mss | wait_info | Host | db | CPU | reads | physical_io |
|-------------------------|-----------------|-----------------------------------|------|-----|-----|--------|-------------|
| 2014-05-20 14:25:30.253 | 00 00:00:00.080 | (1x: 8ms)SLEEP_TASK | W2 | ss2 | 15 | 493 | 28 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.080 | (1x: 2ms)PAGELATCH_EX:tempdb:1(*) | W8 | ss2 | 16 | 1,541 | 1 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.080 | (1x: 7ms)SLEEP_TASK | W2 | ss2 | 16 | 489 | 34 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.083 | (4ms)PAGELATCH_EX:tempdb:1(*) | W2 | ss2 | 16 | 1,429 | 2 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.086 | (1x: 2ms)SLEEP_TASK | W2 | ss2 | 47 | 488 | 36 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.100 | (5ms)PAGELATCH_EX:tempdb:1(*) | W8 | ss2 | 15 | 4,347 | 1 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.106 | (1x: 1ms)SLEEP_TASK | W1 | ss2 | 78 | 530 | 34 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.110 | (2ms)PAGELATCH_EX:tempdb:1(*) | W8 | ss2 | 15 | 853 | NULL |
| 2014-05-20 14:25:30.253 | 00 00:00:00.110 | (1x: 7ms)SLEEP_TASK | W1 | ss2 | 109 | 490 | 28 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.113 | (1x: 1ms)RUNNABLE | W3 | ss2 | 62 | 489 | 28 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.116 | (4ms)PAGELATCH_SH:tempdb:1(*) | W1 | ss2 | 47 | 14,201 | 2 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.116 | (1ms)IO_COMPLETION | W3 | ss2 | 94 | 30,762 | 21 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.120 | (1x: 6ms)SLEEP_TASK | W3 | ss2 | 16 | 507 | 30 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.120 | (12ms)SLEEP_TASK | W3 | ss2 | 62 | 513 | 31 |
| 2014-05-20 14:25:30.253 | 00 00:00:00.123 | (1x: 2ms)RUNNABLE | W1 | ss2 | 0 | 791 | 1 |
合計待機結果の一部は次のとおりです。
| wait_type | wait_time_s | pct | running_pct |
|----------------------------------|-------------|-------|-------------|
| SLEEP_TASK | 301.00 | 41.58 | 41.58 |
| LAZYWRITER_SLEEP | 151.00 | 20.88 | 62.46 |
| CHECKPOINT_QUEUE | 65.00 | 9.00 | 71.46 |
| SQLTRACE_INCREMENTAL_FLUSH_SLEEP | 32.00 | 4.42 | 75.88 |
| LOGMGR_QUEUE | 30.00 | 4.14 | 80.02 |
| XE_TIMER_EVENT | 30.00 | 4.14 | 84.16 |
| REQUEST_FOR_DEADLOCK_SEARCH | 30.00 | 4.14 | 88.30 |
| WAITFOR | 23.00 | 3.18 | 91.47 |
| OLEDB | 17.00 | 2.40 | 93.87 |
| BROKER_TO_FLUSH | 14.00 | 1.99 | 95.87 |
実行中の待機率：
| wait_type | diff | wait_time | max_wait | diff_signal | diff_elapsed | last_time_stamp | previous_time_stamp |
| | waiting tasks | ms | time_ms | wait_time_ms | time_ms | | |
| | count | | | | | | |
|-----------------------------------|---------------|-----------|----------|--------------|--------------|-------------------------|-------------------------|
| SLEEP_TASK | 25100 | 301554 | 1698 | 7891 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| OLEDB | 24161 | 17416 | 15061 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| MSQL_DQ | 2229 | 8111 | 2023 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PREEMPTIVE_COM_QUERYINTERFACE | 2229 | 8109 | 2023 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| SOS_SCHEDULER_YIELD | 40102 | 4929 | 1954 | 4900 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| ASYNC_NETWORK_IO | 81 | 3053 | 2013 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PAGELATCH_EX | 5348 | 988 | 1927 | 535 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PREEMPTIVE_OS_CRYPTACQUIRECONTEXT | 2229 | 654 | 40 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PREEMPTIVE_OS_REVERTTOSELF | 6699 | 630 | 38 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PREEMPTIVE_OS_CRYPTIMPORTKEY | 6687 | 500 | 30 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PAGEIOLATCH_SH | 88 | 491 | 4855 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PREEMPTIVE_OS_SECURITYOPS | 6687 | 451 | 46 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| PAGELATCH_SH | 4633 | 438 | 1933 | 276 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| IO_COMPLETION | 474 | 74 | 237 | 2 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
| WRITELOG | 38 | 62 | 1624 | 0 | 30013 | 2014-05-20 17:36:30.933 | 2014-05-20 17:36:00.920 |
はい、データベースの1つに多くの挿入があり、ログを記録しています（ログを少なくしようとしていますが、現時点では不可能です）。 Fusion IOドライブにメインデータベース、ログファイル、tempDBがあり、RAID10には他のすべてのものがあります。
OLEDBはリンクサーバーへの呼び出しであり、現時点では避けられません。私の主な懸念は、数週間前にはそのような大きなタイムアウトがなかったのに、今では突然タイムアウトが発生することです。参照されている質問を見つけて、サーバーのアップグレードによって、私たちが気付いていない奇妙な動作が引き起こされる可能性があると思いました。
スリープとキューの待機は無視してください。これらは、定義上、常に高くなるため、除外する必要があります。彼らは毎分1分間の待機を収集します。 PAGELATCHは、ついていけないと言っています。とはいえ、それがここでの大きな問題だとは思いません。
ラッチの競合については、 このホワイトペーパー を検討してください。ただし、OLEDBとMSQL_DQの待機についてはもっと心配します。大量のクロスサーバー作業を行っていますか？これのいずれかを統合できますか、またはこれらのものは非SQL Server RDBMSプラットフォームと通信していますか？
2008-> 2008 R2で重大な問題が発生することはないと思いますが、plan/perfの一般的な原因であるため、すべての場所で統計を更新したことを確認する必要があります（FULLSCANを使用して、できればメンテナンスウィンドウ中に）アップグレードまたは移行後の劣化。
ただし、最新のブランチにアクセスして、利用可能な最新のCUをインストールすることも強く検討します。また、2008R2の主流のサポートは2か月で終了することにも注意してください。
また、Fusion GUIDがあり、ラッチが2秒を超えることもあるため、クラスター化されたIOは常にIDENTITY列よりも優れているというThomasの考え方を支持することを躊躇します。 、明らかに問題に高速I/Oをスローしても何も解決されないため、再設計を検討する必要があるかもしれません。
一部のエッジケースの啓蒙については、 この投稿 および この投稿 を参照してください（繰り返しますが、これを「ヒープ>クラスター化インデックス」または「GUID>アイデンティティ」の推奨と見なさないでください） 。