RE: Dataguard - primary database moved to another server
- From: Josh Collier <Josh.Collier@xxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 25 Mar 2004 11:08:31 -0800
I concur that opening the primary resetlogs will kill the standby. You have
no choice but to recreate it from scratch. You can use switch over method to
move the primary around. Set up a standby on the target server (the one to
which you wish to move the primary), get it caught up, then use switchover
to move the primary there.
Josh C.
-----Original Message-----
From: Carel-Jan Engel [mailto:cjpengel.dbalert@xxxxxxxxx]
Sent: Thursday, March 25, 2004 9:56 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Dataguard - primary database moved to another server
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
-----------------------------------------------------------------
----------------------------------------------------------------
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
-----------------------------------------------------------------
Other related posts:
