如何進行ORA-03135報錯分析解決

這期內容當中小編將會給大家帶來有關如何進行ORA-03135報錯分析解決，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

近期發現生產環境一業務應用系統，不定時發生數據庫連接斷開，再次請求后正常連接問題。
系統日志中具體錯誤信息如下：ORA-03135: 連接失去聯系\n進程 ID: 9349\n會話 ID: 2834 序列號: 64475"。
oracle版本：11.2.0.4
日志信息：

錯誤信息：ORA-03135: 連接失去聯系

堆棧信息： at Oracle.ManagedDataAccess.Client.OracleException.HandleError(OracleTraceLevel level, OracleTraceTag tag, Exception ex)

at OracleInternal.TTC.TTCExecuteSql.ReceiveExecuteResponse(Accessor[]& defineAccessors, Accessor[] bindAccessors, Boolean bHasReturningParams, SQLMetaData& sqlMetaData, SqlStatementType statementType, Int64 noOfRowsFetchedLastTime, Int32 noOfRowsToFetch, Int32& noOfRowsFetched, Int64& queryId, Int32 longFetchSize, Int64 initialLOBFetchSize, Int64[] scnFromExecution, Boolean& bAllPureInputBinds, DataUnmarshaller& dataUnmarshaller, MarshalBindParameterValueHelper& marshalBindParamsHelper, Int64[]& rowsAffectedByArrayBind, Boolean bDefineDone, Boolean& bMoreThanOneRowAffectedByDmlWithRetClause, List`1& implicitRSList, Boolean bLOBArrayFetchRequired)

at OracleInternal.ServiceObjects.OracleCommandImpl.ExecuteReader(String commandText, OracleParameterCollection paramColl, CommandType commandType, OracleConnectionImpl connectionImpl, OracleDataReaderImpl& rdrImpl, Int32 longFetchSize, Int64 clientInitialLOBFS, OracleDependencyImpl orclDependencyImpl, Int64[] scnForExecution, Int64[]& scnFromExecution, OracleParameterCollection& bindByPositionParamColl, Boolean& bBindParamPresent, Int64& internalInitialLOBFS, OracleException& exceptionForArrayBindDML, Boolean isDescribeOnly, Boolean isFromEF)

at Oracle.ManagedDataAccess.Client.OracleCommand.ExecuteReader(Boolean requery, Boolean fillRequest, CommandBehavior behavior)

at Oracle.ManagedDataAccess.Client.OracleDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)

ORA-03135出現的原因較多，問題有可能出在網絡設備、操作系統、數據庫上，最有可能是由于網絡和防火墻配置所導致。

解決方案：
經與網絡組工程師溝通確認，當前防火前未開啟長連接設置，開啟后此問題解決。

補充一下長連接和短連接的概念：

①長連接的概念

長連接功能用于設置特定數據流的超長保持時間，讓數據流的會話連接保持時間不受全局老化時間限制。其實這項特殊業務與目前業界的狀態防火墻的實現機制是存在矛盾的。

為保證內部網絡的安全，防火墻上的各會話缺省保持時間都相對較短，例如：缺省情況下，TCP的保持時間為1200s，UDP的保持時間為120s。

正常情況下，當一個TCP會話的兩個連續報文到達防火墻的時間間隔大于該會話的保持時間時，為保證網絡的安全性，防火墻將從會話表中刪除相應會話信息。后續報文到達防火墻后，防火墻根據自身的轉發機制，丟棄該報文，導致連接中斷。在實際應用中，用戶需要查詢服務器上的數據，這些查詢時間間隔遠大于TCP/UDP默認的會話保持時間。此時需要在防火墻上保持TCP連接一段相對較長的時間。當某會話的報文長時間沒有到達防火墻后再次到達時，仍然能夠通過防火墻，這種技術就是長連接。

②短連接的概念

某些應用頻繁發起連接，如果不縮短其會話保持時間，則會使防火墻的會話數爆漲，進而拖垮防火墻。保持太多的會話對防火墻沒有必要，相反，當系統資源過多地用在會話保持的話，會相應損害每秒生成會話的能力，這是一個同樣重要的性能指標。設定過高的會話數量，卻降低了每秒生成會話的能力，其結果，只能是保留一些永遠用不到的會話虛數而已。

因此，我們可以根據網絡應用環境的實際需求，縮短某些會話的保持時間，從而減少防火墻的工作負荷，提高網絡性能。

長、短連接參考資料：

https://www.cnblogs.com/lcplcpjava/p/6581179.html

小知識貼士：
oracle 本地登錄的方式登錄oracle服務端：sqlplus "/as sysdba"，不需要用戶名密碼即可登錄。
禁用方法：

1.linux下

轉到目錄$ORACLE_HOME/network/admin下，

cd $ORACLE_HOME/network/admin

vi sqlnet.ora

在文件sqlnet.ora中，增加一行即可：

sqlnet.authentication_services=(none)

如果應用程序時不時地報錯“ORA-03135連接失去聯系”，該問題可能與sqlnet.ora設置參數SQLNET.EXPIRE_TIME 有關

在文件sqlnet.ora中，增加一行，單位分鐘：

SQLNET.EXPIRE_TIME ＝ 10

2.windows下

SQLNET.AUTHENTICATION_SERVICES= (NTS)是基于操作系統驗證；

SQLNET.AUTHENTICATION_SERVICES= (NONE)是基于Oracle驗證；

SQLNET.AUTHENTICATION_SERVICES= (NONE，NTS)是二者共存。

上述就是小編為大家分享的如何進行ORA-03135報錯分析解決了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。