ORA-03135: connection lost contact的解决方法

现象:

自从搭建了remote standby之后,每天都会收到primary的alert.log的报警邮件 ,内容是ORA-03135: connection lost contact.查看了错误发生的时间,在夜间两点.其余时间没有这个错误信息.以下分别是主库和从库的信息:

主库alert.log:

Tue Dec 11 02:01:10 2007
ARC1: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (3135)
ARC1: Destination LOG_ARCHIVE_DEST_3 network reconnect abandoned
Tue Dec 11 02:01:10 2007
Errors in file /u01/app/oracle/admin/prod/bdump/prod1_arc1_10383.trc:
ORA-03135: connection lost contact
FAL[server, ARC1]: Error 3135 creating remote archivelog file 'standby'
FAL[server, ARC1]: FAL archive failed, see trace file.
Tue Dec 11 02:01:11 2007
Errors in file /u01/app/oracle/admin/prod/bdump/prod1_arc1_10383.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Tue Dec 11 02:01:11 2007
ORACLE Instance prod1 - Archival Error. Archiver continuing.
Tue Dec 11 02:01:16 2007

主库trace file信息:

*** 2007-12-11 02:01:10.994
Error 3135 creating standby archive log file at host 'standby'
*** 2007-12-11 02:01:10.994 60639 kcrr.c
ARC1: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (3135)
*** 2007-12-11 02:01:10.994 60639 kcrr.c
ARC1: Destination LOG_ARCHIVE_DEST_3 network reconnect abandoned
ORA-03135: connection lost contact
*** 2007-12-11 02:01:10.997 58901 kcrr.c
kcrrfail: dest:3 err:3135 force:0 blast:1
Error 1041 detaching RFS from standby instance at host 'standby'
kcrrwkx: unknown error:3135

从库alert.log:

Tue Dec 11 02:00:56 2007
RFS[19]: Possible network disconnect with primary database
Tue Dec 11 02:00:57 2007
RFS[17]: Possible network disconnect with primary database
Tue Dec 11 02:01:01 2007
Fetching gap sequence in thread 2, gap sequence 178-178
Tue Dec 11 02:01:07 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[21]: Assigned to RFS process 31706

分析:

primary在两点开始执行RMAN备份.从alert.log里看,当时有日志切换发生.由于报丢失连接的standby是在异地,本地standby并没有这个错误,所以猜想可能的原因是当时系统繁忙,造成primary与standby之间的网络通信不畅,继而丢失连接.

解决:

由于该错误只在夜间主库做备份的时候发生,加上带宽因素,起先没有考虑处理问题.但在查看了日志里收藏的其他两篇文章后,发现该问题即使对异地standby也是有可能解决的.文中提到在standby的sqlnet.ora文件中设置SQLNET.EXPIRE_TIME参数,用来保持primary与standby的连接.按照这个提示,在异地standby上设置SQLNET.EXPIRE_TIME=10.重新启动listner.经过几天的的观察,错误没有再发生.

SQLNET.EXPIRE_TIME:

参数出处:
$ORACLE_HOME/network/admin/sqlnet.ora -> expire_time
时间单位:
分钟
取值范围:
大于0
默认取值:
无
用途解释:
死联接检测DCD(Dead Connection Detection)是 SQL*NetV2.1 和此版本以后的一个新特性, 当它检测到对方 c/s 或者s/s 联接意外终止时, 释放相关占用的资源。
DCD 起初是专为客户机没有从会话中断开联接的情况下断电的环境设计的。
DCD由服务端开始建立联接。 这时候SQL*Net 从参数文件中读取变量, 设置一个定时器定时产生信号。 这个时间间隔是sqlnet.ora文件中的SQLNET.EXPIRE_TIME提供的。
当定时器设定的时间到了之后, 服务器上的SQL*Net 发送一个探测包到客户端。(如果是数据库联接, 目的端的服务器发送探测包到另一端)。 探测包是由空的SQL*Net包组成, 不体现SQL*Net层任何数据, 但会在下一层的网络协议中产生数据流量。
如果客户端的联接仍然是活动的, 探测包被丢弃,计时装置复位。 如果客户端异常断掉，服务器将收到由发送探测包的调用发出的错误。