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

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

確かに全体的なパフォーマンスの向上の可能性があるように思えます。非実稼働環境でグローバルに有効にし、問題を排除するために数か月間放置することを検討しています。

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

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

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

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

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

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

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

私はSQL 2014を実行していたので、4199について少し気にする必要はないだろうと思っていました...しかし、それは真実ではありませんでした...

4199が必要かどうかを診断する方法

あなたの場合は、クエリが実行するように見えるの悪いあなたはそれが、それはすべてあなたの問題を修正する場合は、必要があるかもしれませんとしても、見ることの末尾に以下を追加してみてくださいべきではないと感じたときに、特に、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は何をしますか？すべての修正が有効になるだけです。

トレースフラグ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によって有効にされたクエリの最適化により、大きな違いが生じました。あなたの経験は異なる場合があります。しかし、この経験に基づいて、それは間違いなく私にとって有効にする価値があるようです。