そのため、SQL Server 2016では、サンプルモードを使用した統計の更新が互換性レベル130で並行して実行されるようになりました。これは、すべての自動および手動の統計更新に対して、デフォルトでどのように機能するかを示しています。これについては、ここで簡単に説明します：
- SQLServer2016でのクエリオプティマイザーの追加
（互換性レベルのトピックと統計の更新のトピックの両方で、ドキュメントも更新されました。）
ただし、これらの操作に実際に使用できるCPUの数を指定できると便利ではないでしょうか（16の上限を許可する以外）。これを4または8に制限できることは、サポートするのが明白で論理的なことだと思います。特に、16個以下のコア、またはボックス上の複数のインスタンスを備えたシステムを実行しているお客様で、Resource Governorなどのエンタープライズ機能に依存できない場合（ほとんどのエンタープライズのお客様は、IMHOを使用することもできません）。
これに対するビジネス上の正当化は、MAXDOPサポートREBUILD、DBCC CHECKDBおよびその一連の保守操作などを追加するために使用される正当化と同じです。このタイプのアクティビティが、それほど抜本的なことをせずに、すべてのコアを引き継ぐのを防ぎたいと考えています。自動更新をオフにしたり、インスタンス全体のMAXDOPを使用したりします。これは、すべての人がメンテナンスウィンドウを利用できるわけではないためです。
この場合、インスタンス全体のMAXDOPはとにかく役に立ちません 、SQL Server 2016 RTMには、MAXDOPが無視されるというバグがあるためです。 サンプリングされた統計の更新。修正が近づいていますが、知っておくべきだと思いました。これが問題の原因である場合、1つのオプションは、より低い互換性レベルを使用することです。
しかし、私がよく言うことを繰り返します。互換性レベルが非常に混雑しています。データベースで並列サンプリングされた統計が必要であるが、古いCEを必要とするのに十分なカーディナリティ推定回帰がある場合は、どちらかを選択する必要があります。
そしてもう1つ、リソースガバナーはこのユースケースではやり過ぎであり、統計の更新によるコアの使用を制限することは、実際にはエンタープライズ機能ではありません（上記のREBUILDやCHECKDBのように）。 RGが許容できる代替手段であると言わないでください。これは、Enterprise Edition*および*ワークロード分類を使用しているユーザーのみが可能であり、MAXDOPによって常に制約される必要があるためです。 。ログインのセッション全体を制限するのではなく、特定の操作（または、最大/問題のあるテーブルのみ）によってこれを制限できるはずです。
彼らにどうやってやってもらいたいか
理想的には、新しいDATABASE SCOPED CONFIGURATIONオプションを使用してデータベースレベルで設定し、使い慣れたOPTION（MAXDOP n）構文を使用してステートメントレベルでこれを設定できます。ステートメントレベルが優先され、明示的なMAXDOPヒントのないサンプルモード統計の更新（自動を含む）は、データベースレベルの設定にフォールバックします。これにより、たとえば、予測できない時間に発生するすべての自動統計更新に対してMAXDOPを4に設定できますが、既知のメンテナンスウィンドウでの手動操作に対しては8または16を設定できます。一例として。
これに投票したい場合は、次のConnectアイテムを参照し、これに対するビジネス上の正当性を追加してください（Michael Campbell）：
- 接続＃628971：統計の更新にMAXDOPパラメーターを追加
もちろん、そのアイテムは2010年から存在しているので、DATABASE SCOPED CONFIGURATION通りについてはまったく言及されていません。そのため、私もコメントを残しました。
それまでの間、サンプルモードの並列処理を無効にする場合は、古い動作に効果的に戻すためのトレースフラグがあります（130未満の互換性レベルに戻すことでこれを行うこともできますが、これはお勧めしません。他の多くのものに影響します）。トレースフラグを公開してもよいと判断されたら、このスペースを更新しますが、現在、Microsoftはそれを胸にしっかりと固定しています。