本篇内容主要讲解“怎么验证LOCK请求的FIFO机制”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么验证LOCK请求的FIFO机制”吧!

在多并发的会话场景中，需要先获取资源的X锁定才能对该资源进行修改。与此同时，当其他会话也同样请求修改该资源时，则必须按照先进先服务的方式（FIFO）进入请求队列排队等候。以下实验可以验证这一机制。

创建表

create table t1(c1number, c2 number);

insert into t1values(101, 5000);

commit;

三个会话按照先后顺序试图更新数据，会话的SID可以通过以下查询获取

selectuserenv('sid') from dual;

Session1（SID：129）

update t1 set c2=6000where c1=101;

Session2（SID：135）

update t1 set c2=7000where c1=101;

Session3（SID：138）

update t1 set c2=8000where c1=101;

可以看到，Session1执行更新后因为没有提交，Session2和Session3都在等待。此时查询事务信息，显示有一个事务

select xid, addr,ses_addr, xidusn, xidslot, xidsqn, ubafil, ubablk, ubasqn, ubarec, status,start_time from v$transaction;

XID ADDR SES_ADDR XIDUSN XIDSLOTXIDSQN UBAFIL UBABLKUBASQN UBAREC STATUS START_TIME

-------------------------------- ---------------- ---------- ---------- ---------- -------------------- ---------- ---------- ---------------- --------------------

0100060090020000000007FF49D24CA8 000007FF4C78B2A01 6 656 3 717 145 35 ACTIVE 10/04/17 11:44:47

查看锁定信息，存在事务回滚段号XIDUSN的会话表示正在执行的事务，129会话优先获取锁，XIDUSN为0则表示会话被锁，处于等待状态，LOCKED_MODE为3表示行独占锁

col oracle_username fora15

select * fromv$locked_object;

XIDUSNXIDSLOT XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAMEOS_USER_NAMEPROCESSLOCKED_MODE

---------- -------------------- ---------- ---------- --------------- ------------------------------------------------------ -----------

1 6 65673449 129 SYS VM-ORA11G-1\Administrator 3136:1796 3

0 0 073449 135 SYS VM-ORA11G-1\Administrator 2932:2184 3

0 0 073449 138 SYS VM-ORA11G-1\Administrator 3820:2100 3

再看锁队列，129会话因为已经获取到锁，所以只有AE会话锁，没有TX锁请求，CTIME为请求时间，135会话先于138会话，REQUEST大于0表示当前会话被阻塞，其它会话以对应的模式占有锁

select * fromv$enqueue_lock where sid in (129, 135, 138);

ADDR KADDR SID TY ID1 ID2LMODE REQUEST CTIMEBLOCK

-------------------------------- ---------- -- ---------- ---------- ---------- -------------------- ----------

000007FF4CC56968000007FF4CC569C0 129 AE 100 0 4 0 6898 0

000007FF4CC56BD8000007FF4CC56C30 135 AE 100 0 4 0 3183 0

000007FF4CC56E48000007FF4CC56EA0 135 TX 65542 656 0 6 3152 1

000007FF4CC56F18000007FF4CC56F70 138 AE 100 0 4 0 3140 0

000007FF4CC57000000007FF4CC57058 138 TX 65542 656 0 6 3106 0

锁类型TYPE列的定义：TM-表级锁，TX-事务锁，MR-Media Recovery（每个文件一个），AE-会话锁（每个会话一个），UL-用户定义的锁类型

锁模式LMODE列的定义：0-none；1-空（NULL）；2-行共享（RS）；3-行独占（RX）；4-共享锁（S）；5-共享行独占（SRX）；6-独占锁（X）

dump等待队列，可见129会话que为own表示正在持有锁，135会话和138会话que为wat表示正在锁请求等待

oradebug setmypid

oradebug tracefile_name

oradebug dump enqueues 8

000007FF4CD05DC0TX-00010006-00000290 U 0 00 0 0 140 [4cd25530,4cd25530]

[49d24d30,49d24d30][4cd05df0,4cd05df0] [4cc56eb0,4cc57068]

lockque owner session hold wait ser link

----------------------------------------------------------------------

000007FF49D24D20 OWN 000007FF4C78B2A0000007FF4C78B2A0 (129) X NLCK 73 [4cd05dd0,4cd05dd0]

000007FF4CC56EA0 WAT 000007FF4C779C00000007FF4C779C00 (135) NLCK X 1468[4cc57068,4cd05de0]

000007FF4CC57058 WAT 000007FF4C7710B0000007FF4C7710B0 (138) NLCK X 1191[4cd05de0,4cc56eb0]

对照验证，将Session1提交，查看事务，新的事务在执行

select xid, addr,ses_addr, xidusn, xidslot, xidsqn, ubafil, ubablk, ubasqn, ubarec, status,start_time from v$transaction;

XID ADDR SES_ADDR XIDUSN XIDSLOTXIDSQN UBAFIL UBABLKUBASQN UBAREC STATUS START_TIME

-------------------------------- ---------------- ---------- ---------- ---------- -------------------- ---------- ---------- ---------------- --------------------

050006005D030000000007FF49D256A8 000007FF4C779C005 6 861 3 536 187 14 ACTIVE 10/04/17 11:45:36

查看锁定对象，129会话的锁已释放，所以无记录，135会话正在执行事务而获得锁，138会话则继续等待

col oracle_username fora15

select * fromv$locked_object;

XIDUSNXIDSLOT XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAMEOS_USER_NAMEPROCESSLOCKED_MODE

---------- -------------------- ---------- ---------- --------------- ------------------------------------------------------ -----------

5 6 86173449 135 SYS VM-ORA11G-1\Administrator 2932:2184 3

0 0 073449 138 SYS VM-ORA11G-1\Administrator 3820:2100 3

查看请求队列，129会话和135会话都已经获取了请求，138会话仍有TX锁请求

select * fromv$enqueue_lock where sid in (129, 135, 138);

ADDR KADDR SID TYPE ID1 ID2LMODE REQUEST CTIMEBLOCK

-------------------------------- ---------- ---- ---------- ---------- ---------- -------------------- ----------

000007FF4CC56968000007FF4CC569C0 129 AE 100 0 4 021793 0

000007FF4CC56BD8000007FF4CC56C30 135 AE 100 0 4 018078 0

000007FF4CC56E48000007FF4CC56EA0 138 TX 327686 861 0 6 674 0

000007FF4CC56F18000007FF4CC56F70 138 AE 100 0 4 018035 0

dump等待队列，可见135会话que为own表示正在持有锁，138会话que为wat表示正在锁请求等待

oradebug setmypid

oradebug tracefile_name

oradebug dump enqueues 8

000007FF4CD07F98TX-00050006-0000035d U 0 00 0 0 140 [4cd25bc0,4cd25bc0]

[49d25730,49d25730][4cd07fc8,4cd07fc8] [4cc56eb0,4cc56eb0]

lockque owner session hold wait ser link

----------------------------------------------------------------------

000007FF49D25720 OWN 000007FF4C779C00000007FF4C779C00 (135) X NLCK 1468[4cd07fa8,4cd07fa8]

000007FF4CC56EA0 WAT 000007FF4C7710B0000007FF4C7710B0 (138) NLCK X 1191[4cd07fb8,4cd07fb8]

对照验证，将Session2提交，查看事务，又一新的事务在执行

select xid, addr,ses_addr, xidusn, xidslot, xidsqn, ubafil, ubablk, ubasqn, ubarec, status,start_time from v$transaction;

XID ADDR SES_ADDR XIDUSN XIDSLOTXIDSQN UBAFIL UBABLKUBASQN UBAREC STATUS START_TIME

-------------------------------- ---------------- ---------- ---------- ---------- -------------------- ---------- ---------- ---------------- --------------------

09000D003D030000000007FF49CC9678 000007FF4C7710B09 13 829 3 2477 184 28 ACTIVE 10/04/17 11:46:22

查看锁定对象，135会话的锁也已释放，138会话正在执行事务而获得锁，没有会话在等待了

col oracle_username fora15

select * fromv$locked_object;

XIDUSNXIDSLOT XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAMEOS_USER_NAMEPROCESSLOCKED_MODE

---------- -------------------- ---------- ---------- --------------- ------------------------------------------------------ -----------

9 13 82973449 138 SYS VM-ORA11G-1\Administrator 3820:2100 3

查看请求队列，已经没有TX锁请求

select * fromv$enqueue_lock where sid in (129, 135, 138);

ADDR KADDR SID TY ID1 ID2LMODE REQUEST CTIMEBLOCK

-------------------------------- ---------- -- ---------- ---------- ---------- -------------------- ----------

000007FF4CC56968000007FF4CC569C0 129 AE 100 0 4 024483 0

000007FF4CC56BD8000007FF4CC56C30 135 AE 100 0 4 020768 0

000007FF4CC56F18000007FF4CC56F70 138 AE 100 0 4 020725 0

dump等待队列，只有138会话的记录了，并且que为own表示已经拥有

oradebug setmypid

oradebug tracefile_name

oradebug dump enqueues 8

000007FF4CD00378TX-0009000d-0000033d U 0 00 0 0 140 [4cd23730,4cd23730]

[49cc9700,49cc9700][4cd003a8,4cd003a8] [4cd00398,4cd00398]

lockque owner session hold wait ser link

----------------------------------------------------------------------

000007FF49CC96F0 OWN 000007FF4C7710B0000007FF4C7710B0 (138) X NLCK 1191[4cd00388,4cd00388]

如果此时关闭已经提交了的Session1和Session2会话，则请求队列中不会再有129和135会话的AE锁记录，在Oracle 11g中AE锁是每个会话都会有一个的，对于Oracle10g则不存在AE会话锁

select * fromv$enqueue_lock where sid in (129, 135, 138);

ADDR KADDR SID TY ID1 ID2LMODE REQUEST CTIMEBLOCK

-------------------------------- ---------- -- ---------- ---------- ---------- -------------------- ----------

000007FF4CC56F18000007FF4CC56F70 138 AE 100 0 4 021120 0

由此，我们通过实验来验证了锁队列的FIFO机制，遵循先请求先服务的原则。

最后，清理实验用表

drop table t1 purge;

到此，相信大家对“怎么验证LOCK请求的FIFO机制”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！