問題タブ [rowlocking]

これは、 SQL Server で行レベルのロックを強制することは可能ですか?の拡張です。. ユースケースはこちら

口座番号、残高などを含む口座テーブルがあります。このテーブルは多くのアプリケーションで使用されています。私がアカウントを変更している間に、他の誰かが別のアカウントを変更している可能性は十分にあります。したがって、予想される動作は、私が自分のアカウント (ROW) をロックし、他のユーザーが彼 (別の ROW) をロックすることです。

しかし、SQL Server 2008 R2 はこのロックをページ/テーブルにエスカレートし、2 番目のユーザーはタイムアウト例外を取得します。参照されている質問に記載されているすべての解決策を試しましたが、何も機能していません。

SQL Server に行レベルのロックのみを強制的にロックさせるにはどうすればよいですか、またはページ/テーブルのロックで機能するようにこのモデルを変更するにはどうすればよいですか?

EDIT 更新はPKを介して単一のレコードを対象としており、インデックスが作成されているため、1行のみが更新/ロックされており、プロセスには1分以上かかりません

編集 今、何か奇妙なことが起こっているようです。複数の接続を開いている DAL 用の ORM ライブラリを使用しており、サポートに質問しました。しかし、テスト目的で、クエリツールで2つのセッションを開き、次のことを行いました

セッション # 2 のクエリがタイムアウトしました!!! の他の値のクエリは正常に機能しCOL_1ています。同じレコードが別のセッションで編集モードになっている場合、セッションの SELECT がブロックされているように見えます。

Oracle は、他のセッションによって変更されている間、行の選択をサポートしていますが (デフォルトのパラメーター/キーワードなし)、SQL Server はサポートしていません (デフォルトのパラメーター付き/キーワードなし)。そのため、問題はライブラリにあるようです。

Silverlight アプリケーション用の WCF Web サービスを作成しています。変更時に読み取り/書き込みロックされるレコードが必要です。

MySQL バージョン 5.5.11 を使用しています。

具体的には、リクエストが変更中に行からデータを読み取らないようにしたいと思います。

UPDATE と SELECT の 2 つの SQL コマンドは、実際には非常に単純で、次のようになります。

更新（書き込み/読み取りのためにロックする必要があります）：

選択 (上記のクエリからロックされている場合は読み取れないはずです):

これが私が試したものですが、まったく機能しないか、何もロックしていないようです:

Access/JET で行ロックを行うことはできますか?

たとえば、JET SQL で次のことができますか。

JET/DAO を使用してロックを使用して MDB データベースのレコードセットを開くdbPessimistic場合、その時点で別のユーザーがそのレコードセットの行を更新しようとするとどうなりますか? エラーが発生しますか?それとも、JET/DAO は行のロックが解除されるまで試行を続けますか?

NHibernateをデータ アクセス レイヤーとして使用し、SQL Server コンパクトを使用して、ac# デスクトップ アプリケーションに取り組んでい ます。アプリケーションは複数のスレッドを使用して、データの選択と更新を実行します。

通常は正常に動作していますが、デッドロック状態が発生することがあります。

15:28:16,750 55 警告: System.Data.SqlServerCe.SqlCeLockTimeoutException (0x80004005): タイムアウト ..... [ セッション ID = 28、スレッド ID = 14576、プロセス ID = 12960、テーブル名 = PatientOrder、競合タイプ = xロック (x ブロック)、リソース = PAG (idx): 1035]

2 つのトランザクションが同じ行を更新しようとすると、デッドロックの問題を理解できます。ただし、この場合、両方のトランザクションが異なる行で動作しています。デッドロックは、インデックス ( ) のページ ロックResource = PAG (idx): 1035が原因のようです。

だから私の質問は、これらのデッドロックを防ぐために何ができるでしょうか?

私はすでに次のオプションを調べました：

• インデックスのページ ロックを無効にします。これは「フル」SQL サーバーでは可能ですが、コンパクト エディションではサポートされていないようです。

• with(rowlock)（うまくいけば）問題を防ぐSQLステートメントを生成するようにhibernateを構成します

• session.lock(...)すべてのトランザクションに対して同じ順序でリソース アクセスを強制するために使用しようとしています。ただし、デッドロックのトランザクションが別の行で動作しているため、これは役に立たないようです。

• 一度に 1 つだけがアクティブになるように、すべてのデータベース トランザクションをシリアル化します。これは機能しますが、パフォーマンスに大きな影響を与えます。

私は現在、私のウェブサイトで厄介な問題を調査しています。ウェブサイトで定期的に賞品を提供していますが、コンテストに参加するにはログインする必要があります。そのため、ウェブサイトは時々非常に忙しくなります。多くの人がログインして登録しようとすると、UpdateUser、CheckPassword、および GetUser関数のデッドロックに関する大量のエラーが発生し、サーバーがビジー状態になり、他の要求がタイムアウトし始めることがわかりました。

ストアド プロシージャを調べると、'UpdateUser' で ROWLOCK が使用されていることがわかりました。これらの ROWLOCK がデッドロックの原因ですか? または、選択だけでデッドロックが発生しますか?

自分の状況でNOLOCKを使おうと思っていたのですが、ちょっと調べてみると、どうやらお勧めできないようです...

デッドロックを回避し、複数のサービスからの要求を同期するために、私はROWLOCK、READPASTを使用しています。私の質問は、CTE、サブクエリ、およびCTEの更新ステートメントを含むクエリのどこに配置する必要があるかということです。重要な場所は1つありますか、それとも3か所すべてにあるべきですか（下）。または、更新される行のみを選択できるように、このようなクエリを作成するためのより良い方法があるかもしれません。

2 つのクライアントを持つクライアント サーバー アプリケーションがあります。

複数のクライアントがデータベースを読み取っているときに、すべてのクライアントが同じ行を取得することなく、データベースの読み取りを効率的にする必要があります。私はテーブルに InnoDB エンジンを使用しています。クエリは好きSELECT...FOR UPDATEで、使用していません。SHARED MODE

次のシナリオでプロセスがどのように動作するかについて説明が必要です。

1. テーブルに 30 行あります。各クライアントには、データベースへの接続オブジェクトが 1 つあります。
2. クライアント A は で 15 行を取得しSELECT ...FOR UPDATEます。これらの行はロックされていると想定されています。
3. クライアント B は、クライアント A によってロックされていない他の 15 行をそれぞれ取得する必要がありSELECT ..FOR UPDATEます。

このシナリオをテストすると、クライアント B もクライアント A の 15 行を取得しました。私は設定し、実行も照会setAutoCommit(false)もしません。したがって、接続は決してコミットされず、(クライアント A がしたなど) 設定されたロックは決して解放されません。COMMITROLLBACK

誰かが私を正しい方向に向けることができますか? 私が間違っていることは何ですか？

やりたいことは、同じスクリプトを cron で数分ごとに実行することです。

スクリプトはデータベースから読み取ったデータを処理する必要があるため、毎回異なる行で作業する必要があることは明らかです。

私のコンセプトは、行ロックを使用して各インスタンスが異なる行で機能することを確認することでしたが、そのようには機能していないようです。このように行ロックを使用することさえ可能ですか? 他のソリューションはありますか？

例：

基本的に必要なのは、SCRIPT1 がテーブルから R1 を読み取ることです。SCRIPT2 は R2 を読み取ります (条件に一致する次のロックされていない行)

編集: たとえば、1) テーブルに URL のリストが格納されているとします。2) スクリプトは URL が応答するかどうかを確認し、データベースのステータス (およびタイムスタンプ) を更新します。

データベースを使用してクライアントを同期する分散アプリケーションがあります。クライアントはレコードを更新しようとしますが、過去 1 時間に他のクライアントが更新を行っていない場合にのみ更新を行います。

縮小されたコードとジレンマは次のとおりです。

あるクライアントがフィールドを「赤」に更新しようとしたとします (過去 1 時間以内に他の誰も更新していないことを確認します)。

同時に、別のクライアントがそれを「緑」に更新しようとします (過去 1 時間以内に他の誰も更新していないことを確認します)。

行の更新に成功するクライアントは1 つだけであると想定できますか?

答えが「いいえ」だと思う理由は次のとおりです。

Oracleは行レベルの更新ロックを取得するsysdate 前に解決する必要があるため (最初に行を見つけるためにそれを使用する必要があるため)、競合状態があるように見えます。

1. クライアント「レッド」が計算sysdate
2. クライアント「グリーン」が計算sysdate
3. 1時間経過
4. クライアント「赤」TimeOfLastUpdateが古いもので更新sysdate
5. クライアント「グリーン」TimeOfLastUpdateは古いもので更新されますsysdate（したがって、2回更新されます）

これを競合状態として特定するのは正しいですか? そうでない場合、何が欠けていますか？

もしそうなら、この問題に対する効率的で信頼性の高い解決策はありますか?