Global names

[Justin Cave]

It recently came to my attention that the DBA's where I work have adopted a convention where the global_name of a database is the same for the production, test, and development instance of that database (obviously, they've turned off global naming in the init.ora). They've also set up the tnsnames.ora file on each machine so that the same service name points at different instances (i.e. connect scott/tiger@foo will connect to the production foo database if you're on another production database, the QA foo database if you're on another QA database, and the development foo database if you're on a development database). Our DBA argues that this configuration is strongly preferred by the majority of developers since they don't have to make any changes to their code when they move from development to QA and to test. Everyone in my development group agrees that this isn't the best way to set up the system, but we're not sure whether this is just an annoyance or whether it's a real problem.

We provide a source of data for a number of other projects that link to our database to grab snapshots of some tables. We've had one incident lately where a development group thought they were pointing at our production instance in all three of their instances and nearly had a heart attack when they discovered that they were close to publishing our development data to their production system. This was partially our fault because the password for the user that has permission to create snapshots was the same in all three of our database instances-- we fixed that really quickly.

We know there are hundreds of databases set up with this sort of naming convention, so we're not in a position to push for the system to be changed if this is merely an aesthetic issue. We've looked around in all the Oracle manuals we can find and while they seem to agree that unique global names is the preferred method, we can't find anything that enumerates the risks of going against that advice. If anyone here has practical experience with this, I'd certainly appreciate hearing about it.

Thanks,
Justin Cave
Distributed Database Consulting

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Justin Cave
INET: [EMAIL PROTECTED]

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).