SELECT OBJECT_ID,SESSION_ID,SERIAL#, ORACLE_USENAME,OS_USER_NAME,S_PROCESS FROM V$LOCKED_OBJECT 1, V$SESSION S WHERE 1.SESSION_ID=S.SID; 也許有的人會問為什么不用如下的SQL語句進行查詢：
SELECT a.username,a.sid,a.serial#,b.id1, c.sql_text from v$session a, V$lock b,v$sqltext c where a.lockwait=b.kaddr and a. sql_address=c.address and a.sql_hash_value=c.hash_value; 以上兩個SQL語句都會查詢返回當前被鎖住的用戶列表，但第二個SQL語句由于加入了sql_text從而使這個查詢變得非常的慢長，特別是在有許多用戶同時對數據庫進行操作時，建議不用，第一個SQL 語句會在很短的時間內查詢出是誰在鎖表，從而有利于對數據庫的管理，一但有用戶進入不了，我們就馬上殺死其鎖進程[SID，SERIAL#]，SQL語句如下：ALTER SYSTEM KILL SESSION ‘SID，SERIAL#’，但這并不是解決問題的根本方法，只能暫時緩解一下；另外我們還發現回滾段時常有“online”與“offline”的現象，于是我們又考慮是否是回滾段引起的問題：因為我們一但對大的回滾段進行操作，馬上就會有用戶反映無法進入。我們知道回退段的大小直接依賴于數據庫的活動狀態，而每一個EXTENTS都應具有相同的值（Oracle的推薦）[INITIAL EXTENTS的值可以從2K（32）、4K（69）、8K（142）、16K、32K等列表中選擇]，這將保證你刪掉一個區的時候，你可以重新使用它的空間而不會造成浪費，另外MINEXTENTS應設為20，這將不會使回退段擴展另一個EXTENT時用到正在被活動的事務所使用的空間，因而我們就可以據此來確定回退段大小，查出數據庫正常運行時所需回滾段的尺寸,為此我們重新設置了回退段的OPTIMAL參數[事實是OPTIMAL的值并不足引起數據庫出錯]，增大了OPTIMAL的值，使用命令SET TRANSACTION USE ROLLBACK SEGMENT為系統指定了一個大的回退段[注意OPTIMAL參數要足夠大以使ORACLE不需經?；乜s和重新分配EXTENTS，如果設得小于最小覆蓋值，性能將由于額外的段重設置而下降，對于一個要執行長查詢的系統，OPTIMAL應設成足夠大以避免ORA-1555，“Smapshot too old”的錯誤，而對于運行小的事務，OPTIMAL應設得小一些，使回退段足夠小以便放于內存中，這將提高系統性能。]，但我們發現這樣做后，ORA-600的錯誤依然出現，而且鎖表越來越嚴重；我們又考慮暫時鎖住這個表，不讓用戶進入，先把用戶的鎖進程全部殺完再看，由于一開始就采用了主機-終端的工作方式，因而根本就無法清除得完，除非斷掉外部的所有網絡連接，但那樣無疑是重啟數據庫，最終我們選擇了重啟數據庫。
