[轉(zhuǎn)帖]ORA-03135: connection lost contact的解決方法

emailwht

http://space.itpub.net/81912/viewspace-584

現(xiàn)象:

自從搭建了remote standby之后,每天都會收到primary的alert.log的報警郵件 ,內(nèi)容是ORA-03135: connection lost contact.查看了錯誤發(fā)生的時間,在夜間兩點.其余時間沒有這個錯誤信息.以下分別是主庫和從庫的信息:

主庫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在兩點開始執(zhí)行RMAN備份.從alert.log里看,當時有日志切換發(fā)生.由于報丟失連接的standby是在異地,本地standby并沒有這個錯誤,所以猜想可能的原因是當時系統(tǒng)繁忙,造成primary與standby之間的網(wǎng)絡(luò)通信不暢,繼而丟失連接.

解決:

由于該錯誤只在夜間主庫做備份的時候發(fā)生,加上帶寬因素,起先沒有考慮處理問題.但在查看了日志里收藏的其他兩篇文章后,發(fā)現(xiàn)該問題即使對異地standby也是有可能解決的.文中提到在standby的sqlnet.ora文件中設(shè)置SQLNET.EXPIRE_TIME參數(shù),用來保持primary與standby的連接.按照這個提示,在異地standby上設(shè)置SQLNET.EXPIRE_TIME=10.重新啟動listner.經(jīng)過幾天的的觀察,錯誤沒有再發(fā)生.

SQLNET.EXPIRE_TIME:

參數(shù)出處:

$ORACLE_HOME/network/admin/sqlnet.ora -> expire_time

時間單位:

分鐘

取值范圍:

大于0

默認取值:

無

用途解釋:

死聯(lián)接檢測DCD(Dead Connection Detection)是 SQL*NetV2.1 和此版本以后的一個新特性, 當它檢測到對方 c/s 或者s/s 聯(lián)接意外終止時, 釋放相關(guān)占用的資源。

DCD 起初是專為客戶機沒有從會話中斷開聯(lián)接的情況下斷電的環(huán)境設(shè)計的。

DCD由服務(wù)端開始建立聯(lián)接。 這時候SQL*Net 從參數(shù)文件中讀取變量, 設(shè)置一個定時器定時產(chǎn)生信號。 這個時間間隔是sqlnet.ora文件中的SQLNET.EXPIRE_TIME提供的。

當定時器設(shè)定的時間到了之后, 服務(wù)器上的SQL*Net 發(fā)送一個探測包到客戶端。(如果是數(shù)據(jù)庫聯(lián)接, 目的端的服務(wù)器發(fā)送探測包到另一端)。 探測包是由空的SQL*Net包組成, 不體現(xiàn)SQL*Net層任何數(shù)據(jù), 但會在下一層的網(wǎng)絡(luò)協(xié)議中產(chǎn)生數(shù)據(jù)流量。

如果客戶端的聯(lián)接仍然是活動的, 探測包被丟棄,計時裝置復(fù)位。 如果客戶端異常斷掉，服務(wù)器將收到由發(fā)送探測包的調(diào)用發(fā)出的錯誤。

參考:

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

http://www.itpub.net/viewthread.php?tid=1216300&extra=&page=1