RE: Standby vs. Adv. Replication (Multi-master)

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).