Ed - We have flirted with the replication thing here for some time. I have
had the same questions as you, trying to take classes, for example. I don't
think replication is widely used, but there are plenty of sites out there.
The conclusion I've come to is that the secret to a successful
replication project is not in the technology. It is in the preparation.
Success requires a military-like discipline of getting full cooperation from
all involved people. And there will be many more people throughout your
organization to be involved than you think. Replication is a practice rather
than a slap-on Oracle or third-party feature. Regardless of the technology
you select, you'll still need to resolve the same issues in order to
succeed. Dull stuff like how you will test replication (very difficult), how
you will fix the data when the replication inevitably breaks, how you will
implement changes (massive issue, as Dick points out). Replication can move
corrupt data just as quickly as good data. Whether you are using the most
expensive third-party add-on tool (aren't vendors great at acting like their
product will solve all your problems?) or tossing magnetic tapes in a semi
to be driven to the site, the big issues don't change. A friend was just
reliving problems they encountered 15 years ago with a home-grown COBOL
system. As he discussed their problems, he was shocked that the underlying
problems haven't really changed much. Maybe more convenient and faster, but
you still have a lot of human involvement, regardless.
Replication is easy so set up. Keeping it running reliably day after day
is the trick. For example a friend of mine who had quit his previous
employer to get away from their replicated environment (this was a Sybase
log-based project). Recently someone at one of their remote sites decided to
reboot a server. It took several days and nights for them to get the entire
system corrected.
First of all your organization must decide whether replication is worth
all the time and trouble it will inflict. Most replication projects are
caused by political rather than technical reasons. Like two divisions that
both need to be equally important.
I feel most replication projects are eventually abandoned. If the
organization was smart and started with a small project, usually their
enthusiasm was simply dulled. If they weren't and started with a really big
project, the disaster can be spectacular. Usually the organization starts
with a small project, learns how much trouble replication is, and never
implements "phase II". The successful replication projects probably aren't
so visible on because the people who tend them day in and day out aren't the
shooting stars that go for the latest technology. Those people may have sold
management on starting the replication project, but they would have probably
gotten bored with the mundane detail and follow-up and moved on to a more
exciting project.
Another factor is the application. The best application is one you are
just now developing in-house where you can build replication considerations
in from the initial design. The worst is a mature third-party product that
you don't clearly understand at the data level and have no hope of modifying
to accommodate replication.
The only two books I've found on replication are:
Data Replication, Marie Buretta, 1997. Lists all the issues that
must be considered for a replication project to succeed.
Oracle Distributed Systems, Charles Dye, 1999.
As you can tell from the publication dates, this isn't exactly a hot
technology.
I don't mean to be too negative. I just feel it is important for an
organization to understand what they are getting in for before they start.
If the benefits outweigh the costs, then proceed. But don't think a couple
of DBAs can "turn replication on" and succeed. Eventually management wakes
up and says "wow, we've gone through about a dozen DBAs in the last year, do
you think they are overwhelmed by that replication thing?".
Again, these are my observations from studying replication from the outside.
Perhaps it will provoke some responses from replication experts.
-----Original Message-----
Sent: Monday, August 26, 2002 11:58 AM
To: Multiple recipients of list ORACLE-L
I'm curious, based on a discussion I had with a DBA here at work, how
many people use the replication features of Oracle. I often see
replication listed as one of the selling points of Oracle, but it's also
very hard to get a class on replication because they are always closing
classes for poor registration.
How common is replication (basic or advanced)? It makes more sense to
use simple snapshots than DB links for what we are doing, but given that
our support from Oracle has been TERRIBLE with snapshot problems, I now
wonder if anyone uses them. We are switching to db links, but that can
pose potential performance issues with, for example, joins across the db
link.
Best,
Ed
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Ed
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: DENNIS WILLIAMS
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).
