RE: GLOBAL_NAME change
- From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 22 Jul 2004 11:15:28 -0500
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Michael Thomas
Sent: Wednesday, July 21, 2004 9:16 PM
To: oracle-l@xxxxxxxxxxxxx
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...
--- DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx> wrote:
> Thanks Jared. From what I see, Dye covers this in
> Chapter 10, page 226.
> Evidentially this is a standard technique used for
> advanced replication, and
> is, I assume, a useful way to create your standard
> database links.
...
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@xxxxxxxxxxxxxxx@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
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
