兩個會話分別只執行一個SQL,可能形成死鎖嗎
1,問題
兩個會話分別只執行一個SQL,可能形成死鎖嗎?
2,測試設想
對於一個大表(比如100萬條記錄),兩個會話分別從一個大表的兩端(頭、尾)更新,就可能形成互相等待對方已佔有資源的情況,從而形成死鎖。
3,測試
3.1測試版本:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
3.2 建立測試用表
create table tmp_x(x int,y int);
插入資料:
insert into tmp_x
select rownum,rownum
from dual
connect by level<1e6+1;
建立索引:
create index idx_tmp_x_x on tmp_x(x);
收集統計資訊:
begin
dbms_stats.gather_table_stats(user,'TMP_X');
end;
/
3.3測試
--會話1
檢視執行計劃:
explain plan for update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1;
select * from table(dbms_xplan.display(null,null,'Advanced'));
Plan hash value: 4167283686
---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 999K| 9765K| 4340 (2)| 00:00:01 |
| 1 | UPDATE | TMP_X | | | | |
|* 2 | INDEX RANGE SCAN| IDX_TMP_X_X | 999K| 9765K| 2254 (2)| 00:00:01 |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X">1)
Column Projection Information (identified by operation id):
-----------------------------------------------------------
2 - (upd=3; cmp=2) "T".ROWID[ROWID,10], "X"[NUMBER,22], "Y"[NUMBER,22]
執行SQL:
update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1;
--會話2
檢視執行計劃(使用提示index_desc,CARDINALITY):
explain plan for update /*+ index_desc(t idx_tmp_x_x) CARDINALITY(t 1000) */ tmp_x t set y=2 where x<1e6;
select * from table(dbms_xplan.display(null,null,'Advanced'));
Plan hash value: 2352573976
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 1000 | 10000 | 4340 (2)| 00:00:01 |
| 1 | UPDATE | TMP_X | | | | |
|* 2 | INDEX RANGE SCAN DESCENDING| IDX_TMP_X_X | 1000 | 10000 | 2254 (2)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X"<1e6)
filter("X"<1e6)
執行SQL:
update /*+ index_desc(t idx_tmp_x_x) CARDINALITY(t 1000) */ tmp_x t set y=2 where x<1e6;
---會話3
檢視會話1,2的等待事件:
select sid,event,blocking_session from v$session where sid in (1894,2324);
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 SQL*Net message from client
2324 SQL*Net message from client
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 db file sequential read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 db file scattered read
2324 gc current request
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current multi block reques
2324 db file scattered read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 gc current request
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 db file sequential read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 db file sequential read
2324 db file scattered read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 log buffer space
2324 log buffer space
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 gc current request
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention
2324 enq: TX - row lock contention
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention 1894
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention 1894
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention 1894
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention
2324 SQL*Net message from client
--會話1
update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
3.4測試結論
兩個會話分別只執行一個SQL,也可能形成死鎖。
兩個會話分別只執行一個SQL,可能形成死鎖嗎?
2,測試設想
對於一個大表(比如100萬條記錄),兩個會話分別從一個大表的兩端(頭、尾)更新,就可能形成互相等待對方已佔有資源的情況,從而形成死鎖。
3,測試
3.1測試版本:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
3.2 建立測試用表
create table tmp_x(x int,y int);
插入資料:
insert into tmp_x
select rownum,rownum
from dual
connect by level<1e6+1;
建立索引:
create index idx_tmp_x_x on tmp_x(x);
收集統計資訊:
begin
dbms_stats.gather_table_stats(user,'TMP_X');
end;
/
3.3測試
--會話1
檢視執行計劃:
explain plan for update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1;
select * from table(dbms_xplan.display(null,null,'Advanced'));
Plan hash value: 4167283686
---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 999K| 9765K| 4340 (2)| 00:00:01 |
| 1 | UPDATE | TMP_X | | | | |
|* 2 | INDEX RANGE SCAN| IDX_TMP_X_X | 999K| 9765K| 2254 (2)| 00:00:01 |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X">1)
Column Projection Information (identified by operation id):
-----------------------------------------------------------
2 - (upd=3; cmp=2) "T".ROWID[ROWID,10], "X"[NUMBER,22], "Y"[NUMBER,22]
執行SQL:
update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1;
--會話2
檢視執行計劃(使用提示index_desc,CARDINALITY):
explain plan for update /*+ index_desc(t idx_tmp_x_x) CARDINALITY(t 1000) */ tmp_x t set y=2 where x<1e6;
select * from table(dbms_xplan.display(null,null,'Advanced'));
Plan hash value: 2352573976
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 1000 | 10000 | 4340 (2)| 00:00:01 |
| 1 | UPDATE | TMP_X | | | | |
|* 2 | INDEX RANGE SCAN DESCENDING| IDX_TMP_X_X | 1000 | 10000 | 2254 (2)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X"<1e6)
filter("X"<1e6)
執行SQL:
update /*+ index_desc(t idx_tmp_x_x) CARDINALITY(t 1000) */ tmp_x t set y=2 where x<1e6;
---會話3
檢視會話1,2的等待事件:
select sid,event,blocking_session from v$session where sid in (1894,2324);
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 SQL*Net message from client
2324 SQL*Net message from client
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 db file sequential read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 db file scattered read
2324 gc current request
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current multi block reques
2324 db file scattered read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 gc current request
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 db file sequential read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 db file sequential read
2324 db file scattered read
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 log buffer space
2324 log buffer space
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 gc current request
2324 gc current request
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention
2324 enq: TX - row lock contention
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention 1894
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention 1894
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention 1894
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention 2324
2324 enq: TX - row lock contention
SQL> /
SID EVENT BLOCKING_SESSION
---------- ----------------------------- ----------------
1894 enq: TX - row lock contention
2324 SQL*Net message from client
--會話1
update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
3.4測試結論
兩個會話分別只執行一個SQL,也可能形成死鎖。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/18922393/viewspace-2153317/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 面試官:請用SQL模擬一個死鎖面試SQL
- sql 注入將會是一個笑話SQL
- 多執行緒的這些鎖知道嗎?手寫一個自旋鎖?執行緒
- 使用select,兩個case 讀取 同一個chan 中的資料,兩個case都可能被執行到
- 什麼?一個核同時執行兩個執行緒?執行緒
- MySQL:Innodb 一個死鎖案例MySql
- MySQL:一個死鎖分析 (未分析出來的死鎖)MySql
- 為什麼建議一個容器中只執行一個程式
- Slave SQL執行緒與PXB FTWRL死鎖問題分析SQL執行緒
- 執行緒中的死鎖執行緒
- 【JUC】2-一把“鎖”兩個“並”三個“程”(JAVA多執行緒相關概念)Java執行緒
- 一個“指令碼執行夯死”問題的分析指令碼
- Java多執行緒(五):死鎖Java執行緒
- 如何處理執行緒死鎖執行緒
- java多執行緒(5)死鎖Java執行緒
- 用個通俗的例子講一講死鎖
- SQL Server 的死鎖SQLServer
- 在一臺電腦上執行兩個或多個tomcatTomcat
- SQL查詢一年的十二個月份,形成報表SQL
- 為什麼dispatch_sync在主執行緒會死鎖執行緒
- PostgreSQL模擬兩個update語句死鎖-利用掃描方法SQL
- 在DOM上同時繫結兩個點選事件(一個用捕獲,一個用冒泡),事件總共會執行幾次,先執行哪個事件?事件
- mysql一次執行多個SQL檔案MySql
- 死磕 java執行緒系列之自己動手寫一個執行緒池Java執行緒
- 一個高頻問題:非同步操作會建立執行緒嗎?非同步執行緒
- 這個SQL你會最佳化嗎?SQL
- Mysql 兩階段鎖和死鎖MySql
- 一個執行緒,從“生”到“死”經歷的過程執行緒
- FFmpeg開發筆記(十九)FFmpeg開啟兩個執行緒分別解碼音影片筆記執行緒
- 記一次排查線上MySQL死鎖過程,不能只會curd,還要知道加鎖原理MySql
- SQL SERVER死鎖查詢,死鎖分析,解鎖,查詢佔用SQLServer
- 剖析6個MySQL死鎖案例的原因以及死鎖預防策略MySql
- 如果一個標籤元素同時出現兩個class屬性,兩個class都會生效嗎?為什麼?
- golang 執行時死鎖排查和檢測Golang
- 阿里二面:如何定位&避免死鎖?連著兩個面試問到了!阿里面試
- IDEA如何同時執行兩個ModulesIdea
- 精盡MyBatis原始碼分析 - SqlSession 會話與 SQL 執行入口MyBatis原始碼SQLSession會話
- 開啟一個jsf會話失效JS會話