Thank you for your excellent feedback. And, thank you
for reminding me that replication requires quiescing
the databases for DDL changes! :-( Ughh, as soon as I
read that I quickly remembered spending late nights
doing application upgrades from 2 years ago and the
hassle I had to go through because it was in a
replicated environment.
I found a variety of white papers on this topic today
that I'm going to read over the weekend. Fun wow.
-w
- Jeremiah Wilton <jwilton_at_speakeasy.net> wrote:
> Things that can weight the decision on the side of
> standby:
> - Frequent DDL changes - requires outage for MM rep.
> - Very high rate of DML - MM rep may fall behind.
> - High latency network - MM rep may fall behind
> - Allowable failover time is over 10 minutes.
> - Losing the last few minutes of transactions is OK.
> - It is economically acceptable to have a whole
> system sitting idle.
>
> Things that can weight the decision on the side of
> MM replication:
> - Both systems must be usable.
> - low rate of DDL changes
> - low rate of DML
> - good network between systems
> - No committed data loss is acceptable
> - Failover must be instant
>
> There are other solutions that you might find worth
> investigation:
>
> - Standby + geomirring of logs & controlfiles - (0
> data loss standby)
> - Shared disk cluster - OPS or HA configuration (DB
> is not redundant, but host is)
> - Quest SharePlex (log-based replication a la
> Sybase)
> - Redundancy within a single host (hardware
> components, RAID mirroring,
> listener, logfile, application redundancy)
> - Just a good fast enterprise backup & restore
>
> You get to do the calculation - based on your
> businsess's needs, which gets the
> correct amount of availability with the fewest
> dollars in the most *likely*
> disaster scenarios?
>
> So, I've ditched LazyDBA as well. I guess I just
> never know everyone was over
> here. There are a lot less questions here where the
> answer is RTFM. All those
> people over there wanting to cheat on their OCP
> class homework were starting to
> get on my nerves. This last little hullabaloo was
> just the last straw. They
> really were a bunch of lazy DBAs. Too lazy to crack
> a manual.
>
> Anyone in Seattle want to get together for beers?
> I'll drag the other Amazon
> DBAs along, if you can stand the sight of a passel
> of geeks. Reply to me, not
> the list.
>
> --
> Jeremiah Wilton
> http://www.speakeasy.net/~jwilton
>
> On Fri, 25 May 2001, Jack C. Applewhite wrote:
>
> > We have a Standby database and I love it -
> especially compared to the
> > complexities of replication!
> >
> > Once you set up the standby database, automate the
> mechanism for
> > transferring archived redo logs from your
> production db to the standby,
> > applying them, and deleting them once applied, it
> requires almost no
> > intervention. About the only time I have to
> fiddle with the standby is
> > after I add a datafile to a tablespace on the
> production db.
> >
> > We're on 8.1.6 under Win2k and our production db
> has almost 8 million CLOB
> > documents, with about 50,000 added each night.
> The standby keeps up nicely.
> >
> > -----Original Message-----
> >
> > I'm looking for feedback on setting up a
> > high-availability architecture for our production
> > database. In a nutshell, we are a 24-hour shop and
> I
> > need to be able to keep a secondary database
> > (failover) in sync with the primary in case the
> > primary fails. I have supported advanced
> replication
> > (asynchronous) in the past but it was a single
> master
> > relationship not multi-master.
> >
> > I'm leaning towards a standby database setup
> because
> > my experience with advanced replication is less
> than
> > favorable if/when transactions get out of sync.
> Also,
> > one of the tables contains a LONG RAW. This column
> may
> > go away or may be converted to a CLOB in the very
> near
> > future but still needs to be kept in consideration
> > when selecting a solution.
> >
> > The platform is Sun (SunOS 5.7) with 8.1.6. The
> > secondary machine and database will most likely be
> > located in another state. The database is small
> right
> > now (~10Gb) and will continue to grow, but not too
> > fast.
> >
> > What are your opinions?
> > Is there an obvious choice between the two
> > alternatives?
> > Is there another alternative that I should be
> > considering?
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Jeremiah Wilton
> INET: jwilton_at_speakeasy.net
>
> 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).
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Walter K
INET: alden14004_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 Fri May 25 2001 - 13:00:52 CDT
