Apart from cluster issues as such, the speed of light is a performance limiting factor for all of them: RAC, storage replicaton or data guard or third party solution. RAC must suffer the most, that's quite obvious. Storage replication ? Well, redo (i.e. commit) performance is of most concern as this is not a background process. The same applies to the data guard. I assume synchronous replication/standby redo log writes here. But can you think of anything else if no data loss is a must ?? btw, in my experience logical standby and replication solutions can perform only in controled and limited situations. Would never ever through them at general purpose database. Too many issues with performance, bugs, limitations... my extra 2 cents, brgds, Laimis N., --------------------------------------------------------------------------------- Please consider the environment before printing this e-mail From: Nuno Souto <dbvision@xxxxxxxxxxxx> To: oracle-l@xxxxxxxxxxxxx Date: 2011.09.01 10:48 Subject: Re: Oracle DR Solution Gaja Krishna Vaidyanatha wrote,on my timestamp of 1/09/2011 7:34 AM: > Extended RAC is a good option for a campus-based HA (ideally with distances not > exceeding 10 km). Yes, I know what the documentation says with 100 km, but > depending on the application, the segmentation of users across nodes (and their > respective read/write workloads) and the interaction with the database buffer > cache, inter-node communication can (and will) be an issue, as the distance > between the nodes increase. Thus, I agree with some of the concerns voiced over > implementing Extended RAC over long distances (even with dark fiber) due to > latency issues that can exacerbate inter-node communication and in-turn can > cause all sorts of downstream issues to the stability of the nodes in the > cluster. If one has dealt with node-evictions due to cluster communication > delays, you know exactly what I am referring to here. Thank you for stating the obvious and being a voice of sanity, Gaja! I can't start to mention how much the "Extended RAC" nonsense has damaged Oracle's credibility in the last 4 years, here in NSW. ALL (that means *ALL*!!!) trial implementations I know of have failed miserably to provide HA, precisely for the reasons you point out: when the distance goes over around 10Ks. The node evictions are simply overwhelming, no matter what communication means is used for the cluster interconnect. And I'd hate to see what happens on a high volume SAP application with such a setup! Note the conditions I mentioned, so please no one counter with a "successfull example" where the distance is across the corridor: it is IRRELEVANT! It's about time dispersed RAC stops being pushed in an unqualified manner by those with vested consultancy interests in its implementations, lest Oracle db's reputation gets irreparably damaged! -- Cheers Nuno Souto in sunny Sydney, Australia dbvision@xxxxxxxxxxxx -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l