还是锁问题--alert system session无法执行

[mer1234567]

v$lock 里发现了几个锁有to，tx类型的
使用 alter system kill session 'sid,serial#';无法执行，一直处在等待状态。
这是怎么回事呢

另：v$lock type各类型什么意思请指教

[essenza]

以下转的:

其中在TYPE字段的取值中，本文只关心TM、TX两种DML锁类型；
关于ID1、ID2，TYPE取值不同其含义也有所不同：
TYPE ID1 ID2
TM 被修改表的标识（object_id） 0
TX 以十进制数值表示该事务所占用的回滚段号与该事务在该回滚段的事务表（Transaction table）中所占用的槽号（slot number，可理解为记录号）。其组成形式为： 0xRRRRSSSS ( RRRR = RBS number, SSSS = slot )。 以十进制数值表示环绕（wrap）次数，即该槽（slot）被重用的次数；




$locked_object视图列出当前系统中哪些对象正被锁定，其主要字段说明如下：
字段名称 类型 说明
XIDUSN NUMBER 回滚段号；
XIDSLOT NUMBER 槽号；
XIDSQN NUMBER 序列号；
OBJECT_ID NUMBER 被锁对象标识；
SESSION_ID NUMBER 持有锁的会话（SESSION）标识；
ORACLE_USERNAME VARCHAR2（30） 持有该锁的用户的Oracle用户名；
OS_USER_NAME VARCHAR2（15） 持有该锁的用户的操作系统用户名；
PROCESS VARCHAR2（9） 操作系统的进程号；
LOCKED_MODE NUMBER 锁模式，取值同表三中的LMODE；




SESS#1：
SQL> select * from dept for update;
DEPTNO DNAME LOC
---------- -------------- -------------
10 account 70
20 research 8
30 sales 8
40 operations 8
SESS#3：
SQL> @showlock
O_NAME SID LOCK_TYPE OBJECT_NAME XIDUSN XIDSLOT XIDSQN
---------- ----- --------------- --------------- ------ ------- ------
SCOTT 17 Row share DEPT 8 2 5861
SQL> @showalllock
SID TY ID1 ID2 LOCK_TYPE REQUEST CTIME BLOCK
----- -- ---------- ---------- --------------- ---------- ---------- ----------
17 TX 524290 5861 Exclusive 0 761 0
17 TM 32970 0 Row share 0 761 0

如第一个脚本showlock所示，执行完SELECT…FOR UPDATE 语句后， SESS#1（SID为17）在DEPT表上获得Row share锁；如第二个脚本showalllock所示，SESS#1获得的TX锁为Exclusive，这些都验证了上面的理论分析。另外，我们可以将TX锁的ID1按如下方法进行分解：
SQL> select trunc(524290/65536) xidusn,mod(524290,65536) xidslot from dual;
XIDUSN XIDSLOT
------ -------
8 2
分解结果与第一个脚本直接查出来的XIDUSN与XIDSLOT相同，而TX锁的ID2（5861）与XIDSQN相同，可见当LOCK TYPE为TX时，ID1实际上是该事务所占用的回滚段段号与事务表中的槽（SLOT）号的组合，ID2即为该槽被重用的次数，而这三个值实际上可以唯一地标识一个事务，即TRANSACTION ID，这三个值从系统表v$transaction中也可查到。
另外， DEPT表中有4条记录被锁定，但TX锁只有1个，这也与上面的理论分析一致。继续进行操作：
SESS#2：
SQL> update dept set loc=loc where deptno=20;
该更新语句被阻塞，此时再查看系统的锁情况：
SESS#3：
SQL> @showlock
O_NAME SID LOCK_TYPE OBJECT_NAME XIDUSN XIDSLOT XIDSQN
---------- ----- --------------- --------------- ------ ------- ------
SCOTT 17 Row share DEPT 8 2 5861
SCOTT 19 Row Exclusive DEPT 0 0 0
SQL> @showalllock
SID TY ID1 ID2 LOCK_TYPE REQUEST CTIME BLOCK
----- -- ---------- ---------- --------------- ---------- ---------- ----------
17 TX 524290 5861 Exclusive 0 3462 1
17 TM 32970 0 Row share 0 3462 0
19 TM 32970 0 Row Exclusive 0 7 0
19 TX 524290 5861 None 6 7 0
在DEPT表上除了SESS#1（SID为17）持有Row share锁外，又增加了SESS#2（SID为19）持有的Row Exclusive锁，但还没有为SESS#2分配回滚段（XIDUSN、XIDSLOT、XIDSQN的值均为0）；而从第二个脚本看到，SESS#2的TX锁的LOCK_TYPE为None，其申请的锁类型（REQUEST）为6（即Exclusive），而其ID1、ID2的值与SESS#1所持有的TX锁的ID1、ID2相同，SESS#1的TX锁的阻塞域（BLOCK）为1，这就说明了由于SESS#1持有的TX锁，阻塞了SESS#2的更新操作（SESS#2所更新的行与SESS#1所锁定的行相冲突）。还可以看出，SESS#2先申请表级的TM锁，后申请行（事务）级的TX锁，这也与前面的理论分析一致。
下面，将SESS#1的事务进行回滚，解除对SESS#2的阻塞，再对系统进行监控。
SESS#3：
SQL> @showlock
O_NAME SID LOCK_TYPE OBJECT_NAME XIDUSN XIDSLOT XIDSQN
---------- ----- --------------- --------------- ------ ------- ------
SCOTT 19 Row Exclusive DEPT 2 10 5803
SQL> @showalllock
SID TY ID1 ID2 LOCK_TYPE REQUEST CTIME BLOCK
----- -- ---------- ---------- --------------- ---------- ---------- ----------
19 TX 131082 5803 Exclusive 0 157 0
19 TM 32970 0 Row Exclusive 0 333 0
可以看到，SESS#1的事务所持有的锁已经释放，系统为SESS#2的事务分配了回滚段，而其TX锁也已经获得，并且ID1、ID2是其真正的Transaction ID。再将会话2的事务进行回滚。
SESS#2：
SQL> rollback;
Rollback complete.
检查系统锁的情况：
SESS#3：
SQL> @showlock
no rows selected
SQL> @showalllock
no rows selected
可以看到，TM与TX锁已全部被释放。

[mer1234567]

学习了
继续up

[rain_zheng]

mark