i Just needed some tips.

We have an oracle DB running on 8i in production system. Its has a
standby which is getting synced using archive logs on a remote
destination.

Archive Log
Server A
-----------------------------------------------------------------------------------------------
Server B


Server A and Server B are in 2 different locations.


My doubt

Can i have the following architecture , where archive logs are written
to 2 servers ?

Server
A-------------------------------------------------------------------------------------------------
Server B

So in the above Server A is primary and i start to write archive logs
to Server B remote location and Server C , same location as Server A.

Then for testing purpose i now apply logs to Server B/Server C , so at
a point in Time , as archive logs are applied , all my three servers
Server A , Server B and Server C are having same data.

My second more important doubt is Can i make Server B primary and let
it ship logs to Server C and Server A without having to take full
backup of Server B? I heard from some guys that this is not possible
but i am hoping that there would be some undocumented way to achieve
this.

Please let me know.

On Sep 1, 11:05*pm, Ruddy <reach... (AT) gmail (DOT) com> wrote:
See the init.ora parameter log_archive_dest_n
http://download-west.oracle.com/docs...h180.htm#41715

Are you applying manually or automatically? If you are using the
automatic application, there are things that could stop your
production. Whatever the case, things are much better in supported
versions.

You can failover to server B... oh, you are asking whether you can
make server A a standby after failover. There was a white paper about
this on oracle.com, I don't know if it is still there. "Graceful
Switchover and Switchback
Oracle Standby Database
Versions 7.3, 8.0, 8.1
Revised November 11, 1999"
You never know what you might find on the web, though.

The basic problem is you have to avoid a resetlogs operation to make
this work. Activating a standby database implicitly does a
resetlogs. Most unsupported hacks to avoid this will give you a
corrupted database. The paper shows how to work around that by
stopping the databases at the correct time and doing the correct
manipulation of controlfiles and applying archived logs to avoid a
resetlogs.

This requires a lot of careful testing.

jg
--
@home.com is bogus.
HP wins, Dell loses.