同事說測試庫上的一張表被鎖了。 不能執行dml 操作。 鎖表的準確說法應該是阻塞。之前的一遍blog裡有說明：
鎖 死鎖 阻塞latch 等待 詳解
找多鎖表的session，並kill 掉之後，對該錶的dml 操作正常。 這裡在模擬一次這個問題。
開2個session：
session a：
sql>select sid from v$mystat whererownum=1;
sidsession b：
sql> select sid from v$mystat whererownum=1;
sidsession a 更新表t1，不commit：
sql>update t1 set object_id=100 where object_id=20;
2 rows updated.
session b 執行同樣的操作，測試session b 會掛住：
sql> update t1 set object_id=100 whereobject_id=20;
--在session a commit 之前，一直處於等待狀態..
檢視表上鎖的情況：
select sn.username,
m.sid,
sn.serial#,
m.type,
decode (m.lmode,
0,'none',
1,'null',
2,'rowshare',
3,'rowexcl.',
4,'share',
5,'s/rowexcl.',
6,'exclusive',
lmode,
ltrim (to_char (lmode, '990')))
lmode,
decode (m.request,
0,'none',
1,'null',
2,'rowshare',
3,'rowexcl.',
4,'share',
5,'s/rowexcl.',
6,'exclusive',
request,
ltrim (to_char (m.request, '990')))
request,
m.id1,
m.id2
from v$session sn, v$lock m
where (sn.sid = m.sid and m.request != 0) --存在鎖請求，即被阻塞
or (sn.sid = m.sid --不存在鎖請求，但是鎖定的物件被其他會話請求鎖定
and m.request = 0 and lmode != 4
and (id1, id2) in
(select s.id1, s.id2
from v$lock s
whererequest != 0
and s.id1 = m.id1
and s.id2 = m.id2))
order by id1, id2, m.request;
這裡就顯示了鎖的資訊。 乙個dml 操作需要持有2個鎖。 乙個3級的tm 鎖和乙個6級的tx鎖。 tm 是共享鎖，tx 是行級exclusive 鎖。
檢視v$lock, 可以驗證以上鎖的資訊：
select * from v$lock where sid in (137,140);
request 是申請鎖資源
block：如果是1，就代表該該sid就持有了乙個鎖，並且阻塞別人獲得這個鎖。
2個功能類似的查詢sql:
/* formatted on2011/8/11 14:18:13 (qp5 v5.163.1008.3004) */
select p.spid,
a.sid,
a.serial#,
a.state,
c.object_name,
b.locked_mode,
b.session_id,
b.oracle_username,
b.os_user_name
from v$process p,
v$session a,
v$locked_object b,
all_objects c
where p.addr = a.paddr
and a.process = b.process
and c.object_id = b.object_id;
select/*+ rule */
s .username,
decode (l.type, 'tm', 'table lock', 'tx', 'row lock', null)
lock_level,
o.owner,
o.object_name,
o.object_type,
s.sid,
s.serial#,
s.terminal,
s.machine,
s.program,
s.osuser
from v$session s, v$lock l, dba_objects o
where l.sid = s.sid and l.id1 = o.object_id(+) and s.username is not null
在session a 提交：
sql> commit;
commit complete.
session b 完成：
sql> update t1 set object_id=100 whereobject_id=20;
0 rows updated.
阻塞已經結束。 如果找不到對應的session 來進行commit 操作，那就只能kill session了。
因為我這是測試庫，所以也是用kill session來進行的。
sql>altersystem kill session'sid,serial#';
此篇blog 沒有什麼新東西，裡面的內容，以前也整理過了，隨便看看，算個筆記吧。
blog：
weibo:
email: ***[email protected]
dba1 群：62697716(滿); dba2 群：62697977(滿)dba3 群：62697850(滿)
dba 超級群：63306533(滿); dba4 群： 83829929(滿)dba5群： 142216823(滿)
dba6 群：158654907(滿) 聊天 群：40132017(滿) 聊天2群：69087192(滿)
--**需要在備註說明oracle表空間和資料檔案的關係，否則拒絕申請
Oracle 一次 鎖表 處理小記
同事說測試庫上的一張表被鎖了。不能執行dml 操作。鎖表的準確說法應該是阻塞。之前的一遍blog裡有說明 鎖 死鎖 阻塞latch 等待 詳解 找多鎖表的session，並kill 掉之後，對該錶的dml 操作正常。這裡在模擬一次這個問題。開2個session session a sql selec...
Oracle鎖表小小記
今天在plsql中測試乙個update語句，誰知成功比我想象的來得更早一些，所以我一激動直接切回了開發平台，既沒有提交事務也沒有回滾事務。等我完成了這個小小的需求變更開始測試時，發現端點停在了dao.update上，我才意識到鎖表了。再切回plsql時，回滾和提交按鈕都亮著，然而資料庫連線已經意外中...
記一次鎖表的處理（定位鎖的原因及處理）
在oracle中，常常會碰到鎖阻塞的問題，這時候 我們就需要 利用oralce的給的相關檢視查出並定位鎖的原因 然後根據業務或者其他的實際情況進行業務上的調整或者 或引數的修改等 1 首先查出阻塞的關係。哪個會話阻塞了哪個會話 select a.sid holdsid,b.sid waitsid,a...