Best way to updat TNSNames.ora in all servers
Krish
We have many unix (hp-ux, AIX, Linux, Solaris) servers running Oracle
database 9.2.0 enterprise edition. 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.
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)
I would like to know the experts comments, suggestions.
Thanks in advance for all your help.
Krish.
DA Morgan
And the logic, or lack thereof, creating additional databases on the
same server? With an unpatched neolithic version of the product? I
find paper cuts less painful.
I'd suggest looking at moving to a single operating system, perhaps
Oracle Linux and a supported version of the database, perhaps 10.2.0.3.
And consolidating everything into a single database with multiple
schemas.
With any luck at all the DBAs might not find themselves working on
Sunday.
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
hjr.p...@gmail.com
You've got enough databases there to make it worth your while
investing a little time and effort in getting Oracle Internet
Directory working. (You're 9i, so you could get Names Server working,
too, but Names Server dies in 10g, so OID gives you some future-
proofing).
There's an article on implementing OID here: http://www.dizwell.com/prod/node/709
I've had good results with OID running in a relatively skimpy virtual
machine on Linux doing good names resolution duties for a totally
Windows-based environment. (You can do OID on pretty much any
platform, of course, it's just that I didn't need a Windows license
doing it this way).
cleveridea
#1 using the NFS mount puts all your eggs in one relatively unstable
basket (compared to a local file system)
#2 if you have so much volatility in spinning up new databases on
existing hosts already running Oracle instances, I suspect you have an
application development/deployment methodology where 1 app = 1
database - instead of 1 app = 1 schema. I've seen that before and it
is a gargantuan waste of time and money. My guess would be there's
lots of public synonyms too?
#3 I haven't used tnsnames.ora for years on a host to host database
reference in years (use @//host/service_name instead of @alias)
fitzj...@cox.net
> 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
Krish
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
hjr.p...@gmail.com
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.
joel garry
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