2014 SP1 + CU4アップグレード後のカーディナリティエスティメータの質問
最近、SQL Server 2008R2からSQL Server 2014 SP1 + CU4にアップグレードしました。
数週間後、行数を適切に推定しない実行プランで問題が発生しました。問題がひどく悪化したため、 9481 トレースフラグを有効にして統計を再度更新することで、古いカーディナリティエスティメータに戻すことが決定されました。私が「悪くなった」と言うときは、クエリの実行時間が10の大きさで増加することを指します。
Traceflag 9481 を使用して問題を解決しましたが、これは解決策にはなりませんか？
Googleを検索すると、古いカーディナリティ推定ルートを使用しているものと、新しい推定量を使用するために 2312 と 4199 を組み合わせて使用しているものがあります。
それでは、2008R2から2014にアップグレードした後、トレースフラグ（存在する場合）と他の手順をどのように組み合わせる必要がありますか？
ありがとう、クレイグ
4月26日午前9時に更新
4199トレースフラグは、新しいCardinality Estimatorをオンにしません。代わりに2312トレースフラグを使用する必要がありました。
4199トレースフラグを使用しても、バージョンは70のままでした。ChrisWoodからの回答は、ある時点で読んだBrent Ozarの article を思い出させました。実行時間が改善されるかどうかを確認するためにまだ待機しています。
このような問題に関する私の経験に基づいており、 このBlogs.msdnの記事 で言及されています
SP1を適用する必要がありますが、修正をアクティブ化するには、トレースフラグ4199も有効にする必要があります。SQLServer 2014 Service Pack 1では、新しいCardinality Estimator（新しいCE）にさまざまな修正が加えられました。リリースノートには修正も記載されています。
だから私はそれを有効にする回帰を抑制することをお勧めします。
Trace flag 9481は、SQL Serverに古いオプティマイザの使用を強制した場合に問題を解決しました。つまり、基本的にSQL Server 2014を使用していますが、それに付属する新しいCEは使用していません。
Trace flag 4199は、SQL Server 2005以降にSQL Serverオプティマイザーに加えられたすべての変更/修正をオプティマイザーが使用していることを確認します。
から このサポート記事
トレースフラグ4199は、将来のリリースでデフォルトでオンになることを目的とした修正プログラムを収集するために使用されましたが、他のトレースフラグは、修正が現在の形式でデフォルトでオンになることを目的としていない状況で使用されました。 SQL Server 2016 RTM以降、データベースのCOMPATIBILITY_LEVEL設定を使用して、トレースフラグ4199関連のホットフィックスをデフォルトで有効にします。この記事では、SQL Server 2016以降のバージョンで計画に影響する修正プログラムがどのように提供されるかについてのメカニズムとポリシーについて説明します。
必要に応じて、3つの方法があります。
ターゲットクエリの直前に（ DBCC TRACEON コマンドを使用して）トレースフラグをバッチで有効にし、クエリの直後に（DBCC TRACEOFFコマンドを使用して）トレースフラグを無効にします。
Microsoft SQL Server 2005 Service Pack 2（SP2）およびMicrosoft SQL Server 2008以降、クエリレベルのオプション "QUERYTRACEON"を使用できます。このオプションを使用すると、単一クエリのコンパイル時にのみ、プランに影響を与えるトレースフラグを有効にできます。
スターアップパラメータで有効にします。
1番目と2番目のポイントは、4199のトレースフラグでクエリ/バッチが実行されることのみを確認します。3番目のポイントは、実行されるすべてのクエリでこのトレースフラグが有効になっていることを確認します。
注：トレースフラグを有効にするにはsysadmin権限が必要なため、たとえばクエリで使用するよう開発者に依頼すると、開発者はアクセスが制限されていると想定できない場合があります。 。
querytraceonまたはdbcc traceonを使用して、クエリがマークまで実行されているかどうかを確認することをお勧めします。
新しいCEが発表されたときに私が見た提案の1つは、Brent Ozarからのものです。 2014年に稼働する前に、これをテストする必要がありました。2014で実行しますが、レベルは2012を示し、時間と計画をベンチマークします。次に、2014レベルに変更し、どのプランが変更されたかを確認します。そこから、悪い計画を調整しようとしました。
トレースフラグ4199は長い間使用されており、2008R2と2012で使用されています。ベンチマークを実行できた場合、両方の実行で同じトレースフラグを使用する必要がありました。
互換性レベルを変更することで、データベースレベルで無効にすることができます。 SQL 2014固有の言語機能を使用しないことを想定しています。
しかし、最終的には、どのクエリが実行計画に問題があるのか、そしてその理由を特定する必要があると思います。これを行うには、再生トレースをキャプチャし、トレースフラグ/互換レベルの有無にかかわらず、テストベッドで再生を開始し、プランキャッシュを選択（または再生中にXEセッションを実行してクエリにかかる時間を決定し、クエリを実行します）違いについて）。
敵がわかったら、適切な解決策を考え出すことができます（SOがそのための素晴らしい場所であるかどうかはわかりませんが、そうでない場合は、SQL Sentry Plan Explorerフォーラムを試してみてください。この種の分析のために作られました）。
ただし、統計の再計算に何を使用しているか、どのオプションを使用しているか、およびどのくらいの頻度で実行されているかを尋ねる必要があります。根本的な問題がメンテナンス不良かどうか疑問に思っています（念のためですが、そうではないと想定しています）。