問題タブ [nolock]

私たちのDBAは、LINQクエリがデータベースに何千ものロックを作成しているという情報を持って来ました。私たちのチームの開発者は、私たちの問題に対する可能な解決策として、このハンゼルマンの投稿を掘り起こしました：

http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx

スコットは、LINQでNOLOCKを設定するための3つの方法を提供します。1）TransactionScope（推奨）、2）SPROCS、3）context.ExecuteCommand

私たちは99％が読み取り、1％が書き込みを行うニュースサイトであるため、検索の速度に重点を置いています。NOLOCKは、すべてのLINQ-TO-SQLクエリに適した戦略ですか？

私が理解しようとしているのは、NOLOCKを使用することがなぜ良い考えであるかそうでないかということです。私たちと同じ目標を持つ多くの人々がいるに違いありません：多くの高速読み取り、更新はほとんどまたはまったくありません。NOLOCKが明白な答えである場合、なぜそれがデフォルトではないのですか？すべてのデータ呼び出しで設定するのではなく、コンテキストのデフォルトにできないのはなぜですか？

NOLOCKは、多くの高速読み取り、少数の更新サイトにとって本当に最良のオプションですか？

更新：SQL Server 2005以降では、スナップショットアイソレーションはNOLOCKよりも優れていますか？ 私はちょうどこれを見つけました http://msdn.microsoft.com/en-us/library/ms179599.aspx

READCOMMITTEDSNAPSHOTをカバーしています。これは書き込みブロックを防ぎますが、ダーティデータを返しませんか？これは、NOLOCKよりも90％の時間使用する必要がありますか？

更新2：私を悩ませているのはDRYです

私が最も気になっているのは、ロックなしまたはスナップショットパターンのいずれかを実装するために、すべてのLINQ-to-SQLクエリメソッド（更新で使用されているものを除く）でそれを変更する必要があることです。これはDRYの重大な違反のようなにおいがします。

開発者がクエリで WITH(nolock) を使用しているのを見たことがありますが、デメリットはありますか? また、クエリのデフォルトの実行モードは何ですか? 私のデータベースにはインデックスがありません。

データベースの select ステートメントのパフォーマンスを向上させる他の方法はありますか?

SQL 2008 を使用していますが、ほとんどの場合、ストアド プロシージャを実行するとエラーが発生します。エラーがあります: could not continue scan with nolock due to data movement。これについてオンラインで調べたところ、ほとんどの人が SQL バージョンを更新するとき、または更新/削除を行うときにこれを取得しているようです。私もやっていません。また、解決策は NOLOCK を削除することですが、NOLOCK を使用していません (SQL Server 2008 のデフォルトでない限り)。私も挿入しようとしましSET TRANSACTION ISOLATION LEVEL READ uncommittedたが、変更はありません。

私のストアド プロシージャは、パラメーターの取得、一時テーブルの作成、テーブルへの SELECT ステートメントのみの入力、およびテーブルからの情報のフェッチで構成されています。

誰が何が悪いのか知っていますか？

このコードに副作用はありますか:

「db」インスタンスは ReadUncommited モードで実行されますか?

with nolockSQL Azure がSQL ステートメントをサポートしていない理由を知っている人はいますか? マイクロソフトは今後これをサポートする予定はありますか?

ストアド プロシージャの出力パラメータで断続的に null 値が返されます。ストアド プロシージャ内の NOLOCK と関係があるかどうか疑問に思っています。ほとんどの場合は機能しますが、断続的に失敗します。特に高負荷時。ほとんどの場合、期待どおりの「y」または「n」が返されます。

ストアド プロシージャは次のとおりです。

そのため、nolock を使用してもロックはかかりません。未解決のロックを引き続き尊重しますか? たとえば、別のプロセスが排他ロックを設定している行を nolock で選択しようとすると、nolock での選択はブロックされますか、それとも行を選択しますか?

私はここや他の場所でしばらく探していましたが、NOLOCKを使用したLinq-TO-SQLが不可能な理由に対する適切な答えを見つけることができません。

with（NOLOCK）ヒントをLinq-To-SQLコンテキスト（1つのSQLステートメントに適用）に適用する方法を検索するたびに、IsolationLevelをReadUncommittedに設定してトランザクション（TransactionScope）を強制するように人々が答えることがよくあります。まあ-彼らはこれが接続がトランザクションを開く原因になるとはめったに言いません（私がどこかで読んだことは手動で閉じられていることを確認する必要があります）。

私のアプリケーションでReadUncommittedをそのまま使用するのは、実際にはそれほど良くありません。現在、相互に同じ接続に対してコンテキストステートメントを使用しています。好き：

合計実行時間が1秒で、同時に多数のユーザーがいる場合、分離レベルを変更すると、接続プール内のすべての接続が使用されているため、コンテキストは相互に接続を解放するのを待機します。

したがって、（多くの理由で）「nolock」に変更する理由の1つは、デッドロックを回避することです（現在、1日に1つの顧客のデッドロックがあります）。上記の結果は単なる別の種類のデッドロックであり、実際には私の問題を解決しません。

だから私ができることは次のとおりです。

1. 同じ接続のネストされた使用を避けてください
2. サーバーで接続プールのサイズを増やします

しかし、私の問題は次のとおりです。

1. これは、コードのリファクタリングの行が多いため、近い将来には不可能であり、アーキテクチャと競合します（これが良いか悪いかについてコメントし始めることさえありません）
2. もちろんこれは機能しますが、これは私が「対症療法」と呼ぶものです。アプリケーションがどれだけ成長するか、そしてこれが将来の信頼できる解決策であるかどうかはわかりません（そして、最終的にはより多くのユーザーが影響を受けるというさらに悪い状況）

私の考えは次のとおりです。

1. NoLockが（トランザクションを開始しないステートメントごとに）不可能であるというのは本当に本当ですか？
2. 1が真の場合-本当に真である可能性があります。他の誰もこの問題を取得して、SQLへの一般的なlinq変更で解決しましたか？
3. 2が真の場合-なぜこれは他の人にとって問題ではないのですか？
   1. 多分私が見たことがない別の回避策はありますか？
   2. 同じ接続（ネストされた）を何度も使用することは、誰もこの問題を抱えていないほど悪い習慣ですか？

ユーザー 1 :

ユーザー 2 :

user1 をコミットした後。ユーザー 2 の最後のステートメントが実行されています。

しかし、私はこのユーザー 2 の最後のステートメントを待機せずに実行したいと考えています。どうすればいいのですか。

私を助けてください。

短い：

C＃コードのSQLステートメントが機能していません。with(nolock)コードを壊しています。

詳細：

以下は私のエラーとエラーが発生するコードです。コードはSQLServerデータベースに接続し（接続コードは正常に機能します）、クエリを実行することになっています。このクエリは、URIが「blah」であるすべてのイベントのIPアドレスを取得します。問題は、with(nolock)私が使用する必要がある私のコマンドのようです。すべてのT-SQLクエリのグループ標準であるため、これを使用する必要があります。

私はしばらくグーグルで検索しましたが、私の問題に合うものは何もないようで、見つけた修正はまだ機能していません。私のコードやリンクについての助けをいただければ幸いです。

エラー：

System.Data.SqlClient.SqlExceptionがキャッチされましたMessage=キーワード'with'の近くの構文が正しくありません。このステートメントが共通テーブル式、xmlnamespaces節、または変更追跡コンテキスト節である場合、前のステートメントはセミコロンで終了する必要があります。
Source =.NetSqlClientデータプロバイダーErrorCode=-2146232060 Class = 15 LineNumber = 1 Number = 319 Procedure = "" Server = State = 1

コード：

解決：

コードを次の場所から変更します。

に：