| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: GLOBAL_NAME change
Michael
Thanks for the additional info. At this point I appreciate all I can get. Although you did have some unsettling news ("our TNS entries would no longer work in a few cases" ???).
Dennis Williams
DBA
Lifetouch, Inc.
"We all want progress, but if you're on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive." -- C.S. Lewis
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Michael Thomas
Sent: Wednesday, July 21, 2004 9:16 PM
To: oracle-l_at_freelists.org
Subject: RE: GLOBAL_NAME change
Hi,
Hope I'm not getting to far off-track of the Subject,
but as far as GLOBAL_NAME is related to
GLOBAL_NAMES...
That book is good. If I remember, the docs on advanced replication have similar examples (??? from memory).
We've used this many times. Another (password hiding) trick is to create a separate (private and local) schema with the db_links & passwords, create views and or synonyms in that schema, and grant permissions to the other local schemas.
Sometimes you get some really cool looking queries when you need to resolve everything:
select *
from dual_at_db_link.domainX_at_alias_schemaY.domainX;
(note two @'s)
One strange gotcha I noticed, if we were to switch all our databases to GLOBAL_NAMES=TRUE, was that our TNS entries would no longer work in a few cases. This might have seriously troubled our application developers.
Note: We used the same tnsnames.ora file on both database servers and clients. Some of our database names were picked so poorly, there would be no way to distinguish the domain. This might simply be something to test for side-effects. :-)
Also, some of the Advanced Replicaton stuff says you *must* use TRUE to perform certain functions. But, we found if its set up correctly, we might (at our own risk) just alter session to TRUE and these functions would work even if the database is FALSE. Not that I'm recommending anyone actually do it. ;-)
Regards,
Mike Thomas
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Jul 22 2004 - 11:15:56 CDT
 |
 |