問題タブ [database-deadlocks]

データベースから特定のテーブルを取得して単一のテーブルに配置するクエリを 1 日に 1 回実行して、必要な形式で情報をすばやくエクスポートできるようにしています。

問題が発生していますが、次のエラーが表示されます。

私が理解していることから、既にロックが設定されているときに、クエリがテーブルをロックしようとしているように思えます。ただし、テーブルのロックやその仕組みについては何も知らないことを告白します。

本当に私は他のテーブルを読み込もうとしているだけで、それらに書き込もうとはしていません.クエリを作成するがロックを要求しない方法はありますか?

私の質問はとてつもなく長いので、投稿しませんでした。必要なパーツがある場合はお知らせください。投稿できます。

データベースで特定のクエリを実行すると、かなり頻繁に次のエラーが発生します (すべてのテーブルは InnoDB ストレージ エンジンを使用します)。

クエリはDELETE FROM sessions WHERE userid != 0 AND lastactivity < 1289594761 AND admin = 1 AND userid NOT IN (SELECT userid FROM users WHERE (userflags & 1048576))

NOT IN 部分を WHERE ステートメントに追加したときに、エラーが発生し始めました。これが原因で問題が発生するのはなぜですか? また、これを防ぐにはどうすればよいですか?

C# で SQL データベースからデータを取得しようとすると、次の 2 つの例外が生成されます。

System.Data.SqlClient.SqlException: トランザクション (プロセス ID 97) が別のプロセスのロック リソースでデッドロックされ、デッドロックの犠牲者として選択されました。

また

System.Data.SqlClient.SqlException: トランザクション (プロセス ID 62) が別のプロセスのロック リソースでデッドロックされ、デッドロックの犠牲者として選択されました。

また

System.Data.SqlClient.SqlException: トランザクション (プロセス ID 54) が別のプロセスのロック リソースでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。

これはコードです：

これらは毎回起こりました。

これらをどのように解決できるかについてのアイデアはありますか?

複数の sql ステートメントを異なるスレッドで同時に実行しているアプリケーションがあり、すべてが 1 つのテーブルから発生しているように見えるさまざまなデッドロックを引き起こしています。たとえば、次の 2 つの更新ステートメントは次のとおりです。

UPDATE WF SET QUEUETIME='2011-02-18 13:06:53.578', STATE = 'outbound', USER = '', TIME = null WHERE PID = 'MessageProcessing' AND ACTIVITYID = 'Delete' AND ITEMID = '120' AND TRANID = '作成済み' AND 状態 = '準備完了' AND USER = ''

UPDATE WF SET QUEUETIME='2011-02-18 13:06:53.625', STATE = 'ready', USER = '', TIME = null WHERE PID = 'standardOutbound' AND ACTIVITYID = 'Node1' AND ITEMID = '121' AND TRANID = 'toNode1' AND STATE = '' AND USER = ''

次のデッドロックを生成します。

ある程度のデッドロックは避けられず、アプリケーションがそれらを処理する必要があることは理解していますが (実際に処理します)、この場合になぜデッドロックが発生するのかわかりません。私の単純な考えでは、これらの 2 つのステートメントは異なる行をロックする必要があり、同じ行を更新していたとしても、一方が他方を待つ必要があります。

デッドロックを引き起こしている理由を説明したり、デッドロックを防ぐ方法について何か提案をしたりできますか?

テーブルには 3 つの非クラスター化インデックス (PID、ACTIVITYID、ITEMID、TRANID)、(ITEMID)、および (PID、ACTIVITYID) があります。(PID、ACTIVITYID、ITEMID、TRANID) が主キーを構成します。私は（やや盲目的に）インデックスをいじってみましたが、一見役に立たないようです。

アプリケーションは weblogic と sql server 2005 で実行されており、websphere と sql server 2008 でデッドロックを再現しました。Oracle データベースを使用している場合は発生しないようですが、残念ながらこれはクライアントのオプションではありません!

これについて助けや洞察を提供できる人に感謝します。

不明な SQL Server 2008 デッドロックが発生しています。

私は2つのテーブルを持っています:

SQL Server エラー ログには、次の内容が記載されています。

PK_X は、ID 列 (自動インクリメント列である ID) のクラスター化された昇順インデックスです。T2 には、JOBID と X の非クラスター化インデックスである別のインデックスもあります。

両方のプロセスが同じオブジェクト (T2.PK_T2) のロックの所有者になっているのはなぜですか?

助けてください、ドロン

これについて専門家のアドバイスが必要です。

背景 PHP/Codeigniter MYSQLi Innodb テーブル - fares_table ストアド プロシージャ

バックエンド - 数分ごとに fares_table に (サービスからの) データを挿入/更新する cronjob php スクリプトが書き込まれます。(通常の SQL クエリ)

フロントエンド - ユーザーはこれらのデータを読み取ることができます (多くのテーブルの結合を伴うため、クエリはストアド プロシージャ形式で記述されます。したがって、私のストアド プロシージャは、fares_table の select ステートメントから一時テーブルを作成し、他のテーブルに結合しています)

問題

fares_table の更新/挿入中にユーザーがフロントエンドに出くわした場合、デッドロックが発生する可能性があります。update ステートメントでデッドロックが発生する

デッドロックは、バックエンドが挿入または更新を行ってロックが解放されるのを待機しようとしている間に、fares_table からの選択ステートメントを使用して一時テーブルを作成しようとしているときに、ストアド プロシージャがロックが解放されるのを待機しようとすることによって発生します。

私の一時的な修正

データベース エラー 1213 をキャッチし、更新クエリを再試行します。現在は機能していますが、代わりにデッドロックを防ぐためのより良い解決策を見つけたいと思います。専門的なアドバイスはありますか？

デッドロックを防ぐために順序を変更するにはどうすればよいですか?またはインデックスの複製がflighttype_idx役立ちますか?

「デッドロックが発生したか、すべてのロックが解除されました」というエラーに続いて、Sybaseがスローします。そこで、Sybaseが使用可能なロックを使い果たしたために問題が発生したかどうかを確認したいと思いました。

利用可能なデフォルトのロックと、利用可能なロックの数を見つける方法を知っている人はいますか？

ロックされたリソースがDBID、ファイルID、ページIDの3つのフィールドで示されているデッドロックグラフを作成しました。関連するobjectidもいくつかあります。私が知りたいのは、このページがどのテーブルに属しているかだけです。試しDBCC PAGE(dbid, fileid, pageid) with tableresultsましたが、テーブル名が表示されません。

これを取得する方法はありますか？

更新：SELECT name From sys.indexes WHERE object_id = 123 and Index_id = 456 ここでも試してみました123はm_objid（next ObjectId）、456はm_indexid（next IndexId）で、コマンドの出力として取得しますDBCC Page。私が得るのはNULLだけです。

私は、時折現れる InnoDB のデッドロックに頭を悩ませようとしています。

当時は知りませんでしたが、INSERT ... SELECT、CREATE ... SELECT は SELECT クエリ内のすべてのテーブルをロックするようです。ご覧のとおり、結合とサブクエリを含むテーブルが多数あります。ロックは共有 (S) ロックだと思っていましたが、上記のデータから、排他 (X) ロックを保持しているようです。理由がわかりません。

たぶん、誰かが CREATE ... SELECT クエリに排他的 (X) ロックがある理由を理解するのを手伝ってくれれば、このデッドロックを解決しようとすることができます。または、デッドロックについてさらに支援を得ることができるかもしれません。

ありがとうございました。

MSSQLServer2008によって選択された犠牲者がデッドロックループの一部ではないという奇妙なデッドロックグラフがあります。このデッドロックはとの間selectですinsert。selectデッドロックリソースは、すべてのユーザーが必要とする単一のテーブルです。waitresource = "KEY: 6:72057594098810880 (ffffffffffff)"

質問1：ここでのffffffffffffは、テーブル全体をフルレンジでロックする必要があることを意味しますか？またはキー範囲全体？または、他の何か？

テーブルに主キーID=0の行がないというルールに従っています。この種のチェックを行う場所はほとんどありません。

select foo from bar where @someId = 0 OR SomeId = @someId。

また、SQLが式を短絡させないことも知りました。したがって、合格@someId = 0した場合、他の部分が評価されないことを保証するものではありません。したがって、SQLは実行時に実行できる可能性がありますSomeId = @someId。

質問2：SomeIdで0を見つけることができなかったため、SQLはテーブル全体（または行）の範囲ロックを取得し、他の誰も0idを挿入しません。右？

その仮定を念頭に置いて、where句をこれに変更しました

これが評価順序を強制することを期待しています。しかし、私は間違っています。再びデッドロックに陥っています。以下にデッドロックグラフを添付しました。関連するテーブルとsprocの名前を変更しました（会社のポリシー）

質問3：私がここで何が欠けているか知っていますか？