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

On Sep 24, 8: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 might consider keeping tnsnames for cases of direct server to server interaction. From what I've seen of places with many different servers, users tend to have heavy use during the day, sometimes including dblinks, while servers tend to have off hours big batches. So during day hours, you don't want to load up the OID and the net with lots of dynamic requests for a very static dblink configuration, and during night hours, you don't want to stop batches because the OID is down for maintenance, or some dummy help desk operator thought it was just another PC.

I've also seen situations where you might want DBA's to have their own .profiles and tnsnames, everyone else can be shared. With many users, you want a failsafe OID, of course. I remember watching people struggle with multiple Oracle Names servers...

YMMV. jg

--
@home.com is bogus.
http://www.engcom.net/index.php?option=com_sliderule&Itemid=73