ORA-00054:resource busy and acquire with nowait
1. 先檢視哪些表被鎖住了。
select b.owner,
b.object_name,
a.session_id,
a.locked_mode from v$locked_object a,
dba_objects b where b.object_id = a.object_id;
2. 獲取sid,serial
select b.username, b.sid, b.serial#, logon_time
from v$locked_object a, v$session b
where a.session_id = b.sid
order by b.logon_time;
3. 殺死鎖程式
alter system kill session 'sid, serial';
如果有ora-00031錯誤,則在後面加immediate;
很多情況下沒法直接殺死session, 需要到資料庫伺服器殺伺服器程式。
透過下面sql查伺服器程式
SELECT a.username, c.spid AS os_process_id, c.pid AS oracle_process_id
FROM v$session a, v$process c
WHERE c.addr = a.paddr
and a.sid ='250'
and a.serial# ='14558';
到這裡鎖應該就被清除了。
——————————————————————————————————————————————————————————————————
查詢鎖定的session
SELECT sn.username,m.SID,sn.SERIAL#, m.TYPE,
DECODE (m.lmode,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
6, 'Exclusive',
lmode, LTRIM (TO_CHAR (lmode, '990'))
) lmode,
DECODE (m.request,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
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
WHERE request != 0 AND s.id1 = m.id1
AND s.id2 = m.id2)
)
ORDER BY id1, id2, m.request;
透過資料字典v$session 與v$lock 來了解正在等待鎖資源的使用者
select a.username,a.sid,a.serial#,b.id1 from v$session a ,v$lock b
where a.lockwait = b.kaddr;
瞭解鎖住其他使用者的使用者程式:
select a.username,a.sid,a.serial#,b.id1 from v$session a,v$lock b
where b.id1 in
(select distinct e.id1 from v$session d,v$lock e where d.lockwait =e.kaddr)
And a.sid = b.sid and b.request =0;
select b.owner,
b.object_name,
a.session_id,
a.locked_mode from v$locked_object a,
dba_objects b where b.object_id = a.object_id;
2. 獲取sid,serial
select b.username, b.sid, b.serial#, logon_time
from v$locked_object a, v$session b
where a.session_id = b.sid
order by b.logon_time;
3. 殺死鎖程式
alter system kill session 'sid, serial';
如果有ora-00031錯誤,則在後面加immediate;
很多情況下沒法直接殺死session, 需要到資料庫伺服器殺伺服器程式。
透過下面sql查伺服器程式
SELECT a.username, c.spid AS os_process_id, c.pid AS oracle_process_id
FROM v$session a, v$process c
WHERE c.addr = a.paddr
and a.sid ='250'
and a.serial# ='14558';
到這裡鎖應該就被清除了。
——————————————————————————————————————————————————————————————————
查詢鎖定的session
SELECT sn.username,m.SID,sn.SERIAL#, m.TYPE,
DECODE (m.lmode,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
6, 'Exclusive',
lmode, LTRIM (TO_CHAR (lmode, '990'))
) lmode,
DECODE (m.request,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
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
WHERE request != 0 AND s.id1 = m.id1
AND s.id2 = m.id2)
)
ORDER BY id1, id2, m.request;
透過資料字典v$session 與v$lock 來了解正在等待鎖資源的使用者
select a.username,a.sid,a.serial#,b.id1 from v$session a ,v$lock b
where a.lockwait = b.kaddr;
瞭解鎖住其他使用者的使用者程式:
select a.username,a.sid,a.serial#,b.id1 from v$session a,v$lock b
where b.id1 in
(select distinct e.id1 from v$session d,v$lock e where d.lockwait =e.kaddr)
And a.sid = b.sid and b.request =0;
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/21374452/viewspace-2131599/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- ORA-00054: resource busy and acquire with NOWAITUIAI
- ORA-00054: resource busy and acquire with NOWAIT specifiedUIAI
- ora-00054:resource busy and acquire with nowait specifiedUIAI
- ORA-00054: resource busy and acquire with NOWAIT specified處理UIAI
- ora-00054:resource busy and acquire with nowait specified解決方法UIAI
- "ORA-00054 resource busy and acquire with NOWAIT specified"的解決方法UIAI
- oracle之 RA-00054: resource busy and acquire with NOWAITOracleUIAI
- ORA-00054,ORA-00031 resource busy and acquire with NOWAIT 資源佔用處理過程UIAI
- Oracle wait interface - ORA-00054: resource busyOracleAI
- gc buffer busy acquire問題處理GCUI
- open failed: EBUSY (Device or resource busy)AIdev
- ORA-00054: 資源正忙,要求指定 NOWAITAI
- Oracle ASM oracleasm createdisk "Device or resource busy"OracleASMdev
- 如何解決ORA-00054資源正忙,要求指定NOWAITAI
- oracle之報錯:ORA-00054: 資源正忙,要求指定 NOWAITOracleAI
- device-mapper create ioctl failed: Device or resource busydevAPPAI
- FILE ON OCFS CANNOT BE DELETED LINUX ERROR: 16: DEVICE OR RESOURCE BUSYdeleteLinuxErrordev
- oracle錯誤處理之ORA-00054:資源正忙,要求指定NOWAITOracleAI
- 分析解決11gR2 雙節點RAC環境下的gc cr block busy/gc buffer busy acquire等待GCBloCUI
- Linux rm -rf 之rm: cannot remove `linux': Device or resource busyLinuxREMdev
- ora-00054: 資源正忙, 但指定以 nowait 方式獲取資源如何解決AI
- ORA-00054: 資源正忙, 但指定以 NOWAIT 方式獲取資源, 或者超時失效AI
- gc buffer busyGC
- select for update nowaitAI
- for update和for update nowaitAI
- FOR UPDATE NOWAIT和 FOR UPDATEAI
- PMON failed to acquire latch, see PMON dumpAIUI
- Oracle Buffer Busy WaitsOracleAI
- buffer busy wait 解析AI
- oracle ora-00054錯誤處理Oracle
- Laravel Resource Routes和API Resource Routes講解LaravelAPI
- Bug 4632780 - PMON "failed to acquire latch" during shutdownAIUI
- PMON "failed to acquire latch" during shutdown-4632780.8AIUI
- PMON failed to acquire latch, see PMON dump in alert logAIUI
- mysql innodb之select for update nowaitMySqlAI
- Oracle中的for update 和 for update nowaitOracleAI
- 【Oracle】ORA-00054 錯誤解決方法Oracle
- ORA-00054 故障處理一例