Right after the last command - "* on primary: alter system switch logfile; " $ cat /SRV_ACE/server/database/bdump/srv_ace_arc0_16980.trc Dump file /SRV_ACE/server/database/bdump/srv_ace_arc0_16980.trc Oracle9i Enterprise Edition Release 184.108.40.206.0 - 64bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 220.127.116.11.0 - Production ORACLE_HOME = /oracle/OraHome1 System name: SunOS Node name: a632dse0 Release: 5.10 Version: Generic_118833-03 Machine: sun4u Instance name: SRV_ACE Redo thread mounted by this instance: 0 <none> Oracle process number: 10 Unix process pid: 16980, image: oracle@a632dse0 (ARC0) *** SESSION ID:(9.1) 2006-09-18 16:41:02.572 Destination LOG_ARCHIVE_DEST_2 is in CLUSTER CONSISTENT mode Destination LOG_ARCHIVE_DEST_2 is in MAXIMUM PERFORMANCE mode Destination LOG_ARCHIVE_DEST_2 is in CLUSTER CONSISTENT mode Destination LOG_ARCHIVE_DEST_2 is in MAXIMUM PERFORMANCE mode Destination LOG_ARCHIVE_DEST_2 is in CLUSTER CONSISTENT mode Destination LOG_ARCHIVE_DEST_2 is in MAXIMUM PERFORMANCE mode RFS network connection lost at host 'SRV_ACE2' Error 3113 creating standby archive log file at host 'SRV_ACE2' *** 2006-09-21 14:50:10.552 ARC0: Error 3113 Creating archive log file to 'SRV_ACE2' *** 2006-09-21 14:50:10.552 kcrrfail: dest:2 err:3113 force:0 ORA-03113: end-of-file on communication channel $ tnsping SRV_ACE2 TNS Ping Utility for Solaris: Version 18.104.22.168.0 - Production on 21-SEP-2006 14:52:41 Copyright (c) 1997 Oracle Corporation. All rights reserved. Used parameter files: /oracle/OraHome1/network/admin/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = adrcap62.am .csplc.org) (PORT = 1527))) (CONNECT_DATA = (SERVICE_NAME = SRV_ACE))) OK (60 msec) $ After a while, everything was back to normal and stays normal. Thanks, [Roger Xu] ----Original Message----- From: Carel-Jan Engel [mailto:cjpengel.dbalert@xxxxxxxxx] Sent: Thursday, September 21, 2006 3:30 PM To: Roger Xu Cc: Jay.Miller@xxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx Subject: RE: 9i physical standby startup Where in the command sequence did you see this message? You don't put timestamps at the 9 commands. Wat's in the file /SRV_ACE/server/database/bdump/srv_ace_arc0_16980.trc? I see the 3113's pretty often in my trace's. The shutdown of the standby kills the RFS proces. The primary therefore can no longer communicate with this proces, responsible for receiving the redo and writing it to disk. ORA-3113 is well resembling that state transition. Maybe I wouldn't defer the destination. Depending on your further settings it will automagically resume once you restart the standby. If you plan to keep the standby shutdown for a longer time deferring makes sense. Best regards, Carel-Jan Engel === If you think education is expensive, try ignorance. (Derek Bok) === On Thu, 2006-09-21 at 15:10 -0500, Roger Xu wrote: Thanks - Now I had another problem: * on primary: alter system set log_archive_dest_state_2=defer scope=both; * on primary: alter system switch logfile; * on standby: alter database recover managed standby database cancel; * on standby: shutdown immediate; * on standby: startup nomount; * on standby: alter database mount standby database; * on standby: alter database recover managed standby database disconnect from session; * on primary: alter system set log_archive_dest_state_2=enable scope=both; * on primary: alter system switch logfile; Immediately, I saw the following in the alert log - I guess this is normal? Thu Sep 21 14:50:10 2006 Errors in file /SRV_ACE/server/database/bdump/srv_ace_arc0_16980.trc: ORA-03113: end-of-file on communication channel BTW, is this the right procedure to shutdown a standby? Thanks, Roger This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, dissemination, copying, printing or other use o ____________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System.