Re: Database redunancy

You can also centralize your tnsnames.ora file and add the tns_admin registry key to point to the centralized tnsnames.ora on all of the client machines.

That way, when you need to switch the machine that is being pointed to, you can just edit the main tnsnames file that would be on a fileserver somewhere.

Does that make any sense?

In case you don't know, the tnsnames.ora is usually put in the orahome\net80\admin directory, and you can override this by adding the tns_admin string value in the
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE] key.

Should look something like:

[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE]
"TNS_ADMIN"="d:\\temp"

where d:\temp could be your network fileserver.

Anyway, that is just a thought I had. Hope it helps.

Scott

"Kenneth C Stahl" <BlueSax_at_Unforgettable.com> wrote in message news:3862258B.29F24895_at_Unforgettable.com...
> 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.
>
> So, that is the background. Any thoughts?
Received on Mon Dec 27 1999 - 14:43:10 CST