トレースフラグ4199-グローバルに有効にしますか？

Question

これは意見の範疇に入るかもしれませんが、人々がSQL Serverの起動パラメータとしてトレースフラグ4199 を使用しているのかどうか知りたいです。これを使用したことがあるユーザーにとって、クエリ回帰はどのような状況で発生しましたか？

確かにそれは全体的に潜在的なパフォーマンスの利点のように思えます、私は非実稼働環境でグローバルにそれを有効にし、問題を特定するために数か月間置くことを検討しています。

4199の修正は、2014年（または2016年）にデフォルトでオプティマイザーに適用されますか？予期しない計画変更を導入しないケースについては理解していますが、バージョン間でこれらの修正をすべて隠しておくのは奇妙に思えます。

2008、2008R2、そして主に2012を使用しています。

spaghettidba · Accepted Answer

個人的には、新しいプロジェクト用に新しいサーバーを構築するときはいつでも、TF4199を常にグローバルに有効にしています。既存のインスタンスを新しいバージョンにアップグレードする場合も同様です。

TFは、アプリケーションの動作に影響を与える新しい修正を有効にしますが、新しいプロジェクトの場合、リグレッションのリスクは問題ではありません。以前のバージョンからアップグレードされたインスタンスの場合、古いバージョンと新しいバージョンの違いはそれ自体が問題であり、とにかく計画の回帰に対処する必要があることが予想されるため、TF4199を有効にしてそれと戦うことを好みます。

既存のデータベースに関する限り、知る唯一の方法は、それをテストすることです。既存のセットアップのワークロードをキャプチャし、フラグを有効にした後でそれを再生できます。 RMLユーティリティは、この答えで説明されているように、プロセスの自動化に役立ちます。

明らかに、フラグはインスタンス全体に影響するので、そこにあるすべてのデータベースをテストする必要があります。

Greg · Answer

トピックの検索でここに来たので、トピックに関する最近の経験を共有したいと思います。

私はSQL 2014を実行していたので、4199を少し気にする必要はないだろうと考えましたが、それは事実ではありませんでした...

4199が必要な場合の診断方法

queryがpoorlyを実行しているように見える場合、特に必要があると思われる場合それでは、最後に以下を追加してみてください。必要に応じて、すべての問題が解決するかどうかを確認してください4199（ "すべてのクエリオプティマイザーの修正を有効にします。"）

SELECT SomeColumn FROM SomeTable OPTION(QUERYTRACEON 4199)

私の状況では、上位10の句がなくてもクエリが正常に実行されました。これにより、何か怪しいことが起こっていると思いました。その4199が役立つ可能性があります。

約4199

新しいメジャーバージョンのリリース後に作成されたSQL Server Query Optimizerのバグ/パフォーマンスの修正は、実際には非表示になり、ブロックされます。これは、理論的に完全に最適化された他のプログラムに実際に害を及ぼす可能性がある場合に備えています。そのため、アップデートをインストールする場合があります。実際のクエリオプティマイザーの変更は、デフォルトでは有効になっていません。したがって、1つの修正または拡張が行われた後、それを利用したい場合は4199が必要になります。多くの修正が表示されるので、そのうちの1つが影響を与えると、最終的にこれをオンにするようになります。これらの修正は通常、独自のトレースフラグに関連付けられていますが、4199はマスターとして使用されます。

必要な修正がわかっている場合は、4199を使用する代わりに、部分的に有効にすることができます。すべての修正を有効にする場合は、4199を使用します。

それでは、グローバルに4199が必要です...

トレースフラグをグローバルに有効にするには、次の行で毎朝実行されるSQLエージェントジョブを作成するだけです。これにより、誰かがそれらをオフにした場合などに、それらが再びオンになることが保証されます。このジョブステップには、かなり単純なsqlがあります。

DBCC TRACEON (4199, -1);

ここで、-1はDBCC TRACEONのグローバル部分を指定します。詳細については、以下を参照してください。

https://msdn.Microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396

「再コンパイル」クエリプラン

私の最近の試みでは、4199をグローバルに有効にし、次に既存のキャッシュされたクエリプランを削除する必要がありました：

sp_recompile 'dbo.SomeTable'

https://msdn.Microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396

再コンパイルされたストアドプロシージャがデータベースオブジェクト（テーブルなど）に関連するクエリプランを見つけ、それらのクエリプランを削除した場合、それらをコンパイルするために同様のクエリを次に実行する必要があります。

したがって、私の場合、4199は不正なクエリプランが作成されないようにしましたが、sp_recompileを介してまだキャッシュされているものも削除する必要がありました。影響を受ける既知のクエリから任意のテーブルを選択します。これで、4199をグローバルに有効にして、問題のキャッシュクエリプランをクリアしたと想定して、そのクエリを再試行してください。

4199の結論として

インデックスを利用する場合、スマートクエリプランの最適化は、これらのインデックスを実際にインテリジェントに使用するために重要になります。クエリ最適化プロセスの修正が徐々にリリースされると想定すると、4199をグローバルに有効にして実行しても問題はありません。いくつかの新しい修正が、修正前の以前の環境でそのように最適化された高度に最適化されたデータベースで実際にはうまく機能しない可能性があることに気づく限り。しかし、4199は何をするのでしょうか？すべての修正が有効になるだけです。

Paul Williams · Answer

私の経験をトレースフラグ4199と共有したかった。

SQL Server 2012 SP3を実行しているお客様のシステムのパフォーマンスの問題の診断を終了しました。お客様はレポートデータベースを本番環境から移動しましたOLTPサーバーを新しいサーバーに移動しました。お客様の目標は、OLTPクエリを使用してリソースの競合をなくすことでした。残念ながら、顧客は新しいレポートサーバーが非常に遅いと述べました。

OLTPシステムで実行されたサンプルクエリは1.6秒で完了しました。クエリプランは、ビューの一部である最大2億行のテーブルでインデックスシークを行いました。

新しいサーバーでは、同じクエリが10分44秒で完了しました。同じ2億行のテーブルでインデックススキャンを実行しました。

レポートサーバーのデータはOLTPデータのコピーであるため、データの違いとは思われませんでした。

（OLTPシステムを実行する）ソフトウェアが起動時にいくつかのトレースフラグを有効にしたことを思い出すまで困惑しました。そのうちの1つ4199は、クエリオプティマイザーの修正でした。

顧客の新しいレポートサーバーでトレースフラグ4199を有効にすることをテストしました。レポートクエリは0.6秒で完了しました。（すごい！）トレースフラグを無効にしたところ、クエリは10分44秒で完了しました。フラグを有効化：0.6秒に戻す。どうやら、トレースフラグを有効にすると、オプティマイザは2億行のテーブルのビューにインデックスシークを使用できるようになりました。

この場合、トレースフラグ4199によって有効化されたクエリの最適化により、大きな違いが生じました。あなたの経験は異なる場合があります。しかし、この経験に基づいて、私には確かにそれを有効にする価値があるようです。