TX锁模式为4的情况模拟及探讨（三、进一步了解TX锁（未看））

论坛 › 大数据与云计算 › Oracle数据库与大数据解决方案 › TX锁模式为4的情况模拟及探讨

返回列表

分享到    

查看: 287 | 回复: 7

分享| 收藏 [笔记]TX锁模式为4的情况模拟及探讨[复制链接]

sxitsxit 版主 加好友 发消息 论坛徽章: 3	电梯直达 1 发表于 2012-12-20 11:05:14 | 只看该作者 | 倒序浏览 今天查了下doc，发现 TM 锁模式有2---6这五种，然后想看下 TX锁模式有哪几种，却怎么也找不到。 问了大牛，大牛说最常见的TX锁 模式 为4 和6 ，其他没见到过的一般都是oracle内部人员在使用，日常的开发用不到。 于是就做了下面这个实验 实验环境： OS：win2003 DB：oracle 10.2.0.1 实验说明： 在模拟锁的过程中，insert操作与update、delete及select for update的情况不同；此处我们用insert来模拟，其他几种的模拟情况稍后再发出 实验步骤： insert 操作 在 session 1中 SQL> create table tt(id int primary key);    //此处创建主键约束 表已创建。 SQL> insert into tt values(1); 已创建 1 行。 SQL> insert into tt values(2); 已创建 1 行。 SQL> commit; 提交完成。 SQL> select * from tt;         ID ----------          1          2 再插入一条数据，不提交 SQL> insert into tt values(3); 已创建 1 行。 然后在session 3 中查询，如下 SQL> select  sid,type,id1,id2,lmode ,request,ctime,block from v$lock where sid in(130,116) order by 1,2;        SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK ---------- -- ---------- ---------- ---------- ---------- ---------- ----------        130 TM      56728          0          3          0          3          0        130 TX     393230       1005        6          0          3          0 发现在表上放了 RX 锁，在行上放了 TX 锁 此时在 session 2中插入相同一条数据，发现session 2 被hang住 SQL> select distinct sid from v$mystat;        SID ----------        116 SQL> insert into tt values(3); 重新打开一个新的会话窗口 session 3，做如下查询 SQL> select  sid,type,id1,id2,lmode ,request,ctime,block from v$lock where sid in(130,116) order by 1,2;        SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK ---------- -- ---------- ---------- ---------- ---------- ---------- ----------        116 TM      56728          0          3          0          3          0        116 TX     589840       1061        6          0          3          0        116 TX     393230       1005        0          4          3          0        130 TM      56728          0          3          0        406          0        130 TX     393230       1005        6          0        406          1 从结果可以看到，会话130和116 同时 insert 两条相同的记录违反了主键约束，因而产生了阻塞。 会话 116 被 会话130阻塞，且正在请求模式为 4 的锁，这种锁比update、delete、select for update 的锁级别要小。模式越小，锁的级别越小。 但是为何这里会出现模式为 4的锁呢 ？ 是因为我们在tt表上创建了 primary key 后 ，系统自动在表tt上创建唯一索引， 可以通过如下视图查看到唯一索引 SYS_C008103   。   下面就具体分析一下模式为4的锁为何对应的是索引？ 首先看到 request为4的那一行的 id1=393230 、id2=1005 ，而查询 v$transaction  视图，找到 XIDSQN=1005的记录 SQL> select addr, xidusn, xidslot, XIDSQN,xid ,ubafil ,ubablk ,ubasqn ,ubarec,status from v$transaction where  XIDSQN=1005; ADDR    XIDUSN   XIDSLOT   XIDSQN      XID         UBAFIL   UBABLK  UBASQN  UBAREC STATUS -------- ---------- ---------- ---------- ---------------- ---------- ---------- 6BE29F78   6       14       1005  06000E00ED030000     2      2077   673       17  ACTIVE 其中  UBAFIL是文件编号，UBABLK 为 块编号 ，也就是说模式为4的锁是加在第2个文件的第2077个块上 而从dba_data_files 视图中看到 file_id=2的文件对应的是 UNDOTBS1 表空间 ，也就是undo中的某个段 接下来就是dump出 第2个文件的第2077个块 SQL> alter system dump datafile 2 block 2077; 系统已更改。 然后在udump中找最新的trace文件，部分内容如下 *** 2012-12-20 10:13:32.656 *** SERVICE NAMESYS$USERS) 2012-12-20 10:13:32.640 *** SESSION ID114.16993) 2012-12-20 10:13:32.640 Start dump data blocks tsn: 1 file#: 2 minblk 2077 maxblk 2077 buffer tsn: 1 rdba: 0x0080081d (2/2077) scn: 0x0000.002591b1 seq: 0x02 flg: 0x04 tail: 0x91b10202 frmt: 0x02 chkval: 0x4e42 type: 0x02=KTU UNDO BLOCK Hex dump of block: st=0, typ_found=1 。。。。。。。。。。。。。 。。。。。。。。。。。。。 。。。。。。。。。。。。。 。。。。。。。。。。。。。 *----------------------------- * Rec #0x11  slt: 0x0e  objn: 56729(0x0000dd99)  objd: 56729  tblspc: 4(0x00000004) *       Layer:  10 (Index)   opc: 22   rci 0x10    Undo type:  Regular undo   Last buffer split:  No Temp Object:  No Tablespace Undo:  No rdba: 0x00000000 *----------------------------- index undo for leaf key operations KTB Redo op: 0x04  ver: 0x01   op: L  itl: xid:  0x0007.02e.0000041a uba: 0x0080024b.02e2.32                       flg: C---    lkc:  0     scn: 0x0000.0025919a Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x10001eb block=0x010001ec (kdxlpu): purge leaf row key 3):  02 c1 06 可以看到 objn: 56729(0x0000dd99)，也就是数据对象编号 ；然后再结合dba_objects 视图找到对象的名称和类型 SQL> select object_name,object_type from dba_objects where data_object_id=56729; OBJECT_NAME      OBJECT_TYPE ----------------------------------- SYS_C008103         INDEX 同样，我们可以从user_indexes视图中得到验证 SQL> select index_name,index_type,table_name,uniqueness from user_indexes; INDEX_NAME       INDEX_TYPE     TABLE_NAME       UNIQUENES --------------------------------------------------- ---------- SYS_C008103       NORMAL          TT             UNIQUE 以上关于dump文件中进制间的相互转换，参考盖总的书（dba进阶）和老谢的视频 实验结论： tx锁中模式为4的锁一般在创建索引时会出现   欢迎拍砖，问题是越讨论越明了
	举报

sxitsxit 版主 加好友 发消息 论坛徽章: 3	2 发表于 2012-12-20 11:08:03 | 只看该作者     在这里 TX 为4 模式的锁   可以叫共享锁吗  ？
	举报

renfengjun 版主 O出个未来 加好友 发消息 论坛徽章: 4	3 发表于 2012-12-20 12:50:19 | 只看该作者 楼主啊，我很早的时候看了你的帖子，还特意去查了mos。但是没有发现相关的总结。 4模式还是经常出现的引自mos 62354.1，已经试验过： 例1： --Ses#1:   ALTER TABLE tx_eg ADD CONSTRAINT tx_eg_pk PRIMARY KEY( num ); --Ses#1: INSERT INTO tx_eg VALUES (10,'New','MALE'); --Ses#2: INSERT INTO tx_eg VALUES (10,'OtherNew',null); --DBA: SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX'; SID        TY ID1        ID2        LMODE      REQUEST ---------- -- ---------- ---------- ---------- ----------           8 TX     196625         39          6          0          10 TX     262155         65          6          0          10 TX     196625         39          0          4 复制代码 例2： --Ses#1:   CREATE BITMAP INDEX tx_eg_bitmap ON tx_eg ( sex ); --Ses#1: UPDATE tx_eg SET sex='FEMALE' WHERE num=3; --Ses#2: UPDATE tx_eg SET sex='FEMALE' WHERE num=4; --DBA: SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX';        SID TY        ID1        ID2      LMODE    REQUEST ---------- -- ---------- ---------- ---------- ----------          8 TX     262151         62          6          0         10 TX     327680         60          6          0         10 TX     262151         62          0          4 复制代码 还有一种是关于itl的参数 MAXTRANS 如果大于maxtrans 则会出现等待request 4 的情况。 只能在9i中实现了。 11g ASSM 会自动忽略掉maxtrans参数，默认为最大值255 。 --Ses#1: UPDATE tx_eg SET txt='Garbage' WHERE num=1; --Ses#2:   UPDATE tx_eg SET txt='Different' WHERE num=2; --DBA: SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX'; SID        TY        ID1        ID2      LMODE    REQUEST ---------- -- ---------- ---------- ---------- ----------           8 TX     327688         48          6          0          10 TX     327688         48          0          4 复制代码
	于平凡中，寻找不平凡之处。
	举报

sxitsxit 版主 加好友 发消息 论坛徽章: 3	4 发表于 2012-12-20 13:45:25 | 只看该作者 renfengjun 发表于 2012-12-20 12:50 楼主啊，我很早的时候看了你的帖子，还特意去查了mos。但是没有发现相关的总结。 4模式还是经常出现的引自 ... 哈      技术是越交流越明了哈 我先看看 你说的 doc 62354.1
	举报

sxitsxit 版主 加好友 发消息 论坛徽章: 3	5 发表于 2012-12-20 15:23:19 | 只看该作者 renfengjun 发表于 2012-12-20 12:50 楼主啊，我很早的时候看了你的帖子，还特意去查了mos。但是没有发现相关的总结。 4模式还是经常出现的引自 ... [size=130%]TX Transaction and Enq: Tx - Row Lock Contention - Example wait scenarios [ID 62354.1]   [size=130%]写的很详细哈 [size=130%] [size=130%]从里面提到的细节可以看出，TX =6  也跟TM =6 一样，是排他锁 [size=130%] [size=130%]贴出里面的部分内容 [size=130%] [size=130%]++++++++++++++++++++++++ [size=130%] [size=130%]Waits due to Row being locked by an active TransactionWhen a session updates a row in a table the row is locked by the sessions transaction. Other users may SELECT that row and will see the row as it was BEFORE the UPDATE occurred. If another session wishes to UPDATE the same row it has to wait for the first session to commit or rollback. The second session waits for the first sessions TX lock in EXCLUSIVE mode. --Ses#1:UPDATE tx_eg SET txt='Garbage' WHERE num=1;--Ses#2:UPDATE tx_eg SET txt='Garbage' WHERE num=1;--DBA:SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX';        SID        TY ID1        ID2        LMODE      REQUEST         ---------- -- ---------- ---------- ---------- ----------                  8 TX     131075        597          6          0                 10 TX     131075        597          0          6 This shows SID 10 is waiting for the TX lock held by SID 8 and it wants the lock in exclusive mode (as REQUEST=6). +++++++++++++++++++++++++++++++++++++++++++ 注意 红色那句话 “。。。the lock in exclusive mode。。”  ，也就是锁tx中 6也表示排他锁 还可以通过 v$session 找到会话所等待的块号、行号： 以dba身份登录，执行如下 --DBA:SELECT row_wait_obj#,  row_wait_file#,  row_wait_block#,  row_wait_row#FROM v$sessionWHERE sid=10; ROW_WAIT_O ROW_WAIT_F ROW_WAIT_B ROW_WAIT_R  ---------- ---------- ---------- ----------        3058          4       2683          0 The waiter is waiting for the TX lock in order to lock row 0 in file 4, block 2683 of object 3058. 对于产生TX 的情况，有三种情况，截取部分数据如下： 1：Waits due to Unique or Primary Key Constraint enforcement If a table has a primary key constraint, a unique constraint or a unique index then the uniqueness of the column/s referenced by the constraint is enforced by a unique index. If two sessions try to insert the same key value the second session has to wait to see if an ORA-0001 should be raised or not. --Ses#1: ALTER TABLE tx_eg ADD CONSTRAINT tx_eg_pk PRIMARY KEY( num );--Ses#1: INSERT INTO tx_eg VALUES (10,'New','MALE'); --Ses#2: INSERT INTO tx_eg VALUES (10,'OtherNew',null);--DBA: SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX'; SID        TY ID1        ID2        LMODE      REQUEST ---------- -- ---------- ---------- ---------- ----------          8 TX     196625         39          6          0         10 TX     262155         65          6          0         10 TX     196625         39          0          4 This shows SID 10 is waiting for the TX lock held by SID 8 and it wants the lock in share mode (as REQUEST=4). SID 10 holds a TX lock for its own transaction. --Ses#1: commit; --Ses#2: ORA-00001: unique constraint (SCOTT.TX_EG_PK) violated--Ses#2: rollback; 2：Waits due to Insufficient 'ITL' slots in a Block Oracle keeps note of which rows are locked by which transaction in an area at the top of each data block known as the 'interested transaction list'. The number of ITL slots in any block in an object is controlled by the INITRANS and MAXTRANS attributes. INITRANS is the number of slots initially created in a block when it is first used, while MAXTRANS places an upper bound on the number of entries allowed. Each transaction which wants to modify a block requires a slot in this 'ITL' list in the block. MAXTRANS places an upper bound on the number of concurrent transactions which can be active at any single point in time within a block. INITRANS provides a minimum guaranteed 'per-block' concurrency. If more than INITRANS but less than MAXTRANS transactions want to be active concurrently within the same block then the ITL list will be extended BUT ONLY IF THERE IS SPACE AVAILABLE TO DO SO WITHIN THE BLOCK. If there is no free 'ITL' then the requesting session will wait on one of the active transaction locks in mode 4. --Ses#1: UPDATE tx_eg SET txt='Garbage' WHERE num=1; --Ses#2:UPDATE tx_eg SET txt='Different' WHERE num=2; --DBA:SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX'; SID        TY        ID1        ID2      LMODE    REQUEST ---------- -- ---------- ---------- ---------- ----------          8 TX     327688         48          6          0         10 TX     327688         48          0          4 This shows SID 10 is waiting for the TX lock held by SID 8 and it wants the lock in share mode (as REQUEST=4). --Ses#1: COMMIT; --Ses#2: COMMIT; --Ses#1: ALTER TABLE tx_eg MAXTRANS 2;--Ses#1: UPDATE tx_eg SET txt='First' WHERE num=1; --Ses#2: UPDATE tx_eg SET txt='Second' WHERE num=2; Both rows update as there is space to grow the ITL list to accommodate both transactions. --Ses#1: COMMIT; --Ses#2: COMMIT; From 9.2 you can check the ITL Waits in v$segment_statistics with a query like: SELECT t.owner,  t.object_name,  t.object_type,  t.statistic_name,  t.valueFROM v$segment_statistics tWHERE t.statistic_name = 'ITL waits'AND t.value > 0; If need be, increase INITTRANS and MAXTRANS. In earlier releases of Oracle Database, the MAXTRANS parameter limited the number of transaction entries that could concurrently use data in a data block. This parameter has been deprecated in 10g and higher. Oracle Database now automatically allows up to 255 concurrent update transactions for any data block, depending on the available space in the block. 3：Waits due to rows being covered by the same BITMAP index fragment Bitmap indexes index key values and a range of ROWIDs. Each 'entry' in a bitmap index can cover many rows in the actual table. If 2 sessions wish to update rows covered by the same bitmap index fragment then the second session waits for the first transaction to either COMMIT or ROLLBACK by waiting for the TX lock in mode 4. --Ses#1: CREATE BITMAP INDEX tx_eg_bitmap ON tx_eg ( sex ); --Ses#1: UPDATE tx_eg SET sex='FEMALE' WHERE num=3; --Ses#2: UPDATE tx_eg SET sex='FEMALE' WHERE num=4;--DBA: SELECT sid,type,id1,id2,lmode,request FROM v$lock WHERE type='TX';       SID TY        ID1        ID2      LMODE    REQUEST ---------- -- ---------- ---------- ---------- ----------         8 TX     262151         62          6          0        10 TX     327680         60          6          0        10 TX     262151         62          0          4 This shows SID 10 is waiting for the TX lock held by SID 8 and it wants the lock in share mode (as REQUEST=4). --Ses#1: COMMIT;--Ses#2: COMMIT; 以上就是doc里的部分内容 ，也是关键内容 没有metalink账号的童子可以参考一下这里面的 [size=130%] [size=130%]
	举报

tigerxjtu 版主 加好友 发消息 论坛徽章: 18	6 发表于 2012-12-20 17:35:34 | 只看该作者 不错，学习了
	KISS: Keep It Simple and Stupid 转让Oracle E-Business Suite：ERP DBA实践指南一书，全新，包邮 http://f.dataguru.cn/thread-175116-1-1.html
	举报

sxitsxit 版主 加好友 发消息 论坛徽章: 3	7 发表于 2012-12-20 21:00:17 | 只看该作者 tigerxjtu 发表于 2012-12-20 17:35 不错，学习了 粘贴的时候  格式太乱了 我一会给将整个doc的内容保存一个txt放上去
	举报

sxitsxit 版主 加好友 发消息 论坛徽章: 3

8 发表于 2012-12-20 21:10:33 | 只看该作者 完整的62354.1 doc内容在附件中 62354.rar(4.1 KB, 下载次数: 0)