| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Dataguard - primary database moved to another server
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_at_xs4all.nl]
Sent: Thursday, March 25, 2004 9:56 AM
To: oracle-l_at_freelists.org
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_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Carel-Jan Engel
> Sent: Thursday, March 25, 2004 10:01 AM
> To: oracle-l_at_freelists.org
> 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_at_freelists.org
>> put 'unsubscribe' in the subject line.
>> --
>> Archives are at http://www.freelists.org/archives/oracle-l/
>> FAQ is at http://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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Mar 25 2004 - 13:08:11 CST
 |
 |