私たちは EF4 を評価していますが、私の DBA は、すべての SELECT ステートメントで NOLOCK ヒントを使用する必要があると言います。そのため、EF4を使用するときにこれを実現する方法を検討しています。
EF4 でこれを実現する方法に関するさまざまなアイデアを読みましたが、すべて回避策のようであり、Microsoft または EF4 によって認可されていません。LINQ-to-SQL / LINQ-to-Entities および EF4 を使用するときに SELECT ステートメントに NOLOCK ヒントを含めたいという人への「公式の Microsoft」応答は何ですか?
ちなみに、私が見つけた最高の情報はここにあり、このトピックに関心のあるすべての人にこのスレッドを読むことをお勧めします.
ありがとう。
NOLOCK = "READUNCOMMITTED"=ダーティリード
MSは、デフォルトの分離レベルを「READCOMMITTED」として選択した理由を知っていると思います。
NOLOCKは、実際にはどんなヒントでも、非常に慎重に使用する必要があります。デフォルトではありません。
あなたのDBAはマペットです。これを参照してください（SO）：SQLサーバーのすべてのSELECTで（nolock）を使用した結果、何が起こる可能性がありますか？。もしあなたがたまたま銀行や私が口座を持っているかもしれない機関で働いているなら、私がそれを閉鎖できるように私に知らせてください。
私は Microsoft の SQL 組織のツール チームの開発者です。私は公式の声明を出す権限はまったくありません。SO には、これらのことについて私よりも詳しい人がいると確信しています。それにもかかわらず、「時期尚早の最適化は諸悪の根源である」というテーマに沿って、友好的な経験則を提供します。
必要になるまで、NOLOCK (またはその他のクエリ ヒント) を使用しないでください。適切なクエリ プランを持つ select ステートメントがあり、システムに他の負荷がほとんどないときは正常に動作するが、他のクエリが同じテーブルにアクセスしているときに速度が低下する場合は、NOLOCK ヒントを追加してみてください。ただし、そうすると、一貫性のないデータが得られるリスクがあることを常に理解しておいてください。オンライン バンキングや航空機の制御を行うミッション クリティカルなアプリを作成している場合、これは受け入れられない可能性があります。ただし、多くのアプリケーションでは、パフォーマンスの高速化はリスクを負う価値があります。ただし、ケースバイケースで評価してください。いたるところでそれらを意地悪に使用しないでください。
NOLOCK を使用することを選択した場合は、拡張メソッドを使用して C#で解決策をブログに書いたので、NOLOCK ヒントを使用するように LINQ クエリを簡単に変更できます。これを EF4 に適応できる場合は、適応を投稿してください。
EF4 には現在、EF4 がすべてのクエリを生成している場合に、それを行うための組み込みの方法がありません。
ストアド プロシージャやより拡張されたインライン クエリ モデルを使用するなど、これを回避する方法がありますが、控えめに言っても時間がかかる可能性があります。
私は、キャッシングは EF4 サイトのサーバーの負荷を軽減するための Microsoft の意図したソリューションであると信じています (これについては Microsoft の代弁者ではありません)。フレームワークに組み込まれたコミットされていない (またはロックなし) 読み取りを行うと、2 つのコンテキストが同時に実行されたときに、EF4 の予想される動作に対して予測できない問題が発生します。それは、あなたの状況がそのレベルの並行性を必要とするという意味ではありません。
すべての選択でnolockを求められたようです。トランザクションである必要があるトランザクションがある場合、これは危険である可能性があるという以前のポスターには同意しますが、DBA を自動的にマペットにすることに同意しません。ダーティ リードに最適な CMS を実行しているだけかもしれません。データベース全体の ISOLATION LEVEL を変更すると、同じ効果が得られます。
DBA は、選択のみの操作に対して nolock を推奨している可能性があります (特に、ORM が誤って使用され、危険なデータ ダンプを実行している場合は問題ありません)。そのマペット コメントの最も面白い点は、スタック オーバーフロー自体が SQL サーバーを READ UNCOMMITTED モードで実行していることです。問題の答えを得るには、別の場所を見つける必要があると思いますか?
これをデータベース レベルで設定する可能性について DBA に相談するか、いくつかの場所でのみ必要な場合はキャッシュ戦略を検討してください。結局、Web はステートレスであるため、直接対処しない限り、同時実行性は幻想であることがよくあります。
1 年以上 EF4 を使用してきた私は、特定のタスクにストアド プロシージャを使用することはハックではなく、特定の状況下でのパフォーマンスのために絶対に必要であることを提案します。
私たちのプラットフォームは、 Web サイト、API、ETL データ フィードを通じて多くのトラフィックを獲得しています。EF は主に Web 側で使用していますが、一部のバックエンド プロセスにも使用しています。EF はクエリ生成で素晴らしい仕事をする場合もあれば、ひどい仕事をする場合もあります。生成されたクエリを確認し、それらをクエリ アナライザーにロードして、操作を別の方法 (ストアド プロシージャなど) で記述した方がよいかどうかを判断する必要があります。
EF と必要性を介してデータを利用できるようにする必要があることがわかった場合はNOLOCKs、いつでもNOLOCKヒントを含むビューを作成し、そのビューを基になるテーブルではなく EF に公開できます。ストアド プロシージャでも同じことができます。Code First アプローチを使用している場合、これらの方法はおそらく少し簡単です。
しかし、多くの人が EF で犯す間違いの 1 つは、EF オブジェクト モデルをデータベース内の物理 (テーブル) モデルに直接マップする必要があると信じていることだと思います。そうではなく、ここで DBA の出番です。彼に物理モデルを設計してもらい、一緒に作業して、EF のオブジェクト モデルにマップされる論理データ モデルを抽象化します。
これは重要な PITA になりますが、いつでも SQL をストアド プロシージャにドロップして、必要な (または強制される) 機能を取得できます。しかし、それは間違いなくハックです！
これがあなたの質問に対する答えではないことはわかっていますが、これを入れたかっただけです。
これは (少なくとも部分的には) DBA の仕事のように思えます。アプリケーションは特定の方法で動作する必要があると言っても問題ありません。ユーザーが望む方法でプログラムをプログラムすることは可能であり、試みるべきです。
ただし、確実にする唯一の方法は、DBA がユーザーと一緒にアプリケーションで作業し、DBA がアプリに提示したい DB サーフェスを構築することです。重要なテーブルを READ UNCOMMITTED としてクエリしたい場合は、一連のストアド プロシージャに正しいアクセス レベルと分離レベルを提供する必要があります。
すべてのアドホック クエリを正しく構築するためにアプリケーション コードに依存することは、スケーラブルなアプローチではありません。