Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Domain design for distributed databases

Re: Domain design for distributed databases

From: Mark Bole <>
Date: Thu, 03 Mar 2005 17:55:08 -0800
Message-ID: <>

Justin Cave (DDBC) wrote:

> I would tend to try to align domains to groups responsible for the
> databases.
> If you have a very silo-ed operation, where there is one DBA group for
> one business unit and another DBA group for another business unit,
> giving each DBA group a different domain to manage makes perfect sense.
> Both business units might want to have an Accounting database named
> 'ACCT' and the DBA's setting these up might not have an easy way to see
> whether anyone else wants to use that name. If there is an 'ACCT.SALES'
> and an 'ACCT.BILLING' database, everyone is happy. Different DBA groups
> might have different procedures/ naming conventions/ etc. that are
> easily accommodated with different domains.
> If you have a more unified operation, on the other hand, one domain is
> probably sufficient. Domains might help you organize databases, (i.e.
> extra pain of trying to remember the domain, adjusting domains as
> systems move locations or become more shared, and dealing with
> connectivity issues because different users have different
> default_domain settings in their sqlnet.ora file and thus need different
> connection strings probably far outweighs these advantages.
> Justin Cave <>
> Distributed Database Consulting, Inc.
> -----Original Message-----
> From:
> [] On Behalf Of Sarah Satterthwaite
> Sent: Thursday, March 03, 2005 2:51 PM
> To:
> Subject: Domain design for distributed databases
> We are looking at implementing updatable snapshots at a remote site and
> this
> has raised a number of issues about how our environment is currently set
> up.
> Environment:
> Oracle on Windows servers (with one VMS 7.3.4 still in
> the
> mix, but not involved in the replication).
> All the databases are in the .WORLD domain.
> Global naming needs to be enforced for the replication
> implementation.
> I am trying to decide whether we should implement multiple domains. The
> db
> servers are located at 3 different sites (only 2 of which will be
> involved
> in the replication). It appears to me that Oracle's assumptions in the
> way
> they have implemented database links and global names includes the
> expectation that the work is pretty well isolated within a domain. If a
> remote object is in the same domain, you can ignore the domain portion
> of
> the database link and let it default. If it is in a different domain
> you
> have to code the full global name someplace, if not in the code, hiding
> it
> in a view or synonym to implement the location transparency. =20
> Some characteristics of our primary application could make maintaining
> all
> this messy:
> Table names are built dynamically based on data values.=20
> The set of tables that exists slowly changes over time as the
> data
> values change.
> There are lots of tables (~8000 in the largest database, only a
> small subset of which will be replicated).
> After experimenting some, a single domain is looking better and better.
> But
> will I regret it later (when it will be even harder to change)?
> I am looking for guidelines on how to design the domains. What should
> be
> grouped together and why? What should be separated? =20
> I hope some of you have wisdom to share and/or pointers to resources.
> Thanks!
> Sarah

You are most likely not operating in a vacuum, in that you probably already have existing DNS domains or Windows domains or NIS domains or some other type of domain in place... so consider first just mirroring that: make the domain of each database the same as the dominant administrative domain that the machine itself lives in.

Domains based on org charts are the least usable in my experience. Geographic locations tend to be very stable (except here in earthquake country!). I have had pretty good experience with making each machine (server) its own domain for Oracle purposes, in other words:

where foo, bar, and baz are separate machines.

You can easily create views and synonyms to achieve the transparency you want, as you said. Just make sure you script it. You already grasp the most important issue when you ask about future regret. It is inevitable that databases will relocate in one or more dimensions over time (organization, geography, machine) -- can you say, "corporate merger"? ;-)

Mark Bole

Received on Thu Mar 03 2005 - 20:58:26 CST

Original text of this message