除了修改業務邏輯，換成同一個執行緒還有別的辦法么？
如果是mysql可以修改事務的隔離級別，oracle怎么弄呢？
主要寫代碼的人太菜了，弄那么多屎給我擦，怎么整？
兩個執行緒，兩個事務，同時洗掉同一條記錄導致死鎖，大家有什么好的解決方案么
uj5u.com熱心網友回復：
oracle的單表單行delete是上行級鎖的，多執行緒刪不存在死鎖，只會暫掛。uj5u.com熱心網友回復：
暫掛時間久了就會報個死鎖的錯誤，我知道不是傳統意義上的死鎖。
uj5u.com熱心網友回復：
暫掛時間長了，應該是你程式超時了，或者是 session 過期了，不是死鎖。死鎖是兩個會話，形成了一個相互等待對方釋放資源的場景。
uj5u.com熱心網友回復：
我知道兄弟，
*** 2018-03-18 01:25:39.378
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-000f001b-002dc2e3 51 177 X 20 234 S
TX-00150001-000ef565 20 234 X 51 177 S
session 177: DID 0001-0033-00000B9B session 234: DID 0001-0014-00001985
session 234: DID 0001-0014-00001985 session 177: DID 0001-0033-00000B9B
Rows waited on:
Session 177: obj - rowid = 00013437 - AAAWIFAGGAADLFQAAA
(dictionary objn - 78903, file - 390, block - 831824, slot - 0)
Session 234: obj - rowid = 00013437 - AAAWIFAGGAADLcrAAA
(dictionary objn - 78903, file - 390, block - 833323, slot - 0)
----- Information for the OTHER waiting sessions -----
Session 234:
sid: 234 ser: 39915 audsid: 18424972 user: 85/IPRA
flags: (0x100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 20 O/S info: user: oracle, term: UNKNOWN, ospid: 54067284
image: oracle@P740_01_LA
client details:
O/S info: user: appadm, term: SQ-IPRA-APP-1, ospid: 7388:8008
machine: SQ\SQ-IPRA-APP-1 program: Server.WinUi.Job.exe
current SQL:
delete from IWBTAX t where iaxksq in (select ksq from
(select ipdprf as prf,ipdfrm as frm,ipdtkt as tkt,ipdksq as ksq from iwbpdt
union select ivtprf as prf,ivtfrm as frm,ivttkt as tkt,ivtksq as ksq from iwbvtk
union select irtprf as prf,irtfrm as frm,irttkt as tkt,irtksq as ksq from iwbrtk)
where (prf,frm,tkt) in ((:prf,:frm,:tkt)))
----- End of information for the OTHER waiting sessions -----
Information for THIS session:
----- Current SQL Statement for this session (sql_id=620uuhpsnkb6u) -----
delete from IWBTAX t where iaxksq in (select ksq from
(select ipdprf as prf,ipdfrm as frm,ipdtkt as tkt,ipdksq as ksq from iwbpdt
union select ivtprf as prf,ivtfrm as frm,ivttkt as tkt,ivtksq as ksq from iwbvtk
union select irtprf as prf,irtfrm as frm,irttkt as tkt,irtksq as ksq from iwbrtk)
where (prf,frm,tkt) in ((:prf,:frm,:tkt)))
但是這個你怎么解釋？
uj5u.com熱心網友回復：
死鎖問題一般都是邏輯設計有問題，找出sql讓開發修改就好了。要避免同一時間多個會話同時處理同一批資料了。
uj5u.com熱心網友回復：
開發早刪庫到跑路啦
uj5u.com熱心網友回復：
你的delete是走全表掃描 還是索引 另外洗掉動作是否有主從表外鍵資料要處理uj5u.com熱心網友回復：
我知道走索引會導致死鎖，現在的問題是我想知道有什么辦法解決多執行緒并發洗掉同一行的問題。。。
因為洗掉了很多表里的資料啦，又不能亂刪索引啊。
又要并發執行，偶爾會報個錯很難受的
uj5u.com熱心網友回復：
你的這種情況 我到是沒遇到過 但是查了下 大部分都指向表的外鍵問題你都查了trace 自己去google下啊
uj5u.com熱心網友回復：
delete from IWBTAX t where iaxksq in (select ksq from(select ipdprf as prf,ipdfrm as frm,ipdtkt as tkt,ipdksq as ksq from iwbpdt
union select ivtprf as prf,ivtfrm as frm,ivttkt as tkt,ivtksq as ksq from iwbvtk
union select irtprf as prf,irtfrm as frm,irttkt as tkt,irtksq as ksq from iwbrtk)
where (prf,frm,tkt) in ((:prf,:frm,:tkt)))
這里用了 三個 系結變數，兩個會話提供的值，也是不一樣的，并且至少提供了多次值。
會話 1, 提供的 C1, C2, C3 ，會話2 提供 D1, D2, D3 ，兩個會話都沒的提交。
此時，會話 1 又提供 D1,D2, D3, 會話 2 提供 C1, C2, C3 ；
這時會話就會形成。
一個開發也找不到了嗎？ 如果找不到，那就不讓多個會話一起洗掉資料。
uj5u.com熱心網友回復：
邏輯上導致，多個回話同時操作同一條資源，為什么非得在資料庫上找方法解決哦。uj5u.com熱心網友回復：
我不知道 洗掉同一條資料 為什么導致死鎖不過要避免可以啊，比如 設定規則
1.執行緒必須先請求并獲得洗掉權限才能洗掉資料
2.同一時刻最多只能分配給一個執行緒洗掉權限
uj5u.com熱心網友回復：
意思是加鎖解決了？
uj5u.com熱心網友回復：
不是加鎖解決，而是規避資源競爭；不讓多個會話一起洗掉資料，讓他們分開操作。
uj5u.com熱心網友回復：
死鎖如果不是程式邏輯問題，有兩個常見原因：1、外鍵無索引；2、位圖索引uj5u.com熱心網友回復：
那只能在delete 邏輯塊加鎖了，還有別的辦法么？
uj5u.com熱心網友回復：
并發高的情況下，應該想辦法讓鎖盡快釋放，避免爭用可以看看該delete陳述句耗時多久，是否存在優化空間，以及該表和其他表是否存在主外鍵關系
uj5u.com熱心網友回復：
你這個明顯不是刪一條資料啊，而是范圍洗掉，又沒用主鍵：delete from IWBTAX t where iaxksq in
我之前做過類似的優化是先SELECT出主鍵，再根據主鍵洗掉，
當然最保險的還是串行執行洗掉
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/66570.html
標籤：高級技術