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層任何數據, 但會在下一層的網絡協議中產生數據流量。
如果客戶端的聯接仍然是活動的, 探測包被丟棄,計時裝置復位。 如果客戶端異常斷掉，服務器將收到由發送探測包的調用發出的錯誤。

參考:

http://orcl-experts.info/troubleshooting.htm

http://forums.oracle.com/forums/thread.jspa?threadID=594409

http://developers.sun.com.cn/blog/yutoujava/entry/7

http://flyfan05.blog.163.com/blog/static/209939020077875727374/

http://oracle.**.com/exploiture/398192.html