Shulou(Shulou.com)06/02 Report--

Phenomenon:

Since the establishment of remote standby, I have received an alarm email from primary's alert.log every day, which reads ORA-03135: connection lost contact. Check the time when the error occurred at two o'clock at night. There is no such error message the rest of the time. The following is the information for the master library and the slave library:

Main library 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 information of the main library:

* 2007-12-11 02 purl 01purl 10.994

Error 3135 creating standby archive log file at host 'standby'

* 2007-12-11 02Disc 01purl 10.994 60639 kcrr.c

ARC1: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (3135)

* 2007-12-11 02Disc 01purl 10.994 60639 kcrr.c

ARC1: Destination LOG_ARCHIVE_DEST_3 network reconnect abandoned

ORA-03135: connection lost contact

* * 2007-12-11 02Disc 01purl 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

From the library 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 178178

Tue Dec 11 02:01:07 2007

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS [21]: Assigned to RFS process 31706

Analysis:

Primary starts performing RMAN backups at two o'clock. From the alert.log, there was a log switch at that time. Since the standby reporting the lost connection is in a different place, the local standby does not have this error, so it is speculated that the possible reason is that the system was busy at that time, resulting in poor network communication between primary and standby, and then lost the connection.

Resolve:

Because the error only occurs when the main database is backed up at night, and the bandwidth factor is added, the processing problem is not considered at first. But after looking at the other two articles collected in the log, I found that the problem could be solved even for remote standby. In this paper, it is mentioned that the SQLNET.EXPIRE_TIME parameter is set in the sqlnet.ora file of standby to maintain the connection between primary and standby. Follow this prompt to set SQLNET.EXPIRE_TIME=10. Exe on the remote standby. Restart listner. After several days of observation, the mistake did not happen again.

SQLNET.EXPIRE_TIME:

Source of parameters:

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

Unit of time:

Minute

Value range:

Greater than 0

Default value:

None

Use explanation:

Dead join detection DCD (Dead Connection Detection) is a new feature of SQL*NetV2.1 and later, which frees up related resources when it detects the unexpected termination of the other party's cUnix s or sbank s connection.

DCD was originally designed for environments where the client is powered off without being disconnected from the session.

The DCD starts to establish the connection from the server. At this time, SQL*Net reads the variables from the parameter file and sets a timer to generate signals. This interval is provided by SQLNET.EXPIRE_TIME in the sqlnet.ora file.

When the timer setting time is up, the SQL*Net on the server sends a probe packet to the client. (in the case of a database connection, the server on the destination side sends a probe packet to the other end). Probe packets are made up of empty SQL*Net packets that do not reflect any data in the SQL*Net layer, but generate data traffic in the next layer of the network protocol.

If the connection of the client is still active, the probe packet is discarded and the timing device is reset. If the client breaks abnormally, the server will receive an error from the call that sent the probe packet.

Reference:

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

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.