Re: Best way to updat TNSNames.ora in all servers

On Sep 25, 1:19 am, Krish <Krishna.Bu..._at_gmail.com> wrote:
> On Sep 24, 9:20 am, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net> wrote:
>
>
>
> > Comments embedded.
> > On Sep 23, 6:30 pm, Krish <Krishna.Bu..._at_gmail.com> wrote:
>
> > > Hi All,
> > > We have many unix (hp-ux, AIX, Linux, Solaris) servers running Oracle
> > > database 9.2.0 enterprise edition.
>
> > Are all of these servers running the same release of Oracle, with the
> > same options installed? If so then I will agree with the advice thus
> > posted: consolidate these databases into a single instance/multiple
> > schemas on a server sized to provide sufficient 'horsepower' to allow
> > all of these applications to function properly. The only reason I
> > could justify for having many installations of Oracle 9.2.0.x would be
> > if the installed options differ between servers, for example the hp-ux
> > servers utilize partitioning, the Solaris servers implement Label
> > Security, the AIX servers house your data warehouses, etc. Should
> > that be the case then I would still work to consolidate the databases
> > on a server or operating system to a single Oracle database on a
> > single server suitably configured for the user load. Why so many
> > vendors of Unix? Was this the product of a merger? Even if an
> > application has need of a specific operating system vendor (for
> > example, AIX) the database it accesses should be able to be run on
> > UNIX from a different vendor (Solaris), allowing you to reduce the
> > number of physical systems running Oracle to one or possibly two,
> > depending upon the size of these databases, the user load and your
> > budget and providing a uniform running environment for your database
> > or databases.
>
> > Are these installations still sitting at 9.2.0.1? Again I must agree
> > with advice already dispensed and patch the installations to the
> > terminal release of 9.2.0 (9.2.0.8) and apply all of the CPU updates.
>
> > > Each server has 4 or more
> > > databases. Currently each unix server has its own tnsnames.ora in /etc
> > > folder and all windows machines TNS_ADMIN is pointing to a shared
> > > drive.
>
> > > we are planning to implement one of the below methods to avoid
> > > "ORA-12154" error whenever new db is created and forgot to update all
> > > the tnsnames.ora files.
> > > 1.creating TNSNames.ora in a shared (NFS mounteed) file system and
> > > pointing all servers TNS_ADMIN to this shared drive.
>
> > You'll be dependent upon that NFS mount to exist and if it fails so
> > goes your access.
>
> > > 2.shell sciprt to replace all the tnsnames.ora files with the master
> > > tnsnames.ora( master tnsnames.ora file will be updated whenever new db
> > > is created)
>
> > Working in a leveraged environment running several versions of Oracle
> > (since not all applications play nicely with the later versions of
> > Oracle and some applications require options which are absent for
> > others) we use such a solution. Ensure that the transfer of the
> > 'master' tnsnames.ora file is successful to all destinations in your
> > script and report any errors in transfer and allow for re-transmission
> > of the 'master' to failed destinations.
>
> > > I would like to know the experts comments, suggestions.
>
> > > Thanks in advance for all your help.
>
> > > Krish.
>
> > David Fitzjarrell
>
> Hi all,
>
> Thank you very much for all of your suggestions.
> We are following the "single database -multiple schemas" concept for
> our testing environments.
> But we do have some production like environments where we have to
> maintain different DBs on different OS.
>
> we are working on "Oracle Internet Directory" option. I belive this is
> the right solution if we don't have to change anything in the
> application.
>
> Once again thanks .
>
> Krish

You don't (have to change anything in the application, that is).

The app still connects as ever it did.

It's the sqlnet.ora which says 'this time, I use an LDAP server' and an ldap.ora says 'Over there, and by the way it's OID'. That's a client configuration change, not an application change. Received on Wed Sep 26 2007 - 20:29:54 CDT