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://developers.sun.com.cn/blog/yutoujava/entry/7

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