兩個會話分別只執(zhí)行一個SQL會不會形成死鎖

這篇文章給大家介紹兩個會話分別只執(zhí)行一個SQL會不會形成死鎖，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

1，問題
   兩個會話分別只執(zhí)行一個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 創(chuàng)建測試用表
create table tmp_x(x int,y int);

插入數(shù)據：
insert into tmp_x
select rownum,rownum
from dual
connect by level<1e6+1;

創(chuàng)建索引：
create index idx_tmp_x_x on tmp_x(x);

收集統(tǒng)計信息：
begin
  dbms_stats.gather_table_stats(user,'TMP_X');
end;
/  


3.3測試
--會話1

查看執(zhí)行計劃：
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]



執(zhí)行SQL：
update /*+ index_asc(t idx_tmp_x_x) */ tmp_x t set y=1 where x>1;



--會話2

查看執(zhí)行計劃（使用提示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)


執(zhí)行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測試結論
  兩個會話分別只執(zhí)行一個SQL，也可能形成死鎖。

關于兩個會話分別只執(zhí)行一個SQL會不會形成死鎖就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。