在某些項目中有時後會出現以下的情況,由於代碼寫錯,在執行Oracle sql之後,我們沒有關閉數據庫的相關連接。如果該代碼重復執行Oracle sql時,會導致應用服務器和數據庫的連接不斷增加,最終導致連接超過數據庫連接上限,系統崩潰。
問題:
項目中的代碼很多,很難准確定位到底是哪一段代碼出了問題
解決辦法:
用應用程序的用戶登錄Oracle,執行下面的sql:
- select sql_text from v$sqlarea a where a.
HASH_VALUE in (- select b.prev_hash_value from v$session b where b.
MacHINE = 'WLS254'- )
sql中的"WLS254"指的是應用服務器的名稱,該sql得到的結果就是WLS254這台機器連接到Oracle的正在執行的Oraclesql。通過分析這些sql,就可以快速的發現是哪部分程序沒有釋放連接。
v$session視圖的字段說明:
SADDR RAW(4) 會話地址,SID NUMBER 會話標識符
SERIAL# NUMBER 會話序列號。用來唯一地標識繪畫對象。如果該會話結束且其他會話以相同的會話ID 開始,則保證會話級的命令被應用到正確會話對象
AUDSID NUMBER 審計會話ID。PADDR RAW(4) 擁有這個會話的進程地址,USER# NUMBER Oracle 用戶標識符,USERNAME VARCHAR(30) Oracle 用戶名,COMMAND NUMBER 正進行的命令。關於值的列表,請參閱表B-
11OWNERID NUMBER 如果值為2147483644,則此列的內容無效。否則此列包含擁有可移植會話的用戶標符。對於利用並行從服務器的操作,將這個值解釋為一個48 字節的值。其低位兩字節表示會話號,而高位字節表示查詢協調程序的實例ID
TADDR VARCHAR2(8) 事務處理狀態對象的地址
LOCKWAIT VARCHAR2(8) 等待鎖的地址;如果沒有,為NULL
STATUS VARCHAR2(8) 會話的狀態:ACTIVE (當前執行的
sql)、INACTIVE、KILLED(標記為
終止)、CACHED(為Oracle*XA 使
用而臨時高速緩存)、SNIPED(會
話不活動,在客戶機上等待)
SERVER VARCHAR2(9) 服務器類型:
DEDICATED、SHARED、
PSEUDO、NONE
SCHEMA# NUMBER 模式用戶標識符
SCHEMANANME VARCHAR2(30) 模式用戶名,OSUSER VARCHAR(15) 操作系統客戶機用戶名,PROCESS VARCHAR2(9) 操作系統客戶機進程ID,MacHINE VARCHAR2(64) 操作系統機器名,TERMINAL VARCHAR2(10) 操作系統終端名,PROGRAM VARCHAR(48) 操作系統程序名,TYPE VARCHAR2(10) 會話類型。sql_ADDRESS RAW(4) 與sql_HASH_VALUE 一道使用標識
當前正在執行的Oraclesql 語句
sql_HASH_VALUE NUMBER 與sql_ADDRESS 一道使用標識當前
正在執行的sql 語句
MODULE VARCHAR2(48) 包含當前正在執行的模塊名,正如
由調用
DBMS_APPLICATION_INFO.SET_MODU
LE 過程所設置
MODULE_HASH NUMBER 上面MODULE 的散列值
ACTION VARCHAR2(32) 包含當前執行活動的名稱,正如由
調用
DBMS_APPLICATION_INFO.SET_ACTI
ON 過程所設置
ACTION_HASH NUMBER 上列活動名稱的散列值
CLIENT_INFO VARCHAR2(64) 由
DBMS_APPLICATION_INFO.SET_CLIE
NT_INFO 過程設置的信息
FIXED_TABLE_
SEQUENCE
NUMBER 此列包含一個數,每當會話完成一
個數據庫調用並且存在來自動態性能表的介入選擇,它個數就增加。這個列可被性能監控程序用來監控數據庫中的統計數據。每當性能監控程序查看數據庫時,只需要查看當前活動的會話或在這個列中具有比上次性能監控程序所看到的最大值更大的值的會話即可。所有其他會話自上次性能監控程序查看數據庫以來都是空閒的。