SQL Server 2014でのフルスキャンによる統計の更新では100％のCPUを使用し、2008 R2では15％を使用します

フルスキャンの更新統計では、SQL Server 2008 R2でCPUの20％を使用しているのに、同じテーブルで同様のハードウェア機能を使用しているのに、SQL Server 2014でCPUの100％を使用するのはなぜですか？

私はMAXDOP他のオプションを検討してきましたが、特に目立つものは何もありません。これを引き起こす可能性のある設定があることは承知していますが、設定は両方のデータベースで非常に似ています（たとえば、MAXDOP両方とも4で、両方に複数のコアがあります）。どちらもEnterprise Editionです。

これを説明できるSQL Server 2014とSQL Server 2008 R2で「異なる」ものはありますか？どちらのサーバーでも、メモリオプションは90％です。何を探すべきかについての考えはありますか？

SQL Server 2008 R2 / SP3とSQL Server 2014 / SP2を使用する2台のサーバーで、フル（100％）スキャンによる統計更新を週に1回実行します。データベースの構造は同じです。2008 R2サーバーでは、2つの非常に大きなテーブルの統計の更新に数時間かかりますが、これは予想どおりですが、CPUは使用率全体で20％未満にとどまります。ただし、2014サーバーでは、CPUは約40分間100％になります。2014サーバーではテーブルが少し小さくなっています。SQLモニターの分析メニューを使用してこれを確認します。

2014 SQL ServerのOlaログファイルの出力は次のとおりです。CPUは、約2:10から2:45まで100％になります。

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  

Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

上記の2つの統計の2008 R2 SQL ServerのOlaログファイルの出力は次のとおりですが、CPUはおそらく15％になります。

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  

Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

サーバーのmaxdop = 1でこれらを実行することはできません。これにより、すべての並列プランの生成が排除され、アプリケーションに悪影響を与える可能性があります。私は反対方向に進み、それを8に増やし（ボックスには16コアがある）、何が起こるかを確認する予定です。CPUがペグされる時間を短縮するために、より高速になる場合があります。このジョブは、ユーザーがほとんどいない間に実行されます。

統計の更新は、SQL Serverのさまざまなオプションに基づいて並行して実行できます。

• 並列処理のコストしきい値 -並列処理トレインに乗るには、クエリがこれほど高い必要があります。2台のサーバーで異なるCTFP設定を使用すると、2008R2の更新がシングルスレッド化されますが、2014年のサーバーではマルチスレッド化されます。
• Max Degree of Parallelism -SQL Serverが最大で並列化することを決定した場合に、クエリが使用できるコアの最大数を決定します。2008R2ボックスではMAXDOPが1に設定されている可能性がありますが、2014ボックスではMAXDOPがデフォルトの0（無制限）に設定されている可能性があります。
• リソースガバナー -このEnterprise Edition機能を使用すると、ユーザーまたはアプリケーションのさまざまなグループをさまざまなMAXDOPに調整できます。

SQL Serverの新しいバージョン（2016以降）では、これはさらに複雑になります。

• データベースレベルのスコープオプション - データベースを右クリックしてプロパティに移動し、そのデータベースのMAXDOPレベルを設定できます。
• 統計の並列処理のヒント -2016 SP2以降、統計の作成および更新ステートメントはMAXDOPヒントを受け入れます

お気づきのように、2008R2はシングルスレッドで実行されますが、2014はマルチスレッドで実行されます（したがって、より速く終了しますが、実行中にCPUを最大限に活用します）。

統計ジョブの適切なバランスを見つけるには、次のことを考慮してください。

• 他にどのようなワークロードがデータベースで同時に発生していますか？短期間にボックスを支配する余裕はありますか？たとえば、週末のほとんどの時間はアイドル状態になっているデータウェアハウスでは、誰もがサーバーを使用していないことを知っているときに、フルスキャンを使用して統計の更新に熱心に取り組んでいます。ヘビーデューティトランザクション環境では、ユーザーが深夜でも不平を言った場合、メンテナンスタスクへの影響を少なくする必要があります。
• フルスキャンは本当に必要ですか？フルスキャンオプションを使用した場合にのみ適切な計画が得られるクエリを表示していますか、それとも単にベストプラクティスとして実行しているだけですか？データベースが拡大するにつれて、ハードウェアへの投資が追いつかない場合は、フルスキャンを実行するのではなく、統計情報のサンプリングでトレードオフを開始する必要がある場合があります。
• 統計の更新頻度を減らすことはできますか？たとえば、毎週末に統計の1/4を更新し、その後毎月、すべての統計を更新しますか？
• より少ないオブジェクトを更新できますか？数十の新しい挿入が行われたという理由だけで、巨大な監査テーブルまたはアーカイブテーブルでも統計を更新している人がよく見られますが、それらの挿入はテーブルの統計に実際には影響しません（そして、誰もそれをクエリしていません）。

_{コミュニティwikiの回答：}

推測：統計を更新するために選択された計画は、2008 R2ボックスよりも2014ボックスで並列か、より並列です。

の並列更新統計はfullscan2005年以降であり、2016年以降のサンプル統計については、SQL ServerデータベースエンジンブログのGjorgji GjeorgjievskiによるSQL Server 2016のクエリオプティマイザーの追加を参照してください。

Enterprise Editionを使用している場合は、リソースガバナーを使用して、メンテナンスジョブで使用されるCPUを制限できます。

また、Javier VillegasによるUpdate Statsへの Connect提案のAdd MAXDOPパラメーターの投票も検討してください。

関連するQ＆A：並列統計の更新