Dick is right on the mark with the KISS principle.
resources required to support a distributed db are going to vary greatly
with each installation. i personally had the honor of being a member of a
20 person dba team supporting a single app using a distributed database for
a large agricultural company. all of us suffered from sleep deprivation (i
dare say far more so than the typical DBA).
that particular app has been re-engineered to the point where only 6 DBAs
are required to administer it today. but all 6 would jump at the chance to
move on to another project. i did that a year ago (jumped that is).
as they say, your mileage may vary ;)
-----Original Message-----
Sent: Wednesday, July 10, 2002 12:15 PM
To: Multiple recipients of list ORACLE-L
James,
Depends on the number of DBA's that you currently have. Doing plain old
distributed stuff is none to complicated, more work for the developers than
anything else. Advanced replication could become a bear depending on who
becomes the responsible party. Once an object falls into the advanced
replication arena you should not perform DDL on it outside of the
replication
tool so this normally becomes a DBA responsibility. The other area that
becomes
fun is the conflict rules, but once setup they should remain stable, unless
there's some real complicated ones, remember KISS.
Dick Goulet
Goffstown, NH
____________________Reply Separator____________________
Author: "James Damiano" <[EMAIL PROTECTED]>
Date: 7/10/2002 8:34 AM
Greetings all,
To this point in time, our organization has pretty much had vanilla
Client/Server and Web Apps accessing Oracle RDBMS on Tru64 Unix, Netware,
and Windows/NT. However, we are considering future applications which may
involve doing "Distributed Database" and "Advanced Replication". In just a
high-level sense, what are the implications to the DBA staff? I.E. Would it
be not much impact and "no big deal", or would it complicate our DBA's lives
drastically and by "orders of magnitude"?
Thanks very much for your always valuable insights,
JDamiano
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: James Damiano
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: STEVE OLLIG
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
