有此錯誤許多不同的原因:
連接池
檢查一下配置,如果你的連接池有一個像超時或一生參數。使用此參數我自己遇到了問題,在池會話不活動一分鐘後導致錯誤ORA-03135。在我的情況下,解決方案是使用非集中連接,但這對大多數應用程序來說不可行。在你的情況下,設置更高的超時時間可能會訣竅。
嘗試激活在DJango和/或中間件上的最高級別的調試,以查看它是否記錄有關會話在池中過期的消息。重新啓動中間件並花費多長時間才能啓動失敗。如果時間很短(例如60秒),則可能需要更改超時時間並確保該池具有足夠的會話供您加載。
網絡錯誤/防火牆
各種網絡問題,如丟棄的數據包或網卡的問題,可能導致連接斷開。
爲了調試這個,使用Sqlplus連接到數據庫並運行任何給定的命令。之後,將會話保持非活動狀態10,20,30,60和120分鐘(一次嘗試一次)。這會讓您知道問題是否只發生在連接池或SQLPLUS中。如果後者是真的,那麼它可能是網絡問題或配置(例如防火牆超時),由於不活動而導致會話中斷。如果會話在相同的時間間隔後(例如兩個小時後)總是死掉,情況尤其如此。在其他機器上嘗試相同的實驗以查看超時是否仍然發生。如果它只發生在某些主機上,則可能是主機連接到的交換機存在問題。您的網絡工程師可能需要參與。
在這種情況下,OS Keepalive配置可能會有所幫助。以下是Windows的鏈接。 http://blogs.technet.com/b/nettracer/archive/2010/06/03/things-that-you-may-want-to-know-about-tcp-keepalives.aspx
調試此類錯誤的另一種方法是啓用客戶端和/或服務器上的TNS跟蹤。這通過在客戶端和服務器sqlnet.ora文件中分別配置參數TRACE_LEVEL_CLIENT和TRACE_LEVEL_SERVER來完成。還有其他參數需要這樣做。檢查有關該主題的Oracle文檔。
Oracle服務器側斷開
數據庫可能會斷開,因爲與它的問題的會議上,甲骨文的錯誤或當會話被管理員殺死。診斷此類問題的最佳方法是查看數據庫alert.log,將發生錯誤的時間與日誌內容進行匹配。如果會話在服務器上終止,則會有一個條目指出會話已終止,並且包含有關斷開連接的其他信息的跟蹤文件的路徑。如果這是造成它的Oracle錯誤,則必須通過Oracle Support搜索適當的修復程序。
此外,用戶可能會關聯到配置了CONNECTION_TIME或IDLE_TIME的Oracle配置文件。爲了調試,如果這是問題的原因,請將用戶與Oracle配置文件關聯,而不受此限制。
來源
2014-11-07 05:52:29
Gui
您是否看到以下主題:https://community.oracle.com/thread/2230671?tstart = 0?如果原因沒有超時,你有沒有看到關閉會話的SQL查詢的歷史?當「錯誤的」SQL查詢導致會話中止(不同的oracle版本中的不同SQL)時,oracle中存在一些錯誤。例如:從雙重聯合中選擇1 通過dbms_random.value從雙重順序中選擇1。 – Dmitry 2014-11-05 20:54:40
我假設SID,Serial和Process在每次錯誤回來時都會更改。在重新啓動中間件後開始出現該問題需要多長時間? – Gui 2014-11-06 03:39:28