問題タブ [read-uncommitted]

Omar のブログでこの興味深い記事を読んでください。Linq to SQL は、コミットされていない読み取りを使用してトランザクションのデッドロックとクエリのタイムアウトの問題を解決します。

ここで解決しようとしている問題は、SQL の意味から、NOLOCK で Select ステートメントを使用するか、SET TRANSACTION LEVEL READ UNCOMMITTED を使用する必要があることです。そうしないと、DB の大量の行がロックされ、エラーが発生します。Omar が使用しているテクノロジは Linq2Sql です。問題は、C# データ アクセス コードでこれをどのように実現して、上記のことが起こらないようにするかということです。

基本的に、この投稿では、Omar は実際のサイトで作業し、SqlProfiler などのツールを使用してテストすることで解決策にたどり着きますが、Javed Hasan は MSDN ドキュメントや Scott Hanselman のブログ投稿などを使用して解決策にたどり着きます。

Omar は、次の使用を提案しています。

ジャベド・ハサンが提案するのに対し

StatckOverflow のようなボリュームの多いサイトで、この特定の問題について皆さんが何をしたか、またはこの点に関してジェフとその関係者が何をしたかを知りたいです。

編集: 最初の投稿を読んだ後、Omar の投稿でいくつか指摘したいことがあります。

1. 彼は彼のアプローチで接続の問題に遭遇しましたが、彼はそれを解決しました。彼の投稿を参照してください。
2. さらに重要なことに、彼は ADO.NET トランザクションの使用方法を試し、Scott Hanselman が彼のブログに書いたことを試してみたと述べましたが、大量のサイトでは機能せず、パフォーマンスがかなり低下します。Omar 氏は次のように述べています。量のウェブサイト。」

DB の潜在的な並行性の問題を調べていたので、読みに行きました。http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005267.htmを見つけ、コミットされていないデータへのアクセスについて言及しています。

コミットされていないデータへのアクセス。アプリケーション A がデータベースの値を更新し、アプリケーション B がコミットされる前にその値を読み取る場合があります。次に、A の値が後でコミットされずにバックアウトされた場合、B によって実行される計算は、コミットされていない (おそらく無効な) データに基づいています。

何...他のセッション(同じアプリや同じスレッドでも)がまだコミットされていないデータを読み取ることができると思いましたか? コミットされていないトランザクションにデータを書き込んだ接続/セッション (用語がよくわかりません) だけが、コミットされていないデータを読み取ることができると思いました。

他のスレッドは、コミットされていないデータを本当に読み取ることができますか? mysql を使用する予定ですが、sqlite を使用する可能性があります

次のように SQL を使用できます。

を使用せずにLINQ to SQLでこれを達成するにはどうすればよいTransactionScopeですか?

System.Data.Sqlite ライブラリを使用して、SQLite データベース内のコミットされていないレコードの数を取得しようとしています。これまでの私の調査では、PRAGMA read_committed を使用することが指摘されていましたが、レコードがコミットされるまでは常にカウントが 0 になります。任意のヒント？

この投稿の回答によると、次のように述べています。

共有キャッシュを有効にしていて、両方の接続が同じスレッドからのものでない限り、ReadUncommittedがシリアル化された分離に戻ることをご存知ですか？

次に、C＃で作業し、DLLインポートを次のように定義しました。

この関数を呼び出してキャッシュを有効にし、呼び出されたときに成功した結果ステータス0を取得しました。それでも、以下の行を実行して分離レベルをReadUncommittedに設定しようとすると、例外「isolationlevel」が発生します。

この質問は、私がここに投稿した別の質問に関連しています。

SQLiteで分離レベルがReadUncommittedのクエリを実行するにはどうすればよいですか？

ときどき、ストアド プロシージャを実行して、2 つまたは 3 つの異なるテーブルのレコードのうち、いくつかの基準を満たすレコードの数を概算したいと考えています。この見積もり中に新しいレコードが追加、削除、または更新された場合、実際には問題はありません (大まかな見積もりが必要です)。つまり、 を使用してこのプロセスを実行する余裕がありますSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。ただし、これについて 2 つの質問があります。

1) 命令だけを使用しているので、これらのステートメントをブロックSELECT COUNT(*)でラップする必要は本当にありますか?BEGIN/COMMIT TRANSACTION

2）ストアドプロシージャSET TRANSACTION ISOLATION LEVEL READ COMMITTEDの最後に戻る必要がありますか、それとも実行が終了すると自動的に設定されますか？

クライアントの要求に応じて、Web アプリケーションを read-uncommitted 分離レベルにするように依頼されました (これはおそらく悪い考えです...)。

分離が行われているかどうかをテストしているときに、コミットせずに行を挿入し(DBVisualiser : @set autocommit off + データベースへの VPN 接続を停止)、コミットされていない挿入に対してアプリケーションのテストを開始しました。

select * from MYTABLE WHERE MY ID = "NON_COMMIT_INSERT_ID" WITH URは正常に動作しています。今、この行を「削除」したいのですが、方法が見つかりませんでした...

更新:しばらくすると行が消えました (約 30 分)。ロールバックが自動的に発行される前に、何らかのタイムアウトがあると思います。これが発生する前にコミットされていない行を削除する方法はありますか?

InnoDB を使用して MySQL にテーブルがあり、コミットされていない読み取りのトランザクション分離レベルを使用しています。@x示されているように設定するとロックが取得されるのはなぜですか?

別のプロンプトからこのテーブルを更新しようとすると、タイムアウト エラーが発生します。

独自のクエリを作成せずに Rob Conery の Massive を使用しているときに、コミットされていない読み取りを行う方法はありますか?

ほとんどが読み取り専用のサイト用です。サイトの CMS タイプ。

明らかに間違った分離レベルで実行されるいくつかのデータベース コードに問題があります。コードのこの特定の部分では、ロックを最小限に抑えるために「READ UNCOMMITTED」で実行することになっています。この時点では、不整合なデータは問題ありません。

ただし、コードは実際には READ COMMITTED で読み取りますが、その理由はわかりません。

行ったことは次のとおりです。

1. 接続を開く
2. この接続で「SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED」を実行します
3. ブレークポイントにヒット
4. SQL を実行する

ブレークポイントで、次のコマンドをデータベースに発行します。

この SQL は現在 4 つのプールされた接続を報告します。そのうちの 1 つは、ブレークポイントを超えて SQL を実行できる接続で、次の状態です。

すなわち。セッション 53 には分離レベル 2 (READ COMMITTED) があり、このセッションで最後に実行された SQL はその「SET TRANSACTION ...」コマンドでした。

どうすればいいの？

.NET コードが開く前にこの接続が有効でなかったことを SQL プロファイラーで確認したため、接続プールから再利用されませんでした。

しかし、接続が新しくなり、その接続で実行された最初の唯一の SQL が明示的に READ UNCOMMITTED を使用するように指示した場合、接続が依然として READ COMMITTED である可能性はありますか?

ここで何を見るべきですか？

接続文字列 (編集されたビットを含む) は次のようになります。

接続は通常のSqlConnection接続であり、通常の方法で開かれます。

残念ながら、SqlConnection を開く通常のコードを記述しても問題を再現できないため、アプリケーションの状態に何らかの問題があるはずですが、SqlProfiler と Sql Server の両方が「はい、SQL は実行されましたが、いいえ、私は気にしないでください。

これには何が影響しますか?

まったく同じコードが他の接続も開きます。つまり、コードが何度も実行され、多くの接続が開かれるため、複数の接続がプールに入れられますが、この問題が発生するのは最初の接続だけです。

これは SQL Server 2008 R2 であり、2012 でもこの問題を再現しました。

編集

OK、もう少し情報。

まず、プーリングを有効にしています。つまり、明示的に無効にしておらず、接続文字列をいじって「N」個のプールを作成していません。

ただし、この接続は、この特定の接続文字列で最初に開かれるため、プールから取得されません。また、永久に「病気」であるという以下の私のメモも参照してください。

この接続は次のように設定されています。

これより前に他の SQL を実行していません。

このコードは、アプリケーションの存続期間中に何度も使用されることに注意してください。最終的に間違っているのは、最初に開いた接続のみです。

この接続も永久に病気になります。接続を開くたびに (接続プールから取得する場合でも)、上記の状態変更イベントが実行され、分離レベルを再度設定しようとします。これも失敗しますが、この単一の接続のみです。

さらに、この質問を投稿してから、これに影響を与える 1 つのことがわかりました。

その後、この問題はなくなります。前述のブレークポイントで、接続は「READ UNCOMMITTED」状態になります。

これはおせっかいでした。実際にコードを実行するまで、概要で接続が報告されませんでした。

デバッグを続けています。