Hi Chris, I think (i'm not completely sure) the resetlogs killed to standby. I think there is a better way of doing the job. When I install a DG-environment I perform a hot backup from the primary to the standby. This can be done whilst the primary is up and running. What I suggest is: Define a second standby, situated at the destination server. Instantiate the thing, using rman/hot backup/scripts/manual, whatever you like. Preferrably through the network, via tape is also possible. After succesfull instatiation and putting the new standby in managed recovery mode (check if the log-switch actually causes recovery activity at the new standby)you perform a smooth switchover from the primary to the new standby database, which will have the standby defined in an log_archive_dest_n as well. This will result in a new primary, having two standby's: The old standby and the old primary. Then you stop the old primary, and remove its references from the new primary and old standby. This is will cause you only a small hickup during switchover. I think this is a more robust move, that will also cause you less downtime. Probably most of the activities can be done during office-hours as well, depending on the available bandwith and resource-consumption. Regards, Carel-Jan === If you think education is expensive, try ignorance. (Derek Bok) === > Cold backup of the primary database. It was then restored on the new > server. A reset logs was done, but right now I'm trying to debug the > activation ID mismatch. Unless the activation id is tied into the > sequence number?? > > Not sure if the DBA had stopped the standby last night. Probably not. > Would that really be a factor? The primary was shutdown, logs stopped > shipping. > > The old and new server name for the primary database are different. We > moved a bunch of databases from individual servers to a new monster > server. So Im wondering if that is killing me. Perhaps the hostname is > coded into the archive log file??? Dunno. > > Still scratching my head, poking and proding around... > > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx > [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Carel-Jan Engel > Sent: Thursday, March 25, 2004 10:01 AM > To: oracle-l@xxxxxxxxxxxxx > Subject: Re: Dataguard - primary database moved to another server > > > Chris, > > Can you explain how you moved the primary? Did you stop the standby while > the primary was moved? > > > > >> A primary database was moved to a new server. The primary and standby >> are >> no longer communicating. >> >> The alert log on the primary is reporting.... >> ORA-16069: Archive Log standby database activation identifier mismatch >> >> The alert log on the standby is reporting.... >> RFS: Activation ID mismatch found xxxxx expected yyyyyy >> RFS: Possible network disconnect with primary database >> >> Is there a config file that I can tweak to fix this activation id??? >> >> I dropped the entry in Dataguard and attempted to recreate but it failed >> because of the above errors. >> >> For what its worth I fixed fal_server on the standby. >> >> I have been searching around Metalink and the doc but I cant find many >> references to the activiation id. I searched the DG .dat files, but I >> can't find it in there either. >> >> We really don't want to recreate the standby from the primary again, >> since >> we are planning on moving a slew of primary databases to new servers. >> >> Help? >> ---------------------------------------------------------------- >> Please see the official ORACLE-L FAQ: http://www.orafaq.com >> ---------------------------------------------------------------- >> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx >> put 'unsubscribe' in the subject line. >> -- >> Archives are at //www.freelists.org/archives/oracle-l/ >> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html >> ----------------------------------------------------------------- >> > > > Regards, Carel-Jan > > === > If you think education is expensive, try ignorance. (Derek Bok) > === > > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ------------------- > --------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------