Re: Oracle DR Solution

  • From: Laimutis.Nedzinskas@xxxxxx
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 1 Sep 2011 13:59:03 +0300

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


Other related posts: