タグ付けされた質問 「deadlock」

2つ以上のプロセスが他のプロセスによって保持されているリソースのロックによってブロックされているため、処理を続行できない(したがって、ロックを解放できない)ことによって引き起こされる状況。

2
SQL Serverインデックス更新のデッドロック
同時に実行するとデッドロックが発生する2つのクエリがあります。 クエリ1-インデックス(index1)に含まれる列を更新します。 update table1 set column1 = value1 where id = @Id table1でXロックを取得してから、index1でXロックを試行します。 クエリ2: select columnx, columny, etc from table1 where {some condition} index1でS-Lockを取得してから、table1でS-Lockを試行します。 同じクエリを維持しながらデッドロックを防ぐ方法はありますか?たとえば、更新前に更新トランザクションのインデックスでX-Lockを何らかの方法で取得して、テーブルとインデックスのアクセスが同じ順序であることを確認できますか?デッドロックを防ぐことができますか? 分離レベルは読み取りコミットです。インデックスの行ロックとページロックが有効になっています。同じレコードが両方のクエリに参加している可能性があります。パラメータが表示されないため、デッドロックグラフからはわかりません。 デッドロックグラフ

1
デッドロック検出のためのSQL拡張イベントセッション
<inputbuf>デッドロック拡張イベントセッションによってキャプチャされたデッドロックXMLの要素のサイズを増やす方法はありますか? アプリケーションコードで問題を特定するのに役立つ完全なクエリが必要です。 1024文字+/-に制限されているようです。増やすことはできますか? サンプルXMLについては、以下を参照してください。<inputbuf>要素のクエリテキストが選択リストの中央で途切れていることがわかります。 <deadlock> <victim-list> <victimProcess id="processc9c0829848" /> </victim-list> <process-list> <process id="processc9c0829848" taskpriority="0" logused="0" waitresource="PAGE: 5:1:40600276 " waittime="696" ownerId="255115931225" transactionname="SELECT" lasttranstarted="2019-04-24T09:29:25.950" XDES="0xc8dfa8da40" lockMode="S" schedulerid="13" kpid="8480" status="suspended" spid="245" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2019-04-24T09:29:25.950" lastbatchcompleted="2019-04-24T09:29:25.950" lastattention="1900-01-01T00:00:00.950" clientapp="EntityFramework" hostname="MSR-PRD-BDB02" hostpid="43440" loginname="IUSR_BuildDB" isolationlevel="read committed (2)" xactid="255115931225" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> <executionStack> <frame procname="adhoc" …

2
これらの2つのクエリを順番に実行すると、デッドロックが発生しますか?
これはほぼ間違いなく他の質問の原因ですが、改ざんまたは検証したい次のログに基づいて仮説があるので、2つを分ける価値があると思いました。 私の仮説では、他のデッドロックは実際には次のクエリの結果であり、innodbステータスが最新のトランザクションのみを表示するという理解に基づいて元のクエリが非表示になっています(これは正しいですか?)。 ログに基づいて、コードをチェックしたところ、次の2つのクエリが順番に実行されていることがわかりました。 db.Execute("UPDATE people SET iphone_device_id=NULL WHERE iphone_device_id=@0 AND people_id<>@1", DeviceID, m_User.people_id); // I have hard coded this query in this snippet to simplify things db.Execute("UPDATE people SET company_id = 444, name = 'Dad', password = '<pass>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@gmail.com', phone = NULL, …

1
デッドロックレポートの「ロックは待機しますがギャップ待機はしません」の意味
locks rec but not gap waitingTRANSACTION(1)の意味について、どちらが正しいですか? 既にギャップロックが付与されており、クラスター化インデックスXロックを待機していますか? クラスター化されたインデックスXロックを既に付与し、ギャップロックを待機していますか? Transaction(1)には31行あります。それらの行の意味は何ですか?これはギャップロックを表しますか? 0: len 4; hex 800c20d6; asc ;; .... 29: SQL NULL; 30: SQL NULL; 最新の検出されたデッドロックレポート LATEST DETECTED DEADLOCK ------------------------ 2015-09-25 15:27:24 1b8084000 *** (1) TRANSACTION: TRANSACTION 5226928, ACTIVE 0 sec fetching rows mysql tables in use 1, locked 1 LOCK WAIT …
12 mysql  deadlock 

1
最後のいくつかのinnodbデッドロックを表示する
mysql / innodbで最新のデッドロックを表示できることがわかりましたが、過去のデッドロックを表示する方法はありますか?デッドロックには2つの問題があります。1つは重要で、もう1つは重要ではありません。重要性の低いデッドロックは1日に数回発生するため、「最新の」デッドロックになります。

2
SELECT…WITH XLOCKを使用する理由は何ですか?
私はいくつかの再発するデッドロックに直面しています。そのうちの1つはキーロックであり、デッドロックの犠牲になるXLOCKヒントを含むSELECTクエリが含まれています。もう1つのステートメントは、最初のクエリのビューの一部であるテーブルの1つへのINSERTです。 見る: create view dbo.viewE as select * from dbo.E where myValue > 13000 クエリを選択: select * from dbo.viewE with (XLOCK) where A > GETUTCDATE() INSERTステートメント: INSERT INTO [dbo].[E] (myValue,A) VALUES (10,GetDate()) 基になるテーブルdbo.Eは、約20列に約300万行を保持しています。それらの一部はntextです。 クエリを取り出し、2つのトランザクションで手動でシミュレーションすると、動作は再現可能です。XLOCKが選択から削除されると、動作が変わります。 デッドロックグラフ: <deadlock-list> <deadlock victim="process222222221"> <process-list> <process id="process222222221" taskpriority="0" logused="0" waitresource="KEY: 5:72057604035644444 (ccdf51accc0c)" waittime="2522" ownerId="27202256401" transactionname="SELECT" lasttranstarted="2015-09-14T16:32:36.160" …

1
削除ステートメントのデッドロック
SQL Serverジョブを実行すると、デッドロックが発生します。デッドロックは、単純なDELETEステートメントで発生します。デッドロックを引き起こすためにSELECT / UPDATEクエリを実行する必要があると思いましたか?しかし、それはDELETE / DELETEデッドロックのように見えます... 私が探しているのは、DELETE / DELETEデッドロックが発生する理由です。(私の知る限りでは)異なるパラメーターを渡すことです。 何か案は?ありがとう。 deadlock-list 2014-05-20 07:30:09.66 spid25s deadlock victim=process409048 2014-05-20 07:30:09.66 spid25s process-list 2014-05-20 07:30:09.66 spid25s process id=process409048 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127294 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x397219620 lockMode=U schedulerid=5 kpid=3792 status=suspended spid=150 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed …

1
インデックスのロック順序による2つの更新でのSQL Serverのデッドロック
2つのUPDATEがあります。ステータス列も更新されているため、1つは最初にCIをロックし、次にNCI(ステータス)をロックします。もう1つは、NCIが変更中であることを認識しているため、すでにNCIのUロックを所有しており、CIのUロックを取得しようとします。 これらを強制的にシリアル化する最も簡単な方法は何ですか?これは内部インデックスの問題であるため、TABLEレベルのヒントを使用するのは奇妙に思われます-関係するテーブルは1つだけです-UPDLOCK、HOLDLOCKはそのテーブルで必要なすべてのインデックスに自動的に適用され、それによって強制的にシリアル化されますか? クエリは次のとおりです。 UPDATE htt_action_log SET status = 'ABORTED', CLOSED = GETUTCDATE() WHERE transition_uuid = '{F53ADDDA-E46B-4726-66D8-D7B640B66597}' AND status = 'OPEN'; その1つのXが(CREATED列で)CIの行をロックし、ステータス列を含むNCIでXロックを試みます。 UPDATE htt_action_log SET status = 'RUNNING {36082BCD-EB52-4358-E3D3-4D96FD5B9F0F} 1360094342' WHERE action_uuid = (SELECT TOP 1 action_uuid FROM htt_action_log WHERE transition_uuid = '{F53ADDDA-E46B-4726-66D8-D7B640B66597}' AND status = 'OPEN' ORDER BY action_seq) この1つのUは同じNCIをロックします-私が推測するネストされたクエリの場合、更新のためにCIをロックします。 …

1
デッドロックグラフに犠牲者のいないエントリがあるのはなぜですか?
SQL Server 2008のデッドロックグラフの分析方法を学習しようとしていますが、<victim-list>ノードが空のエントリがたくさん見つかります。これらのエントリの意味がわかりません。被害者がいない場合、どのようにしてデッドロックの原因となっているwaitresourceを特定できますか?これらのエントリはどういう意味ですか? ここに私が見ているエントリーの簡単な例があります: <deadlock-list> <deadlock> <victim-list /> <process-list> <process id="processd2b6508" taskpriority="0" logused="10000" waittime="31" schedulerid="63" kpid="9104" status="suspended" spid="69" sbid="0" ecid="184" priority="0" trancount="0" lastbatchstarted="2012-07-30T01:10:45.550" lastbatchcompleted="2012-07-30T01:10:45.550" clientapp=".Net SqlClient Data Provider" hostname="XXXXXXX" hostpid="3648" isolationlevel="read committed (2)" xactid="30461033" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> <executionStack> <frame procname="" line="1" sqlhandle="0x020000002340c50225c17d0eec9bf7c51129348edffd1c70" /> <!--About 2 more frame tags... --> …

5
デッドロックを監視する方法
SQL Server 2005/2008のデッドロックのトラブルシューティングを開始する時期と方法は?アラートは、SQL Serverのパフォーマンス条件アラート、オブジェクト-> SQLServer:Locks、カウンター->ロック待機/秒、インスタンス:_Total、カウンターが値を超えた場合にアラートを介してSSMSでオンになります。これは、予防的な監視方法ですか?許容値は何ですか?よろしくお願いします。ありがとうございました!!!

2
このクエリがデッドロックを引き起こすのはなぜですか?
このクエリがデッドロックを引き起こすのはなぜですか? UPDATE TOP(1) system_Queue SET [StatusID] = 2, @ID = InternalID WHERE InternalID IN ( SELECT TOP 1 InternalID FROM system_Queue WHERE IsOutGoing = @IsOutGoing AND StatusID = 1 ORDER BY MessageID ASC, InternalID ASC) 追加されたデッドロックグラフ: <keylock hobtid="72057594236436480" dbid="9" objectname="Z.dbo.system_Queue" indexname="PK_system_Queue" id="lock5b25cc80" mode="X" associatedObjectId="72057594236436480"> <owner-list> <owner id="processc6fe40" mode="X"/> </owner-list> <waiter-list> …

6
READ UNCOMMITTED分離レベルを使用するのに最適な状況
ご存じのとおり、READ UNCOMMITTEDは、ダーティリードやファントムリードなどが発生する可能性がある最低の分離レベルです。この分離レベルを使用するのに最適な時期はいつですか、どのような理由で使用されるのですか? 実は前に答えを読んでみましたが、例が少ないので完全には理解できませんでした。

2
Parallelism Exchangeイベントのデッドロックが被害者なしである場合、それは問題ですか?
実稼働環境(SQL Server 2012 SP2-はい...わかっています...)にこれらのクエリ内並列スレッドデッドロックが多数見られますが、拡張イベントを介してキャプチャされたデッドロックXMLを見ると、犠牲者リストは空です。 <victim-list /> デッドロックは4つのスレッドの間にあり、2つはWaitType="e_waitPipeNewRow"、2つはWaitType="e_waitPipeGetRow"。 <resource-list> <exchangeEvent id="Pipe13904cb620" WaitType="e_waitPipeNewRow" nodeId="19"> <owner-list> <owner id="process4649868" /> </owner-list> <waiter-list> <waiter id="process40eb498" /> </waiter-list> </exchangeEvent> <exchangeEvent id="Pipe30670d480" WaitType="e_waitPipeNewRow" nodeId="21"> <owner-list> <owner id="process368ecf8" /> </owner-list> <waiter-list> <waiter id="process46a0cf8" /> </waiter-list> </exchangeEvent> <exchangeEvent id="Pipe13904cb4e0" WaitType="e_waitPipeGetRow" nodeId="19"> <owner-list> <owner id="process40eb498" /> </owner-list> <waiter-list> <waiter id="process368ecf8" …

2
Tablockヒントがデッドロックをトリガーする
最小限のログを使用して、2つのデータセットを空のヒープテーブルに挿入しました。これは、次の形式のSQLで並列実行されている2つのSQL実行タスクを使用して行われました。 INSERT INTO Table (TABLOCK) SELECT FROM ... ジョブが少しハングした後、SQLタスクの1つがデッドロックの犠牲になりました。以下は、デッドロックグラフのXML出力です。 誰かが内部で何が起こっていたか説明できますか? <resource-list> <objectlock lockPartition="0" objid="1586156746" subresource="FULL" dbid="7" objectname="dbo.TargetTable" id="lock7374a00" mode="IX" associatedObjectId="1586156746"> <owner-list> <owner id="process9609dc8" mode="Sch-S"/> <owner id="process9609dc8" mode="IX"/> </owner-list> <waiter-list> <waiter id="process5e13048" mode="X" requestType="convert"/> </waiter-list> </objectlock> <objectlock lockPartition="0" objid="1586156746" subresource="FULL" dbid="7" objectname="dbo.TargetTable" id="lock7374a00" mode="IX" associatedObjectId="1586156746"> <owner-list> <owner id="process5e13048" mode="Sch-S"/> <owner id="process5e13048" …

1
SQL Serverはいつロックを取得しますか?
ここにあるSQL Serverの分離レベルのリストには、トランザクション内で取得された書き込みロックは、トランザクションが終了するまで保持されることが記載されています。ただし、これらのロックがいつ取得されるかについては触れられていません。 ロックはデフォルトでトランザクションの開始時に取得されますか、それとも必要なときに取得されますか?後者が当てはまる場合、Xのロックが保持される時間を最小限に抑えるために、大規模なトランザクションでは書き込み操作をできるだけ遅く実行する方が有利でしょうか。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.