Re: Domain design for distributed databases
- From: Mark Bole <makbo@xxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 03 Mar 2005 17:55:08 -0800
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.
> DB1.ATLANTA and DB2.NEWYORK or DB1.ACCOUNTING and DB2.SALES) but the
> 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 <jcave@xxxxxxxxxxx>
> Distributed Database Consulting, Inc.
> http://www.ddbcinc.com/askDDBC
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Sarah Satterthwaite
> Sent: Thursday, March 03, 2005 2:51 PM
> To: oracle-l@xxxxxxxxxxxxx
> 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 8.1.7.4 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:
inst1.foo
inst2.foo
inst1.bar
inst1.baz
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
http://www.bincomputing.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
