2. 程式人生 > >外來鍵缺乏索引導致的Oracle資料庫死鎖

外來鍵缺乏索引導致的Oracle資料庫死鎖

阿新 • • 發佈：2019-02-16
Global Enqueue Services Deadlock detected. More info in file /u01/app/oracle/diag/rdbms/mdmdb/mdmdb1/trace/mdmdb1_ora_2752986.trc.

檢視 mdmdb1_ora_2752986.trc 檔案中的內容：

Trace file /u01/app/oracle/diag/rdbms/mdmdb/mdmdb1/trace/mdmdb1_ora_65732640.trcOracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit ProductionWith the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,...Single resource deadlock: blocking enqueue which blocks itself, f 0

Granted global enqueue 700000356fa12a8----------enqueue 700000356fa12a8------------------------lock version     : 107165Owner inst       : 1grant_level      : KJUSERNLreq_level        : KJUSERPWbast_level       : KJUSERNLnotify_func      : 0resp             : 70000036b321090procp            : 700000352b7f3c8pid              : 21954568proc version     : 89oprocp           : 0opid             : 21954568group lock owner : 7000003565f7208possible pid     : 21954568xid              : 101C-01C9-00000C78dd_time          : 10.0 secsdd_count         : 0timeout          : 0.0 secsOn_timer_q?      : NOn_dd_q?         : Ylock_state       : OPENING CONVERTING ast_flag         : 0x0Open Options     : KJUSERDEADLOCK Convert options  : KJUSERGETVALUE History          : 0x4951449aMsg_Seq          : 0x0res_seq          : 5valblk           : 0x07000002899609580000000110d3fb10 .Xuser session for deadlock lock 0x700000356fa12a8  sid: 452 ser: 11575 audsid: 374059 user: 85/MDM    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-    flags2: (0x40009) -/-/INC  pid: 457 O/S info: user: grid, term: UNKNOWN, ospid: 21954568    image:
[email protected]  client details:    O/S info: user: root, term: , ospid: 27811    machine: phy-mdm-121 program: [email protected] (TNS V1-V3)    application name: [email protected] (TNS V1-V3), hash value=14486045  current SQL:  DELETE FROM t_device WHERE t_device.id = :idRequesting global enqueue 700000358ec44e0----------enqueue 700000358ec44e0------------------------lock version     : 87133Owner inst       : 1grant_level      : KJUSERCWreq_level        : KJUSERPWbast_level       : KJUSERNLnotify_func      : 0resp             : 70000036b321090
procp            : 700000352b29748pid              : 65732640proc version     : 154oprocp           : 0opid             : 65732640group lock owner : 7000003546d2ad0possible pid     : 65732640xid              : 1013-0136-000001A4dd_time          : 0.0 secsdd_count         : 0timeout          : 0.0 secsOn_timer_q?      : NOn_dd_q?         : Nlock_state       : CONVERTING ast_flag         : 0x0Open Options     : KJUSERDEADLOCK Convert options  : KJUSERGETVALUE History          : 0x51449a55Msg_Seq          : 0x0res_seq          : 5valblk           : 0x07000003565f72080700000356fa12a8 .V_rVuser session for deadlock lock 0x700000358ec44e0  sid: 1083 ser: 1655 audsid: 373847 user: 85/MDM    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-    flags2: (0x40009) -/-/INC  pid: 310 O/S info: user: grid, term: UNKNOWN, ospid: 65732640    image: [email protected]  client details:    O/S info: user: root, term: , ospid: 21862    machine: phy-mdm-130 program: [email protected] (TNS V1-V3)    application name: [email protected] (TNS V1-V3), hash value=3173956709  current SQL:  DELETE FROM t_device WHERE t_device.id = :id----------resource 70000036b321090----------------------resname       : [0x13d03][0x0],[TM][ext 0x0,0x0]hash mask     : x3Local inst    : 1dir_inst      : 1master_inst   : 1hv idx        : 98hv last r.inc : 8current inc   : 8hv status     : 0hv master     : 0open options  : dd cached grant_bits    : KJUSERNL KJUSERCW grant mode    : KJUSERNL  KJUSERCR  KJUSERCW  KJUSERPR  KJUSERPW  KJUSEREXcount         : 1         0         4         0         0         0val_state     : KJUSERVS_NOVALUEvalblk        : 0x00000000000000000000000000000000 .access_inst   : 1vbreq_state   : 0state         : x0resp          : 70000036b321090On Scan_q?    : Ncache level   : 0Total accesses: 336659265Imm.  accesses: 336357556Granted_locks : 4 Cvting_locks  : 1 value_block:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00GRANTED_Q :lp 700000354c49708 gl KJUSERCW rp 70000036b321090 [0x13d03][0x0],[TM][ext 0x0,0x0]  master 1 gl owner 7000003525fb4f8 possible pid 16122136 xid 101E-01EB-00000177 bast 0 rseq 5 mseq 0 history 0x51449a51  open opt KJUSERDEADLOCK  lp 70000035aca2438 gl KJUSERCW rp 70000036b321090 [0x13d03][0x0],[TM][ext 0x0,0x0]  master 1 gl owner 70000035a680930 possible pid 65601692 xid 101B-01B1-0000041A bast 0 rseq 5 mseq 0 history 0x51449a51  open opt KJUSERDEADLOCK  lp 70000036cfa71c0 gl KJUSERCW rp 70000036b321090 [0x13d03][0x0],[TM][ext 0x0,0x0]  master 1 gl owner 70000035264bbb0 possible pid 39190724 xid 1008-008F-00000286 bast 0 rseq 5 mseq 0 history 0x51449a51  open opt KJUSERDEADLOCK  lp 700000358ec44e0 gl KJUSERCW rp 70000036b321090 [0x13d03][0x0],[TM][ext 0x0,0x0]  master 1 gl owner 7000003546d2ad0 possible pid 65732640 xid 1013-0136-000001A4 bast 0 rseq 5 mseq 0 history 0x51449a55  open opt KJUSERDEADLOCK  CONVERT_Q: lp 700000356fa12a8 gl KJUSERNL rl KJUSERPW rp 70000036b321090 [0x13d03][0x0],[TM][ext 0x0,0x0]  master 1 gl owner 7000003565f7208 possible pid 21954568 xid 101C-01C9-00000C78 bast 0 rseq 5 mseq 0 history 0x4951449a  convert opt KJUSERGETVALUE   

相關推薦

外來鍵缺乏索引導致的Oracle資料庫死鎖

Global Enqueue Services Deadlock detected. More info in file /u01/app/oracle/diag/rdbms/mdmdb/mdmdb1/trace/mdmdb1_ora_2752986.trc.檢視 mdmdb1_ora_2752986.trc

關於oracle資料庫死鎖的解決 以及產生的原因

前段時間寫sql語句事物造成了資料庫死鎖，導致所有更新操作無法執行 1.查死鎖 檢視關於鎖的會話資訊 select * from v$session t1, v$locked_object t2 where t1.sid = t2.SESSION_ID   &nb

mysql-不恰當的update語句使用主鍵和索引導致mysql死鎖

行修改 sql錯誤 狀態 還要 錯誤日誌 示意圖 http 概率 最小 背景知識：MySQL有三種鎖的級別：頁級、表級、行級。 MyISAM和MEMORY存儲引擎采用的是表級鎖（table-level locking）；BDB存儲引擎采用的是頁面鎖（page-level l

oracle匯入表資料時遇到外來鍵約束問題導致匯入失敗

1、先關掉所有外來鍵約束： SELECT 'alter table  '|| t.table_name || ' disable constraint ' || t.CONSTRAINT_NAME || ';' FROM USER_CONSTRAINTS t WHERE t.CONST

資料庫——主鍵、外來鍵、索引

概念： 主鍵(primary key)：  能夠唯一標識表中某一行的屬性或屬性組。一個表只能有一個主鍵，但可以有多個候選索引。主鍵常常與外來鍵構成參照完整性約束，防止出現數據不一致。主鍵可以保證記錄的唯一和主鍵域非空,資料庫管理系統對於主鍵自動生成唯一索引，所以主鍵也是一個特殊的索

資料庫的幾個概念：主鍵，外來鍵，索引，唯一索引

主鍵：       主鍵是資料表的唯一索引，比如學生表裡有學號和姓名，姓名可能有重名的，但學號確是唯一的，你要從學生表中搜索一條紀錄如查詢一個人，就只能根據學號去查詢，這才能找出唯一的一個，這就是主鍵;如：id int(10) not null primary key aut

ORACLE中關於外來鍵缺少索引的探討和總結

作者：瀟湘隱者 在ORACLE資料庫中，定義外來鍵約束時，ORACLE是不會自動建立對應索引的，必須手動在外來鍵約束相關的列上建立索引。那麼外來鍵欄位上是否有必要建立索引呢？如果有必要的話，巡檢時，如何找出外來鍵欄位上沒有建立索引的相關表，並生成對應的索引的指

mysql查詢指定庫的所有表的記錄數、外來鍵、索引、檢視、觸發器等

--  查詢指定庫的所有表資料行數 use information_schema; select table_name,table_rows from tables  where TABLE_SCHEMA = 'cs_lanzhou'  order by table

資料庫主鍵和外來鍵及索引

1、主鍵： 若某一個屬性組（注意是組）能唯一標識一條記錄，該屬性組就是一個主鍵。主鍵不能重複，且只能有一個，也不允許為空。定義主鍵主要是為了維護關係資料庫的完整性。 2、外來鍵： 外來鍵用於與另一張表的關聯，是能確定另一張表記錄的欄位。外來鍵是另一個表的主鍵，可以重

資料庫死鎖導致分佈事務中大批量更新資料庫不成功

1 問題描述 未簽收的訂單十五天之後自動簽收：總共2個步驟： step1 在樂購系統中批量更新未簽收訂單的狀態，step2: 通過RPC修改訂單系統的訂單狀態， step1和step2放到一個事務中。然後發現step2 訂單DB狀態修改成功，但是step1 樂購db的訂單狀態並未修改。 2 排查過程 懷疑是

mysql死鎖-非主鍵索引更新引起的死鎖

背景：最近線上經常丟擲mysql的一個Deadlock，細細查來，長了知識！分析：錯誤日誌如下:21:02:02.563 ERROR dao.CommonDao        [pool-15-thread-19] [jbc.trade.qunar.com] [703c9dd

listener.log檔案過大導致oracle資料庫連線非常慢

最近發現oracle資料庫連線非常慢，sqlplus很快，用客戶端就很慢，甚至會無響應。 然後伺服器記憶體一下就飆升到了90%，不是表空間佔滿了，也不是資料庫連線數佔滿了。重啟還是一樣！ 在客戶端連線伺服器的時候，點選“登入”，需要很久（正常1，2秒就行）才可以連線到資料庫

關於在專案中遇到MySQL資料庫死鎖的問題

在MySQL中, 當一個事務去更新某條資料, 還沒有提交的時候, 第二個事務去更新該資料, 則會出現等待獲取鎖超時異常: >>　　Lock wait timeout exceeded; try restarting transaction 此異

資料庫死鎖_死鎖荔枝_解決方法

轉自高效能mysql；   【1.3.2】死鎖 1）死鎖定義：指兩個或多個事務在同一資源上相互佔用， 並請求鎖定對方佔用的資源，從而導致惡性迴圈的現象； 當多個事務試圖以不同順序鎖定資源時，就可能產生死鎖；多個事務同時鎖定同一個資源時，也會產生死鎖； 2）死鎖解決方法

MySQL資料庫死鎖原因及解決

      資料庫和作業系統一樣，是一個多使用者使用的共享資源。當多個使用者併發地存取資料 時，在資料庫中就會產生多個事務同時存取同一資料的情況。若對併發操作不加控制就可能會讀取和儲存不正確的資料，破壞資料庫的一致性。加鎖是實現資料庫並 發控制的一個非常重要的技術。在實

利用opensips實現freeswitch負載均衡的資料庫死鎖問題

多個freeswitch實現負載均衡，要使用同一個資料庫，這樣每個freeswitch都要建立到資料庫的連線，在每個呼叫結束時，都要到資料庫中刪除一些資料，比如要到calls表刪除呼叫資訊，如果多個freeswitch同時進行刪除操作，有可能會產生死鎖，比如： 2018-0

程式設計面試題：編寫一個會造成資料庫死鎖的應用

相信對於"開發一個會產生死鎖的Java應用”這類需求，大家都能順利完成。但是如果題目要求得更具體一些，要求這個死鎖發生在資料庫層面，應該怎樣完成呢？ 下面我提供一種答案，採用SAP的程式語言ABAP(Advanced Business Application Programming)實現。 我們從ABAP幫

MySQL 5.7.25資料庫死鎖

1、檢視innodb狀態 show engine innodb status\G 2、開啟lock_monitor監控 use databases sys; create table innodb_lock_monitor(x int) engine=innodb; 3、查詢程序 m

導致DllMain中死鎖的關鍵隱藏因子

        有了前面兩節的基礎，我們現在切入正題：研究下DllMain為什麼會因為不當操作導致死鎖的問題。首先我們看一段比較經典的“DllMain中死鎖”程式碼。 //主執行緒中 HMODULE h = LoadLibraryA(strDllName.c_str

資料庫死鎖及解決方法

死鎖的概念：   死鎖是指兩個或者兩個以上的事務在執行過程中，因爭奪鎖資源而造成的一種互相等待的現象。 死鎖的處理機制：  解決死鎖最有用最簡單的方法是不要有等待，將任何等待都轉化為回滾，並且事務重新開始。但是有可能影響併發效能。 1：超時回滾，即當兩個事務互相等待時，