| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Standby vs. Adv. Replication (Multi-master)
I too have had the wonderful experience of supporting multi-master replication. We had 3 sites and there was a lot of work maintaining it. I have not had the opportunity to implement a standby-database yet but from talking with those who have setting up and maintaining a standy-by database would be less painful that setting up advanced replication.
Either way you need to evaluate your network. One of the killers for our initial advanced replication environment was network speed. There just wasn't enough 'umph' to replicate the data real-time (every 60 seconds) between 3 sites.
We used our environment to split workload as well as provide availability when one of the servers was down (either voluntarily or involuntarily). The failover was fairly straight forward, change the DNS information to point the clients to another server and break the push jobs related to the down server. Getting the database back in sync afterwards was a different matter. We were pushing approximately 10,000 database calls an hour. The transaction queue would get so full that many times we simply had to do a complete refresh of the database.
I could keep going on but I guess what I am trying to say is that if you are going to be using the secondary database strictly for failover then it seems to me that the standby-database solution would be easier to implement and maintain.
Nancy
-----Original Message-----
Sent: Friday, May 25, 2001 12:21 PM
To: Multiple recipients of list ORACLE-L
Hi,
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?
Thanks VERY much in advance.
-w
-- 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-LReceived on Fri May 25 2001 - 13:53:05 CDT
(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: Nancy McCormick INET: nmccormick_at_sbti.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).
 |
 |