今天在修改bug的過程中，一條更新資料的sql執行怎麼也執行不了，進入貌似“排隊”的情況，一直處於等待的狀態，第一直覺是事務鎖起到壞作用，後在專案組高手的協助下找到了原因，是資料被鎖住了。一般查詢是否被鎖住可以做如下操作：

以系統資料庫管理員的身份登入

--無連線啟動sqlplus
sqlplus /nolog;

--以sysdba的身份連線資料庫
conn /as sysdba;

檢視被鎖的資料物件

--查詢被鎖的資料物件
select t2.username, t2.sid, t2.serial#, t2.logon_time
  from v$locked_object t1, v$session
 
 t2
 where t1.session_id = t2.sid
 order by t2.logon_time;

執行上述語句後，得到如下的結果：

表明的確是有使用者的資料物件（因為當前資料庫例項中只有圖中的使用者處於活動狀態）處於鎖定狀態，然後需要把該使用者的程序kill掉即可。

停止被鎖事務資料物件的程序

--同一個sid可能會被不同的session使用，所以通過sid和serial number可以唯一定位；
--下面的sid，和serial#替換成上圖中對應的值即可
alter system kill session  'sid,serial#';

其實，上面的截圖只是一部分，總共有27個被鎖的資料物件，如果一行一行進行kill，豈不累死寶寶啊，因此我使用儲存過程來實現了：

declare
    cursor kill_lockedobj_crs is(
        select t2.sid,t2.serial# serial from v$locked_object
        t1,v$session t2 where t1.session_id=t2.sid
    );
    v_sql varchar2(500);
    v_session varchar2(30);
begin
    for cont in kill_lockedobj_crs loop
        exit when kill_lockedobj_crs%notfound;
 

        v_obj := cont.sid ||','||cont.serial;
        v_sql := 'alter system kill session' || v_obj;
        execute immediate v_sql;
    end loop;
end;
/
commit;

望我的解決方法對大家有所幫助。如有錯誤，歡迎指正！