Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Domain design for distributed databases
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 replicationimplementation.
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 thedata
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