Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

RE: Domain design for distributed databases

From: Justin Cave (DDBC) <jcave_at_ddbcinc.com>
Date: Thu, 3 Mar 2005 13:33:27 -0700
Message-ID: <87E9F113CEF1D211A4C300902730187462C9F6@ddbcinc.ddbc.local>


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_at_ddbcinc.com>
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Sarah Satterthwaite Sent: Thursday, March 03, 2005 2:51 PM
To: oracle-l_at_freelists.org
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


Sarah Satterthwaite
Database Administrator
Fiserv CSW, Inc
125 Cambridge Park Drive
Cambridge, MA 02140

Email: sarah_at_cswv.com

--

http://www.freelists.org/webpage/oracle-l
--

http://www.freelists.org/webpage/oracle-l Received on Thu Mar 03 2005 - 15:36:42 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US