两个会话分别只执行一个SQL会不会形成死锁
这篇文章给大家介绍两个会话分别只执行一个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会不会形成死锁就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
标题名称：两个会话分别只执行一个SQL会不会形成死锁
当前URL：http://pwwzsj.com/article/jogcjs.html
