Brad wrote:
>
> In article <3862258B.29F24895_at_Unforgettable.com>,
> BlueSax_at_Unforgettable.com says...
> > I have been asked to investigate the possability of setting up a
> > fault-tolerant Oracle instance on a Sun 450/SunOS5.6 system. The
> > requirements are somewhat fuzzy, but maybe someone will recognize what I'm
> > trying to accomplish.
> >
> > The system architects want to set up the file system so that it is mirrored
> > to another file system. They would like to have Oracle set up so that if
> > the primary database fails that another instance will be instantly
> > available which uses the mirrored files.
> >
> > In a way this seems to be backwards from parallel server since that schema
> > would use two different instances against the same files. In my case it
> > would be an instance with the same name as the primary instance except that
> > it would be running on another machine (in a cluster configuration).
> >
> > I do see some tremendous problems with this since all of the applications
> > programs are actually running on NT workstations as client applications.
> > Even if I could do the database end I don't see how I could instantly
> > switch users over to the alternate instance without diddling with the
> > tnsnames.ora. If it were simply a matter of having them log in different by
> > specifying a difference database alias I could see how that could be
> > handled, but I didn't write the login screens and the database alias is
> > hardcoded into one of the programs and is handled by a global configurator
> > for the other applications. Considering that the current usages is about
> > 80-100 call-center agents, it would appear to me that the deck is stacked
> > against me for any type of automated switchover.
>
> The machine that takes over needs to takeover the IP address of the
> crashed machine.
The problem with that is that the primary machine itself might not crash.
There might only be a problem with the database, the file system or with
networking. Whatever I do, I can only effect the database.
Received on Thu Dec 23 1999 - 11:06:17 CST
