RE: GLOBAL_NAME change

From: Michael Thomas <mhthomas_at_yahoo.com>
Date: Wed, 21 Jul 2004 19:15:48 -0700 (PDT)
Message-ID: <20040722021548.58134.qmail@web50605.mail.yahoo.com>

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_at_LIFETOUCH.COM> 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_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                 

---

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_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 Wed Jul 21 2004 - 21:12:20 CDT