有关ORA-03135报错分析解决

本文探讨了ORA-03135错误的原因及解决方案,指出此错误通常由网络配置不当引起,并详细解释了如何通过调整防火墙设置来解决这一问题。此外,还介绍了长连接和短连接的概念及其在实际应用中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

近期发现生产环境一业务应用系统,不定时发生数据库连接断开,再次请求后正常连接问题。
系统日志中具体错误信息如下: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)是二者共存。

<think>我们正在处理关于Oracle数据库ORA-01555错误的问题。根据提供的引用,我们可以总结出以下关键点: 1. ORA-01555错误是“快照过旧”错误,通常发生在查询需要一致性读时,所需的回滚段信息已经被覆盖。 2. 错误原因包括: - 查询执行时间过长 - UNDO表空间过小 - 事务量过大或提交过于频繁 - 使用SQL*Loader直接加载数据时(因为不产生Redo和Undo,使用CACHED COMMIT SCN) 3. 解决方法: - 增加UNDO表空间大小 - 增加`undo_retention`参数(在自动撤销管理模式下) - 优化SQL语句以减少执行时间 - 避免频繁提交事务(合并小事务) - 清理回滚段信息(但注意在自动撤销管理下,通常由Oracle管理) - 检查数据库配置(如UNDO表空间大小、回滚段存储方式) 此外,引用[5]提到在Sqoop抽取Oracle数据时遇到此错误,也属于上述原因。 现在,我们将按照用户要求,逐步分析解决ORA-01555错误。 ### 步骤1: 确认错误发生的原因 首先,需要确认错误发生的场景。例如: - 错误是在执行什么操作时发生的?(长时间查询?数据导入?) - 发生的频率如何?(偶尔发生还是经常发生?) ### 步骤2: 检查UNDO表空间配置 在自动撤销管理(AUM)模式下,需要检查: 1. UNDO表空间大小:是否足够? 2. `undo_retention`参数设置:默认900秒(15分钟),如果查询需要更长的读一致性时间,则需要增加此值。 查询当前UNDO表空间使用情况和配置: ```sql -- 查看UNDO表空间大小 SELECT tablespace_name, file_name, bytes/1024/1024 AS size_mb FROM dba_data_files WHERE tablespace_name LIKE '%UNDO%'; -- 查看UNDO表空间使用情况 SELECT tablespace_name, status, SUM(bytes)/1024/1024 AS size_mb FROM dba_undo_extents GROUP BY tablespace_name, status; -- 查看undo_retention参数 SHOW PARAMETER undo_retention; ``` ### 步骤3: 优化查询 如果错误由长时间查询引起,考虑: - 优化查询语句(添加索引、重写查询) - 减少查询需要的一致性读时间(例如,在业务低峰期运行) ### 步骤4: 调整事务提交频率 如果因为频繁提交导致UNDO信息被快速覆盖,考虑合并事务(但注意不要使单个事务过大,以免产生其他问题)。 ### 步骤5: 增加UNDO表空间或调整undo_retention 如果UNDO表空间不足,增加其大小: ```sql ALTER DATABASE DATAFILE '/path/to/undo_datafile' RESIZE <new_size>M; ``` 或者添加新的数据文件: ```sql ALTER TABLESPACE undo_tbs ADD DATAFILE '/path/to/new_undo_datafile' SIZE <size>M; ``` 调整`undo_retention`(单位:秒): ```sql ALTER SYSTEM SET undo_retention = <new_value_in_seconds> SCOPE=BOTH; ``` 注意:在Oracle 10g及以上版本中,如果启用了自动扩展,Oracle可能会根据`undo_retention`自动调整UNDO表空间大小。但如果没有自动扩展,则可能需要手动调整。 ### 步骤6: 处理特殊情况 如果错误发生在使用SQL*Loader直接加载数据时,可以考虑: - 避免使用直接加载方式(设置`direct=false`),但这会降低加载速度。 - 或者,在加载后立即执行分析操作,使数据块尽快进入一致状态。 ### 步骤7: 监控和预防 设置监控,定期检查UNDO表空间的使用情况以及长查询情况,预防错误再次发生。 ### 总结 ORA-01555错误的解决需要根据具体原因采取相应措施。通常,调整UNDO表空间大小和`undo_retention`参数是最直接的方法,同时优化相关SQL语句和事务处理逻辑也是关键。 §§相关问题§§ 1. 如何监控Oracle UNDO表空间的使用情况? 2. 在自动撤销管理模式下,如何调整UNDO表空间的大小? 3. 如何优化长时间运行的查询以避免ORA-01555错误? 4. 使用SQL*Loader直接加载数据时,如何避免ORA-01555错误?</think>### ORA-01555错误分析解决方案 #### **错误本质** ORA-01555是Oracle的"快照过旧"错误,发生在查询需要一致性读时,所需的回滚段数据已被覆盖[^1][^3]。核心矛盾是:**查询执行时间 > 回滚段数据保留时间**。 #### **根本原因分析** 1. **UNDO空间不足** - UNDO表空间过小,无法存储足够的历史数据 - 高并发事务导致UNDO信息快速覆盖 - 检查:`SELECT TABLESPACE_NAME, STATUS, SUM(BYTES)/1024/1024 "SIZE_MB" FROM DBA_UNDO_EXTENTS GROUP BY TABLESPACE_NAME, STATUS;` 2. **undo_retention设置不当** - 默认900秒(15分钟),长查询超过此时间会触发错误 - 检查:`SHOW PARAMETER undo_retention` 3. **SQL执行效率低下** - 全表扫描、缺失索引导致查询超时 - 检查:`SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(sql_id => 'xxx'));` 4. **特殊操作影响** - SQL*Loader直接加载(`direct=true`)不生成Redo/Undo[^2] - 频繁提交事务产生大量瞬时UNDO数据[^4][^5] #### **解决方案** 1. **调整UNDO配置** ```sql -- 增加undo_retention(单位:秒) ALTER SYSTEM SET undo_retention = 1800; -- 扩展UNDO表空间 ALTER DATABASE DATAFILE '/u01/oradata/undotbs01.dbf' RESIZE 10G; ``` 2. **优化SQL语句** - 添加缺失索引:`CREATE INDEX idx_col ON table_name(column);` - 避免全表扫描:使用分区表、物化视图 - 减少结果集:添加`WHERE`条件过滤 3. **事务模式调整** - 合并小事务:减少`COMMIT`频率 - 避免高峰时段运行长查询 - SQL*Loader改用常规模式(`direct=false`)[^2] 4. **紧急处理** ```sql -- 强制释放UNDO空间(谨慎使用) ALTER SYSTEM CHECKPOINT; -- 清理过期会话 SELECT SID, SERIAL# FROM V$SESSION WHERE STATUS='INACTIVE'; ALTER SYSTEM KILL SESSION 'sid,serial#'; ``` #### **预防措施** - **监控脚本**: ```sql SELECT TO_CHAR(BEGIN_TIME, 'HH24:MI') TIME, UNDOBLKS, TXNCOUNT, MAXQUERYLEN FROM V$UNDOSTAT WHERE MAXQUERYLEN > 500; -- 查询超过500秒报警 ``` - **参数调整**: - 设置`_undo_autotune=TRUE`(Oracle 10g+自动优化UNDO) - 启用RETENTION GUARANTEE:`ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;` > **关键原则**:该错误本质是资源与需求的矛盾[^4]。优先优化SQL效率,其次调整UNDO配置,最后考虑硬件扩容。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值