We are using advanced replication for three instances.
It's labor intensive, fraught with error, and
requires continual babysitting.
For us, it is doing what we want. Near real time
copies of the primary instance, and instant failover
capability (well, instant as soon as the tnsnames.ora
is changed - but that's another story).
--- DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM> wrote:
> 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: mrclark_at_xnet.com
>
> 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: ListGuru_at_fatcity.com (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: DWILLIAMS_at_LIFETOUCH.COM
>
> 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: ListGuru_at_fatcity.com (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).
Pete Barnett
Lead Database Administrator
The Regence Group
pnbarne_at_regence.com
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Peter Barnett
INET: regdba_at_yahoo.com
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: ListGuru_at_fatcity.com (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).
Received on Tue Aug 27 2002 - 15:48:32 CDT
