Peter, I think I follow your email, but I don't see the error you refer to nor do I have the exact answer, but rather a suggestion; >> I have a problem that the switchover fails because >> the standby says there is incomplete recovery I would suggest taking the DG/Standby concept out of the equation for a bit. Any database the can be RESTORED & RECOVER (complete) to another server *can* be made a STANDBY DATABASE, agreed? I try would manually RECOVER the new database (old primary)...I believe you have less of a DG/Standby issue and more of a Recovery issue!? Something like this; SQL>RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; ... SQL><RET>/[Enter] ... SQL><RET>/[Enter] ... SQL>CANCEL ... !!!NEVER TO OPEN THE DATABASE NOR OPEN RESETLOGS!!! You should be able to do this over and over again...ftp'ing logs from your (new) primary to old primary where the database is waiting to accept additional recovery. If you can to this you should be fine. You could also and I would try to Recover manually as a STANDBY DATABASE --------------------------------------------------- SQL NOMOUNT STANDBY DATABASE --------------------------------------------------- startup nomount pfile='/.../pfile/init.ora' ALTER DATABASE MOUNT STANDBY DATABASE; --------------------------------------------------- SQL MANUAL RECOVERY STANDBY DATABASE --------------------------------------------------- SQL>RECOVER STANDBY DATABASE; ... SQL><RET>/[Enter] ... SQL><RET>/[Enter] ... SQL>CANCEL ... Again, if you can manually Recover over and over and at any time then you should be able to use this database as a STANDBY DATABASE...if you can not recover manually then you have a Restore and Recovery problem for sure. hth Chris Marquez -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Peter McLarty Sent: Wed 5/18/2005 6:32 AM To: Oracle-l Subject: After Dataguard failover not able to make switchover back Hi all DG gurus I have run some tests of dataguard and in the it all something has happened of which I am a little lost. After a number of configuration errors in the two databases I had the system making switchovers successfully. Then the client insisted that we do a fail over test. the failover went smoothly and all appeared well. No for the fun part I rebuilt the old primary as a standby to the new primary and have now had 4 attempts to successfully switchover none of which have worked. I have a problem that the switchover fails because the standby says there is incomplete recovery and as such cannot continue. I think i may have stuffed this one and may have to export the data and rebuild a new clean primary but if anyone has any ideas as to how to recover I would appreciate it This is some of the alert log and it points to a file 1_0.dbf in the archivelogs directory Whatever this file is supposed to do is killing me when I try and do a switchover as the standby then complains about incomplete recovery and fails to make the switch from standby to primary. ARC0: Completed archiving log 4 thread 1 sequence 47836 Sat May 14 11:36:12 2005 End: All standby logfiles have been archived Resetting standby activation ID 4238571451 (0xfca377bb) MRP0: Background Media Recovery process shutdown Sat May 14 11:36:13 2005 Terminal Incomplete Recovery: completion detected Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FI Sat May 14 11:36:13 2005 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY RESETLOGS after incomplete recovery UNTIL CHANGE 58368209 Resetting resetlogs activation ID 0 (0x0) Changing control file format version from 8.0.0.0.0 to 9.0.0.0.0 RESETLOGS changing datafile format version from 9.0.0.0.0 to 8.0.0.0.0 Switchover: Complete - Database shutdown required Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAI Sat May 14 11:36:14 2005 Shutting down instance: further logons disabled Shutting down instance (immediate) License high water mark = 5 Sat May 14 11:36:14 2005 alter database CLOSE NORMAL ORA-1507 signalled during: alter database CLOSE NORMAL... ARCH: Archiving is disabled Shutting down archive processes Archiving is disabled Sat May 14 11:36:14 2005 ARCH shutting down Sat May 14 11:36:14 2005 ARCH shutting down Sat May 14 11:36:14 2005 ARC0: Archival stopped Sat May 14 11:36:14 2005 ARC1: Archival stopped Sat May 14 11:36:17 2005 ARCH: Archiving is disabled Shutting down archive processes Archiving is disabled Archive process shutdown avoided: 0 active Shutting down Data Guard Broker processes Sat May 14 11:36:19 2005 Completed: Data Guard Broker shutdown Sat May 14 11:36:21 2005 Starting ORACLE instance (normal) Disable cache advisory with old cache parameters LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 SCN scheme 3 Using log_archive_dest parameter default value LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: 9.2.0.5.0. System parameters with non-default values: processes = 50 timed_statistics = FALSE shared_pool_size = 20971520 nls_language = AMERICAN nls_territory = AMERICA nls_comp = ansi control_files = /data3/ellipse/elldrc/standby_1.ctl db_file_name_convert = /data1/ellipse/ellprd/, /data3/ellipse/elldrc/ log_file_name_convert = /data1/ellipse/ellprd/, /data3/ellipse/elldrc db_block_buffers = 1250 db_block_size = 8192 compatible = 9.2.0.5 log_archive_start = TRUE log_archive_dest_1 = LOCATION=/data4/ellipse/elldrc/archivelogs MANDATOR Y log_archive_dest_2 = log_archive_dest_3 = log_archive_dest_4 = log_archive_dest_5 = log_archive_dest_6 = log_archive_dest_7 = log_archive_dest_8 = log_archive_dest_9 = log_archive_dest_10 = log_archive_dest_state_2 = ENABLE log_archive_max_processes= 2 log_archive_min_succeed_dest= 1 standby_archive_dest = /data4/oracle/standby_log log_archive_trace = 0 fal_server = ellprd fal_client = elldrc log_archive_format = %t_%s.dbf log_buffer = 65536 log_checkpoint_interval = 10000 archive_lag_target = 0 db_files = 200 db_file_multiblock_read_count= 8 standby_file_management = AUTO log_checkpoints_to_alert = TRUE dml_locks = 500 rollback_segments = r01, r02, r03, r04 remote_os_authent = TRUE remote_login_passwordfile= EXCLUSIVE instance_name = elldrc background_dump_dest = /var/opt/oracle/elldrc/bdump user_dump_dest = /var/opt/oracle/elldrc/udump max_dump_file_size = 10240 core_dump_dest = /var/opt/oracle/elldrc/cdump db_name = ellprd open_cursors = 1000 os_authent_prefix = OPS$ dg_broker_start = TRUE PMON started with pid=2 DBW0 started with pid=3 LGWR started with pid=4 CKPT started with pid=5 SMON started with pid=6 RECO started with pid=7 Sat May 14 11:36:22 2005 ARCH: STARTING ARCH PROCESSES ARC0 started with pid=8 ARC0: Archival started ARC1 started with pid=9 ARC1: Archival started Sat May 14 11:36:22 2005 ARCH: STARTING ARCH PROCESSES COMPLETE Sat May 14 11:36:22 2005 ARC1: Thread not mounted Sat May 14 11:36:22 2005 ARC0: Thread not mounted DMON started with pid=10 Starting Data Guard Broker (DMON) RSM0 started with pid=12 Sat May 14 11:36:29 2005 ALTER DATABASE MOUNT Sat May 14 11:36:33 2005 Successful mount of redo thread 1, with mount id 4238817981 Sat May 14 11:36:33 2005 Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Sat May 14 11:36:33 2005 ALTER DATABASE OPEN Sat May 14 11:36:33 2005 LGWR: Primary database is in CLUSTER CONSISTENT mode Assigning activation ID 4238817981 (0xfca73abd) Thread 1 opened at log sequence 47837 Current log# 3 seq# 47837 mem# 0: /data3/ellipse/elldrclog3a_ellprd.log Successful open of redo thread 1 Oracle 9.2.0.5 AIX 5.2 Cheers Peter -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l