異なるクライアントがSQLサーバと通信している異なる結果に基づいて

Question

本番環境では、本番環境で非常に奇妙なシナリオが発生しています。誰もがこのようなことを見て、私のために良い説明を持っているかどうか分かります。

私たちはSql Server 2014にストアドプロシージャを持っていて、私たちの.NETシステムがそれを呼び出すときには何のデータも返していませんでした。

Sql Profilerを使用して呼び出しをキャプチャし、同じSQL認証資格情報を使用してSql Management Studioで再生し、期待どおりの結果を返しました。

何度も何度も試してみても、クライアントが.NETクライアントの場合は結果が得られず、SSMSのときはうまくいきました。

SP再コンパイルを実行することで問題を解決することができましたが、一時的な解決策と思われ、元の原因が警告なしに再発する可能性があることを認識していません。さらに、私はsp再コンパイルが異なる結果ではなくパフォーマンスの問題にのみ影響を与えるという印象を受けました。

誰もこれまで見たことがありますか？ sp再コンパイルがなぜそれを修正したのか説明できますか？

多くのありがとうございます！

Answer 1

通常、クエリはSSMSでうまく実行されますが、.Netクライアントではタイムアウトします。それはあなたがここで説明しているものかもしれません。

この問題の正確な原因についていくつかの議論があります。

一方では、SSMSと.Netクライアントのデフォルト値が異なるという問題があります。 SQL Server Management Studioのデフォルト設定のARITHABORTがONになっている

WARNING

：最も一般的な犯罪者がONに設定されていますが、ほとんどのSQL Serverのプロバイダは、サーバのデフォルト（OFF）のままにしておきますがSSMS ARITHABORT、あります。 クライアントアプリケーションでARITHABORTをOFFに設定すると、異なる クエリプランが受信され、パフォーマンスが悪い クエリのトラブルシューティングが困難になります。つまり、同じクエリは管理スタジオ では高速に実行できますが、アプリケーションは遅くなります。 を使用してクエリをトラブルシューティングする場合Management Studioは常にクライアントのARITHABORT設定と一致します。

この結果、a cached query plan（かなり複雑なトピック）がSSMSではうまく動作しますが、.Netクライアントではうまく動作しません。

もう一方の側の問題は、ちょうどparameter sniffingであり、ストアドプロシージャにキャッシュされた不良プランがあることを意味します。この側面では、ARITHABORT設定によって、サーバーが別のプランを選択して、悪いプランをスキップすると主張しています。しかし、中核的な問題はパラメータスニッフィングであり、実際にはARITHABORT設定は回避策です。

This SO questionは、可能な解決策の多くをカバーしています（ARITHABORT ONの設定、OPTION RECOMPILEの使用、OPTIMIZE FOR UNKNOWNの使用など）。その質問は、Erland Sommarskogの精巧な研究、つまりSlow in the Application, Fast in SSMS?: Understanding Performance Mysteriesにもリンクしています。これはおそらくあなたが今まで知りたいこと以上のものです。